¿Qué es ITP?

ITP es una función de WebKit, el motor que mueve Safari en Mac, iPhone y iPad. Apareció en 2017 con un planteamiento distinto al de las listas negras. En lugar de mantener un catálogo de dominios prohibidos, el navegador observa cómo se comporta cada dominio y decide por su cuenta cuáles pueden seguir a una persona entre sitios. La clasificación usa un modelo estadístico que mira, entre otras señales, en cuántos dominios distintos aparece un recurso como subrecurso, en cuántos aparece dentro de un marco y hacia cuántos dominios distintos redirige. Todo el cálculo ocurre en el dispositivo del usuario.

De ahí vienen las dos confusiones más caras. La primera: ITP no es un bloqueador de publicidad. Los anuncios se siguen mostrando y las páginas se siguen cargando; lo que se recorta es la vida del almacenamiento que permitiría reconocer a la misma persona en visitas separadas. La segunda: ITP no pregunta por el consentimiento. Es una decisión del navegador, se aplica igual con permiso concedido y responde a la política de privacidad de WebKit, no al aviso de cookies de la web. Un usuario que acepta todo en el banner tiene exactamente los mismos límites de caducidad en Safari que uno que rechaza.

La primera versión trabajaba con dos ventanas temporales. Si el usuario había interactuado con un dominio clasificado en las últimas veinticuatro horas, las cookies de ese dominio seguían disponibles cuando aparecía como tercero. Pasados treinta días sin interacción, sus datos y sus cookies se borraban.

ITP 2.0 eliminó la ventana de veinticuatro horas y pasó a particionar de inmediato. Introdujo además la Storage Access API para los casos legítimos de sesión incrustada, la detección del rebote a través de dominios intermedios y el recorte del referente. ITP 2.1 limitó a siete días la caducidad de cualquier cookie persistente escrita mediante document.cookie y retiró las cookies particionadas. ITP 2.2 bajó ese límite a un día cuando el usuario llega desde un dominio clasificado y la dirección de destino trae parámetros añadidos. ITP 2.3 extendió el recorte al resto del almacenamiento accesible por script y degradó document.referrer al dominio de nivel superior más uno.

En 2020 llegaron los dos cambios que cierran el cuadro. Safari bloquea por defecto las cookies de los recursos de otros sitios, ya sin excepciones, y borra todo el almacenamiento escribible por script de una web tras siete días de uso del navegador sin interacción del usuario en ella. Poco después, ITP empezó a detectar las peticiones que esconden a un tercero detrás de un subdominio propio mediante registros CNAME y a limitar a siete días las cookies fijadas en esas respuestas. WebKit añade en ese punto un aviso de seguridad: quien monta ese tipo de configuración se expone a la toma de control del sitio y al robo de las cookies de sus clientes.

La consecuencia práctica es una sola y conviene decirla sin adornos. En Safari se rompe el reconocimiento a lo largo del tiempo. Una cookie propia configurada para durar un año puede vivir siete días. Los ciclos de compra largos, los embudos con varias visitas y los análisis de valor de cliente a doce meses ven un tramo del recorrido y atribuyen el resto a una visita directa o al último canal que aparece.

Ahí llega siempre la misma pregunta: ¿lo arregla el tracking en servidor? Ayuda en lo que le corresponde. Da control sobre qué datos salen, reduce la dependencia de scripts de terceros en la página y aguanta mejor los bloqueadores de red. Lo que no hace es devolver el reconocimiento de larga duración, porque los recortes de caducidad alcanzan tanto a las cookies escritas desde el navegador como a las que llegan por rutas cuyo destinatario real es un tercero. Vender una infraestructura de servidor como remedio contra ITP es prometer justo aquello que la función está diseñada para impedir.

Lo que sí sostiene la medición es otra cosa: ventanas de análisis más cortas, identificación voluntaria mediante inicio de sesión con permiso, informes agregados o modelados donde antes había recuentos individuales, y expectativas de atribución ajustadas por navegador.

• Mide en ventanas cortas y compara periodos equivalentes, en lugar de arrastrar cohortes de doce meses que en Safari nunca estarán completas.
• Separa los informes por navegador antes de sacar conclusiones. Mezclar Safari con Chrome esconde el efecto y hace que parezca un problema de campaña.
• Da una razón real para iniciar sesión. La identificación voluntaria con permiso es el único reconocimiento estable a largo plazo.
• Usa la Storage Access API cuando un contenido incrustado necesite de verdad la sesión del usuario, en vez de buscar sustitutos de almacenamiento.
• Revisa qué decisiones dependen de la atribución al último clic y cuáles pueden apoyarse en medición agregada o en experimentos.
• Documenta la pérdida esperada por navegador y compártela con quien lee los informes, para que la caída no se interprete como un error de implantación.

• Tratar ITP como un asunto de consentimiento y pedirle a la CMP que lo resuelva.
• Comparar el rendimiento de Safari con el de Chrome sin corregir la diferencia de medición, y recortar presupuesto en el canal equivocado.
• Contratar tracking en servidor con la expectativa de que restituya el reconocimiento de larga duración.
• Dar por hecho que una cookie propia vive lo que dice su fecha de caducidad.
• Confundir el bloqueo de anuncios con la prevención de rastreo al leer una caída en los informes.