Saltar al contenido principal
La Intelligent Tracking Prevention (ITP) de Apple es una tecnología orientada a aumentar la privacidad del usuario evitando el tracking no deseado por parte de los sitios web y los distintos scripts instalados en ellos. Se utiliza en todos los navegadores Safari, incluidos los de equipos de escritorio (Macintosh) y todos los dispositivos iOS (iPhone e iPad). ITP introduce importantes restricciones en las operaciones que puede realizar el software basado en JavaScript. Aunque ITP se dirige principalmente a los sistemas de publicidad online, las últimas versiones son mucho más agresivas e impactan significativamente en el software de analítica web, como Google Analytics. ITP también afecta significativamente a las herramientas de A/B testing. Kameleoon puede ser plenamente funcional incluso con dispositivos Apple que tengan ITP activada. Sin embargo, debe insertar una pequeña sección de código de sincronización en sus servidores backend. Este artículo explica las limitaciones técnicas y las consecuencias de ITP para la experimentación y la analítica.
  • Limitaciones técnicas impuestas por ITP.
  • Consecuencias para las operaciones de Web Analytics y Conversion Optimization.
  • Solución recomendada por Kameleoon para evitar los problemas de ITP.

​
Restricciones técnicas de ITP​

Intelligent Tracking Prevention implementa restricciones considerables en torno al uso de cookies y otros almacenamientos del lado del cliente (como local storage). Es importante entender algunas características importantes de las cookies. Las cookies son fragmentos (muy) pequeños de datos que un sitio web almacena en el navegador del visitante. Muy a menudo, representan identificadores únicos generados aleatoriamente. Cada cookie está vinculada a un dominio (como www.example.com) y tiene una fecha de caducidad. Cada vez que se realiza una llamada al servidor a cualquier dominio vinculado a una o más cookies almacenadas en su ordenador, los datos contenidos en estas cookies se envían al servidor web de ese dominio de forma automática y transparente. En consecuencia, las cookies se añaden constantemente a la mayoría de las solicitudes web, con dos consecuencias inmediatas:
  • El tamaño de las solicitudes web aumenta, ralentizando su velocidad de navegación.
  • Su navegador transfiere datos a servidores remotos sin su consentimiento explícito, lo que permite identificarle y rastrearle.
Como las cookies suelen ser bastante pequeñas, el primer problema generalmente no es muy significativo. Sin embargo, el segundo tiene un alcance mucho mayor y es motivo de gran preocupación para los defensores de la privacidad del usuario. El uso de cookies es un tema complejo, ya que se utilizan con muchos fines distintos en la web. Muchas, debido a la naturaleza sin estado del protocolo HTTP, son necesarias para el funcionamiento básico del sitio web. Por ejemplo, las transacciones de comercio electrónico suelen depender de ellas. Con ITP, Apple pretende separar las cookies “útiles” (las obligatorias para el funcionamiento normal de un sitio web determinado) de las “malas” (las asociadas con publicidad, tracking y violaciones de la privacidad). Los sitios web pueden establecer cookies utilizando dos mecanismos diferentes:
  • Cuando se realiza una llamada a un servidor web, el servidor establece la cookie añadiendo una cabecera HTTP en la respuesta HTTP.
  • Mediante código JavaScript en el cliente.
El dominio asociado de la cookie depende del método utilizado. Para las cookies del servidor, es el dominio al que se envió la llamada al servidor. Para las cookies JavaScript del lado del cliente, el dominio es uno de los de las páginas desde donde se ejecuta el código JavaScript (no necesariamente el dominio anfitrión del archivo JavaScript). Las cookies de terceros (third-party) son cookies que se envían a un dominio distinto al de la página web que está viendo en ese momento. Por ejemplo, si está navegando por www.randomshop.com, pero ese sitio web realiza una llamada a tracking.ad-system.com, las cookies asociadas a www.ad-system.com pueden enviarse junto con la consulta HTTP. Se considerarán cookies de terceros en el contexto de su sesión actual de navegación en www.randomshop.com. Cuando una cookie caduca, el navegador la elimina por completo. Sin embargo, dado que la entidad que crea la cookie elige la fecha de caducidad, esta puede establecerse muy lejos en el futuro (por ejemplo, 10 años o más). Esta duración garantiza que vive mucho más allá de lo necesario para el funcionamiento normal del sitio web original. Esta práctica está cambiando con ITP. Estas son las dos restricciones principales impuestas por ITP 2.3:
  • En todas las versiones de ITP, las cookies de terceros están muy restringidas. Safari bloquea las cookies de terceros 24 horas después de establecerse en el navegador. Técnicamente, no se eliminan, pero ya no se envían automáticamente al servidor de terceros mediante solicitudes HTTP. En el ejemplo anterior, un visitante que llega a www.randomshop.com obtiene una cookie de www.ad-system.com mediante una llamada HTTP a ese servidor durante su primera visita. Si el visitante vuelve más de 24 horas después, la siguiente solicitud HTTP a www.ad-system.com no recibe los datos de la cookie original.
  • A partir de la versión 2.3, todos los almacenamientos del lado del cliente (cookies basadas en JavaScript y LocalStorage) caducan a los 7 días.
Dado que el software de analítica web y de A/B testing generalmente no depende de cookies de terceros, la primera restricción afecta principalmente a los sistemas de publicidad. El resto de este artículo se centra en la segunda restricción.

​
Consecuencias de las limitaciones de los almacenamientos del lado del cliente​

Limitar la caducidad de las cookies basadas en JavaScript a 7 días es muy agresivo. Casi todas las plataformas de analítica web (incluida Google Analytics) están basadas en JavaScript o en el frontend y todas utilizan una cookie para almacenar el identificador único del visitante. Este identificador se genera aleatoriamente en la primera página vista de la primera visita del visitante a su sitio web. En las páginas vistas y visitas posteriores, el identificador se reutiliza desde la cookie para identificar al visitante. Esto permite al software de analítica diferenciar entre un nuevo visitante (se genera una nueva cookie) y uno que vuelve (se encuentra una cookie establecida previamente). Como Safari reduce la vida útil de la cookie a 7 días, un visitante que realiza su primera visita un lunes y vuelve un martes de la semana siguiente se considera un visitante totalmente nuevo. En otras palabras, los datos de la nueva visita no se vincularán a la anterior. Como resultado, las métricas de nuevos visitantes en el software de analítica ya no son fiables para su tráfico de Safari. Muchas otras métricas también pueden distorsionarse (número de visitantes únicos, tiempo de compra, etc.). Resulta difícil confiar en cualquier cifra producida por soluciones de analítica basadas en cookies. Para sitios web de escritorio, esto podría considerarse una molestia menor, ya que la cuota de mercado del Safari de escritorio de Apple es relativamente baja (entre el 5% y el 10% generalmente). Sin embargo, para sitios web con fuerte tráfico móvil, la cuota de mercado de los dispositivos iOS suele acercarse al rango del 40-50%. Esta cuota significa que casi la mitad de su tráfico puede verse afectada. La mayoría de plataformas de testing y optimización de conversión incluyen sus propias capacidades de analítica web. Estas sufren problemas idénticos, lo que es problemático en sí mismo. No obstante, para los experimentos A/B aparece un obstáculo aún más grave. Cada vez que se asigna un visitante a un experimento, el software de testing selecciona una variación para el visitante. Esta variación debe recordarse con precisión, ya que, si el visitante vuelve, debe ver la misma variación que vio anteriormente. Todas las soluciones de testing en frontend almacenan esta información (asociación entre experimento y variación) en una cookie. Con ITP, un visitante que vuelve más de 7 días después de disparar inicialmente un experimento corre el riesgo de ver una variación diferente. En estas condiciones, el A/B testing no produce resultados fiables. Para más detalles técnicos, consulte esta entrada de blog sobre ITP y sus implicaciones para Web Analytics. El artículo también ofrece una lista de soluciones alternativas al reto de ITP, que se tratan en la siguiente sección.

​
Soluciones para Kameleoon​

La primera solución alternativa implementada por Kameleoon fue guardar información importante, como las asignaciones de variaciones, en LocalStorage en lugar de cookies. De hecho, el uso de LocalStorage en lugar de cookies en Kameleoon es anterior a ITP, ya que LocalStorage tiene varias ventajas sobre las cookies. Una ventaja es que las cookies establecidas por JavaScript no eran completamente fiables ni siquiera antes de ITP, porque los usuarios podían borrarlas manualmente. Usar LocalStorage en su lugar funcionó al principio; sin embargo, la última versión de ITP trata LocalStorage como una cookie y las entradas caducan a los 7 días. Como resultado, este método ya no garantiza A/B tests y personalizaciones fiables en Safari. La solución recomendada por Kameleoon consiste en establecer la cookie kameleoonVisitorCode, que contiene el importante identificador visitorCode, en el servidor mediante una cabecera HTTP, y no solo en el navegador con JavaScript. ITP no impone restricciones a las cookies establecidas por servidores, por lo que esta cookie puede tener una fecha de caducidad suficientemente larga. Con este método, el sistema sincroniza esta cookie entre frontend y backend, y la vida útil de la cookie ya no está limitada por ITP. En Safari, una vez que Kameleoon obtiene el visitorCode leyendo la cookie kameleoonVisitorCode establecida por el servidor, comprueba si el LocalStorage actual está vacío. Si lo está, probablemente la última visita del visitante fue hace más de 7 días. Kameleoon realiza una Server Synchronization Call (SSC) para recuperar de los servidores backend todos los datos que estaban presentes en el LocalStorage. Una vez completada esta llamada, los datos se restauran a su estado anterior. Las operaciones normales pueden reanudarse entonces. Aunque el núcleo de analítica no se ve afectado por ITP y los datos de tráfico reportados son fiables, Kameleoon no puede garantizar lo mismo para las plataformas externas de analítica web. Los bridges de integración con herramientas asociadas siguen funcionando de la misma manera. Comente la situación con el proveedor de la solución de analítica elegida.

​
Conclusión​

Utilizando la solución detallada en este artículo, puede seguir ejecutando AB experiments fiables con la base de usuarios de Safari. Kameleoon proporciona una solución alternativa recomendada y anima a su implementación en lugar de excluir Safari de la base de pruebas. Se esperan más cambios en ITP a medida que Apple trabaja para proteger la privacidad del usuario. Kameleoon continúa supervisando la evolución de la tecnología ITP de Apple e iniciativas similares de otros proveedores de navegadores. Por ejemplo, Firefox tiene una solución similar a ITP, pero aún no es tan estricta. Cualquier cambio incompatible se analizará y se comunicarán las soluciones.