Atribución de clics tras Safari ITP: lo que aún funciona en 2026

Apple lanzó la primera versión de Intelligent Tracking Prevention en septiembre de 2017. Se enmarcó como una característica de privacidad, lo cual es preciso. También fue un desmantelamiento sistemático de cada solución alternativa que la industria de la tecnología publicitaria había ensamblado desde que el ecosistema de cookies de terceros empezó a agrietarse alrededor de 2013. Cada nueva versión de ITP cerraba la escotilla de escape que los marketers habían encontrado en la anterior. Para cuando ITP 2.3 se lanzó en 2019, la secuencia de cierres había sido lo suficientemente exhaustiva como para que los únicos caminos de atribución que aún funcionaban de forma fiable en Safari fueran aquellos que nunca habían dependido del tracking entre sitios en absoluto.

Este post recorre esa secuencia por orden de fecha: qué rompió cada versión, qué solución alternativa estaba específicamente diseñada para cerrar, y dónde deja eso a la atribución en 2026. El post complementario Atribución sin cookies explicada cubre el panorama más amplio a través de los navegadores; este es específicamente sobre Safari y específicamente sobre el patrón de cadena de redirección que sobrevive a todo.

TL;DR#

• ITP 2.0 (2018) bloqueó todo el acceso a almacenamiento de terceros en dominios entre sitios, matando el camino estándar de atribución por píxel de anuncio en Safari.
• ITP 2.1 (2019) limitó las cookies de primera parte establecidas por JavaScript a 7 días, terminando con las ventanas de atribución de un año establecidas vía gestores de tags.
• ITP 2.2 y 2.3 eliminaron parámetros de decoración de enlaces y degradaron las cabeceras Referer, cerrando las últimas soluciones de cadena de consulta.
• Un enlace corto en tu propio dominio establece una cookie de primera parte del lado del servidor en el momento de la redirección - este es el único patrón que sobrevive a ITP en todas sus versiones y te da una ventana de atribución fiable de 7 días en Safari.

La línea de tiempo de ITP: un desglose versión por versión#

ITP no llegó completamente formado. Se lanzó de forma incremental, con cada versión apuntando a una clase específica de solución alternativa que la industria había desarrollado en respuesta a la versión anterior. Entender la secuencia importa porque la forma técnica de lo que sobrevive está definida por lo que se cerró y cómo.

ITP 1.0 - septiembre de 2017. El primer lanzamiento clasificó dominios como "trackers entre sitios" basado en frecuencia de rebote y señales de interacción del usuario. Los dominios clasificados como trackers tenían sus cookies particionadas - podían establecerse, pero solo leerse en un contexto entre sitios si el usuario había interactuado directamente con el dominio del tracker en las últimas 24 horas. Para un dominio como un píxel de analytics estándar al que los usuarios nunca navegan directamente, la ventana de 24 horas era un bloqueo de facto.

ITP 1.1 - marzo de 2018. Los anunciantes respondieron a 1.0 enrutando la atribución a través de cadenas de redirección que tocaban el dominio del tracker como aterrizaje de primera parte antes de rebotar al destino. Esto daba a los usuarios una "visita directa" al dominio del tracker, lo que reiniciaba el reloj de interacción. ITP 1.1 identificó este patrón - conocido como el bounce tracker - y eliminó el crédito de interacción que generaban las cadenas de redirección de rebote. Los dominios que parecían existir únicamente para el patrón de rebote y redirección perdieron su estatus de interacción.

Qué rompió ITP 2.0#

ITP 2.0 se lanzó en septiembre de 2018. Fue la ruptura estructural. Donde 1.x había particionado cookies de terceros, 2.0 fue más allá: eliminó el acceso a almacenamiento de terceros por completo para dominios clasificados. Cookies, localStorage, IndexedDB, datos en caché - todo fue bloqueado para cualquier dominio que ITP clasificara como tracker entre sitios.

El efecto práctico en la tecnología publicitaria fue significativo. El Facebook Pixel, el tag de conversión de Google Ads y la mayoría de los píxeles de retargeting dependen de leer una cookie entre sitios para vincular un clic a una conversión. En Safari después de ITP 2.0, esa lectura falló. Los informes propios de Meta en el momento indicaron una brecha del 15-25% en la cobertura de eventos en el tráfico de Safari - clics y conversiones que el píxel veía en Chrome o Firefox simplemente no aparecían desde usuarios de Safari.

El bloqueo de almacenamiento no se limitó a las cookies. Los scripts que intentaban persistir identificadores en localStorage bajo un dominio clasificado como tracker, o usar Service Workers para persistencia, fueron igualmente bloqueados. La intención de 2.0 era hacer que la capa de almacenamiento de terceros fuera estructuralmente no disponible para fines de tracking, no solo romper una técnica específica.

Qué rompió ITP 2.1#

Si 2.0 mató la atribución de terceros, ITP 2.1 (marzo de 2019) apuntó a la solución alternativa que había crecido en respuesta: la atribución por cookie de primera parte vía inyección de gestor de tags.

La lógica era sólida. Si el píxel de terceros estaba bloqueado, aún podías persistir la atribución escribiendo una cookie de primera parte en el dominio propio del anunciante vía JavaScript - típicamente inyectado por un gestor de tags como GTM. La cookie era de primera parte y por lo tanto no sujeta a las restricciones de almacenamiento de terceros de ITP. Muchos equipos se habían mudado a ventanas de atribución de un año establecidas de esta manera, razonando que un document.cookie de primera parte era seguro.

ITP 2.1 limitó todas las cookies establecidas vía document.cookie - independientemente del estatus de primera o tercera parte - a un máximo de 7 días. El límite se aplicaba específicamente a cookies establecidas por script; las cookies establecidas vía la cabecera de respuesta HTTP Set-Cookie no se vieron afectadas por 2.1. La distinción es precisa y consecuente: document.cookie = "..." en JavaScript está limitado a 7 días. Set-Cookie: ...; Max-Age=31536000 desde una respuesta del servidor no lo está.

La víctima inmediata fue la configuración de atribución basada en GTM. GTM escribe cookies a través de JavaScript en la página. Esas cookies, independientemente de su expiración declarada, ahora expiraban en 7 días en Safari. Un usuario que hizo clic en un enlace de campaña un martes y convirtió el miércoles siguiente estaba fuera de la ventana de atribución. La ventana de atribución por cookie de primera parte de un año a la que los equipos habían migrado después de ITP 2.0 se había ido.

Qué rompió ITP 2.2#

ITP 2.2 ajustó dos áreas. Primero, redujo el límite de cookies de JavaScript a 24 horas en el caso específico donde la página de destino estaba enlazada desde un dominio que ITP había clasificado como tracker entre sitios. Si un usuario hacía clic en un enlace desde la página de un dominio clasificado, las cookies de primera parte en el sitio de destino establecidas vía JavaScript se limitaban a 24 horas - no 7 días. El límite de 7 días permanecía para caminos de referrer no rastreados, pero el límite de 24 horas se aplicaba cuando la cadena de clic incluía un dominio clasificado.

Segundo, y más ampliamente notado, ITP 2.2 introdujo límites en la decoración de enlaces. Las plataformas de anuncios y herramientas de analytics habían desarrollado un patrón de añadir identificadores de atribución como parámetros de consulta a las URLs de destino - gclid para Google Ads, fbclid para Meta, msclkid para Microsoft Advertising. Bajo ciertas condiciones, si el dominio de enlace estaba clasificado como tracker, ITP empezó a eliminar esos parámetros antes de que la página cargara o limitando las cookies que se podían establecer en respuesta a su presencia.

Este fue un ataque directo al camino de atribución basado en gclid al que los equipos habían pivotado después de 2.0 y 2.1. El razonamiento fue explícito: Apple consideró el tracking de usuarios basado en parámetros de consulta como equivalente en impacto de privacidad al tracking basado en cookies, y las mismas restricciones deberían aplicarse.

Qué rompió ITP 2.3#

ITP 2.3 (septiembre de 2019) cerró dos brechas restantes.

La primera fue la degradación del referrer en la navegación entre sitios. Donde las versiones anteriores se habían centrado en el almacenamiento y los parámetros de enlace, 2.3 abordó la cabecera del referrer - el valor Referer que una página recibe cuando un usuario navega a ella desde otro sitio. Para navegaciones entre sitios desde dominios clasificados, ITP 2.3 degradó el referrer a solo origen: https://classified-domain.com/ en lugar del completo https://classified-domain.com/path?campaign=spring&source=email. La ruta y la cadena de consulta, que a menudo contenían contexto de atribución, fueron eliminadas.

El segundo cambio extendió la lógica de limitación de almacenamiento. Además del límite de 7 días en cookies de JavaScript, ITP 2.3 aplicó un límite de almacenamiento después de un único clic entre sitios desde un dominio clasificado: todo el almacenamiento del lado del cliente en el sitio de destino - cookies, localStorage, IndexedDB - estaba sujeto a limitación. La intención era cerrar una clase de patrones de atribución con estado donde el mero acto de ser enlazado desde un dominio clasificado iniciaría una cuenta atrás sobre la capacidad del destino para persistir datos.

Juntos, 2.2 y 2.3 cerraron las tres rutas principales que los equipos habían usado después de 2.0 y 2.1: parámetros de decoración de enlace, atribución basada en referrer y acumulación de almacenamiento a través de cadenas de clic entre sitios.

Qué sobrevive#

La secuencia de ITP fue metódica, pero fue dirigida al tracking entre sitios. Los patrones que sobreviven son aquellos que son genuinamente de primera parte - donde los datos de atribución se capturan en tu propio dominio, se establecen vía tu propio servidor, y nunca pasan a través del almacenamiento del dominio de un tercero.

Cookies de primera parte establecidas por el servidor. El límite de cookies de ITP 2.1 se aplica a escrituras document.cookie vía JavaScript. Las cookies establecidas por un servidor vía la cabecera de respuesta HTTP Set-Cookie retienen su expiración declarada. La restricción clave es que la cookie debe establecerse en el dominio que el servidor controla.

Reenvío de eventos del lado del servidor. Si el identificador de clic se captura en el momento de la redirección y se almacena del lado del servidor, la búsqueda de atribución en el momento de la conversión es una operación servidor a servidor. Ninguna cookie del navegador necesita sobrevivir 7 días; el click ID está en tu base de datos. Esta es la arquitectura detrás del tracking de conversiones del lado del servidor y el enfoque que Meta CAPI, GA4 Measurement Protocol y TikTok Events API están todos diseñados para soportar.

Emparejamiento determinista vía email o teléfono hasheado. Cuando un usuario está autenticado o ha enviado una dirección de email, la conversión puede emparejarse al clic original por hash de email en lugar de por identidad de cookie. Este camino es independiente de ITP por completo - nunca dependió del almacenamiento del navegador. La limitación es la cobertura: solo funciona para usuarios que se han identificado a sí mismos dentro de la ventana de atribución.

El contexto técnico completo para estos patrones está en Atribución sin cookies explicada.

El patrón de redirección de enlace corto#

Los enlaces cortos en tu propio dominio - no en un dominio de acortador compartido - te dan el camino de cookie establecida por el servidor en una forma que funciona naturalmente con el tráfico de campaña.

La mecánica es directa. Cuando un usuario hace clic en un enlace de campaña apuntando a go.acme.example/spring26, la petición llega a un manejador de edge en go.acme.example. El manejador de edge captura el evento de clic, genera un click ID, y establece una cabecera Set-Cookie en la respuesta de redirección - una cookie de primera parte establecida por el servidor en acme.example. Luego emite el 302 a la URL de destino con el click ID añadido como parámetro de consulta.

Debido a que la cookie se establece vía Set-Cookie por el servidor en el momento de la redirección, el límite de 7 días de JavaScript de ITP 2.1 no se aplica. La cookie retiene la expiración que el servidor estableció. En Safari, con ITP 2.3 completamente activo, una cookie establecida por el servidor en go.acme.example sobrevive durante toda la ventana configurada. Establecemos una expiración de 7 días por defecto en Elido porque eso coincide con la restricción más restrictiva de ITP para cookies establecidas por JS de todos modos, y la cookie establecida por el servidor se mantiene durante los 7 días completos.

La página de destino luego lee el click ID desde la cookie o desde el parámetro de consulta (cualquiera que esté disponible), lo escribe en los atributos del carrito o pedido, y el evento de conversión lo lleva del lado del servidor en el momento de la compra. Ningún dominio entre sitios está involucrado. La cookie está en tu dominio. La búsqueda de atribución es una operación del lado del servidor. ITP no tiene nada que bloquear.

Por eso el soporte de dominio personalizado en un enlace corto importa para la atribución: no solo para la marca sino para la clasificación de primera parte de la cookie. Un dominio de acortador compartido como bit.ly o short.io es un origen diferente a tu sitio web. Una cookie establecida en bit.ly es una cookie de terceros en acme.example; ITP 2.0 la bloquea. Una cookie establecida en go.acme.example es de primera parte; nada en ITP la toca. La página solutions/marketers cubre el flujo de atribución de campaña de extremo a extremo.

Para un contexto GDPR más profundo sobre qué datos de clic puede procesar legítimamente un acortador y cómo configurar la minimización de datos en el esquema de eventos de clic, ver GDPR para acortadores de URL.

Qué aún no funciona#

La honestidad es más barata que vender en exceso una solución parcial.

Atribución view-through entre dominios. Si un usuario ve un anuncio en publisher.example sin hacer clic y más tarde convierte en advertiser.example, no hay camino seguro de ITP para esa atribución. View-through requiere inherentemente una señal entre sitios desde la impresión hasta la conversión. Safari lo bloquea, y los enfoques de reenvío del lado del servidor anteriores están iniciados por clic - requieren el clic para establecer la cookie de primera parte o escribir el click ID.

Stitching en tiempo real para usuarios no autenticados. Si un usuario convierte sin nunca iniciar sesión o enviar una dirección de email, el único identificador disponible es el click ID de la cookie o el parámetro de consulta. Si la cookie ha expirado (más allá de 7 días después del primer clic, o 24 horas si se aplica el límite más estricto de 2.2), el stitch se pierde. El almacenamiento de click ID del lado del servidor resuelve esto para conversiones dentro de la ventana. No lo resuelve para conversiones que llegan después de que la ventana se haya cerrado.

Ventanas de atribución más largas que 7 días en Safari para first-touch. Si tu negocio tiene un ciclo de compra medido en semanas o meses - común en SaaS B2B, e-commerce de alto valor, servicios financieros - la ventana de 7 días en cookies de primera parte de Safari significa que una fracción sustancial de conversiones no será atribuible a su clic originario. Para estos modelos de negocio, el camino determinista de hash de email es la única opción; la atribución probabilística en Safari no es lo suficientemente fiable para actuar sobre ella.

Fingerprinting como sustituto. El fingerprinting de canvas, el fingerprinting de audio y la enumeración de fuentes son soluciones alternativas que intentan re-identificar usuarios a través de sesiones sin cookies. Apple se ha movido explícitamente para reducir la superficie de fingerprinting en Safari. Las notas de lanzamiento de ITP 2.3 hacen referencia a "protección adicional contra otras formas de tracking entre sitios", y la dirección ha continuado en cada lanzamiento posterior de Safari. El fingerprinting también lleva un riesgo legal material bajo el Artículo 6 de GDPR, como se explora en GDPR para acortadores de URL. No es un reemplazo viable para los patrones descritos arriba.

Punto de partida práctico#

El patrón de redirección funciona. Configura un dominio personalizado en tu workspace de enlaces cortos (go.yourdomain.example), enruta el tráfico de campaña a través de él, y configura tu página de destino para que lea el parámetro de consulta elido_click o la cookie de primera parte y lo escriba en los atributos de tu pedido o carrito antes de que el usuario convierta. Luego enruta las conversiones del lado del servidor a las plataformas de anuncios vía la API de conversiones. La ventana de 7 días cubre la mayoría de los caminos de clic a conversión para la mayoría de los tipos de campaña.

Para la configuración de reenvío de conversiones - Meta CAPI, GA4 Measurement Protocol, la semántica de reintento y la forma de deduplicación - tracking de conversiones del lado del servidor es el compañero técnico de este post. Para la superficie del producto, funciones de tracking de conversiones es el punto de partida.

ITP no mató la atribución. Mató una arquitectura específica de atribución - la construida sobre el almacenamiento persistente entre sitios y la acumulación indiferenciada de datos a través de dominios que no controlas. La arquitectura que la reemplazó es más defendible, no menos.