Blog

Por qué el ITP de Safari hace que pierdas conversiones (y qué hacer al respecto)

Publicado 2026-07-16

safari itp conversiones cayendointelligent tracking preventionitp cookie 7 díassafari no rastrea conversiones

"No sé por qué, pero los números simplemente no cuadran solo para nuestros usuarios de iPhone." Esta es una queja que crece lentamente pero cada vez con más frecuencia en operaciones publicitarias y optimización de sitios. El tracking funciona correctamente en Chrome, pero el tráfico que pasa por Safari (iPhone, iPad, Mac) vuelve escaso. No recuerdas haber cambiado nada, pero los números simplemente no cierran. La mayoría de las veces, la causa son las restricciones de cookies impuestas por ITP (Intelligent Tracking Prevention), integrado en Safari por defecto.

¿Te suena alguno de estos casos?

Mucho tráfico desde iPhone y Mac, pero solo las conversiones de Safari son bajas
En GA4, la tasa de usuarios nuevos en Safari es anormalmente alta (parece que la misma persona se cuenta como nueva una y otra vez)
Una conversión de un anuncio clickeado hace unos días no se atribuye, aunque está dentro de la ventana de atribución
Los usuarios que deberían tratarse como visitantes recurrentes se ven como visitantes de primera vez cada vez
Los click IDs de anuncios (gclid, fbclid) dejan de funcionar después de unos días

Esta guía explica cómo el ITP de Safari hace que las conversiones caigan o desaparezcan, por qué se rompen la identificación de visitantes recurrentes y la atribución, qué puedes hacer al respecto, y cómo verificar — en tu entorno de producción real — exactamente cómo se están manejando las cookies en este momento.

Primer principio: el ITP no es un "mal funcionamiento", es una función de privacidad

La razón principal por la que esto sale mal es asumir que números más bajos en Safari significan un "tag roto" o un "error de configuración". En realidad, esto es el resultado de una protección de privacidad implementada deliberadamente en Safari (más precisamente, en su motor de navegador, WebKit). No es algo que puedas "arreglar" — es una especificación que necesitas asumir como un dato de partida desde el principio.

Esto es lo que realmente hace el ITP:

Qué hace el ITP	Comportamiento concreto
Limita la vida útil de las cookies first-party	Las cookies first-party establecidas vía JavaScript (`document.cookie`) se eliminan como máximo a los 7 días. Después de una navegación cross-site (link decoration — una redirección con parámetros de query), puede reducirse a 24 horas
Bloquea las cookies third-party	Las cookies establecidas por otros dominios se bloquean por defecto, cortando el tracking cross-site
Restringe la medición cross-site	Restringe progresivamente la identificación de un usuario entre sitios

El punto clave: cuanto más se establece una cookie vía JavaScript, más corta se trata su vida útil. La mayoría de los tags de medición establecen cookies exactamente por esa vía de JavaScript — por eso la base de tu medición choca de frente con el ITP de Safari.

Por qué "desaparece en 7 días" hace caer tus conversiones

La regla del ITP que más importa en la práctica es el límite de la vida útil de las cookies first-party a un máximo de 7 días. Aquí está el porqué de que esto reduzca tus números, dividido en cuatro efectos.

1. Se rompe la identificación de visitantes recurrentes

Los tags de medición almacenan un identificador en una cookie (como _ga para GA4) para reconocer a un usuario. Cuando ese identificador se elimina después de 7 días, la misma persona que regresa el día 8 se vuelve a contar como un "usuario nuevo distinto". El resultado: menos visitantes recurrentes y usuarios nuevos inflados por encima de la realidad.

Error común: "la tasa de usuarios nuevos en Safari está rara, muy alta" — a menudo esto no significa que la adquisición vaya genial. Es una señal de que _ga se está reiniciando y la misma persona se está contando como nueva una y otra vez.

2. La ventana de atribución se reduce en la práctica

Aunque hayas configurado "contar conversiones dentro de los 14 días de un clic en anuncio", si la cookie usada para ese cálculo desaparece en 7 días (a veces 24 horas), la segunda mitad de la ventana simplemente no se puede atribuir. Sin importar cuán larga sea tu ventana de atribución configurada, en Safari solo puedes captar resultados dentro de una ventana sustancialmente más corta.

3. El almacenamiento de `gclid` / `fbclid` expira

Los usuarios que llegan desde anuncios llevan un click ID que indica de qué anuncio provienen (el gclid de Google, el fbclid de Meta). Muchas implementaciones almacenan esto en una cookie first-party vía JavaScript y lo leen de nuevo cuando el usuario convierte más tarde. Pero si esa cookie desaparece en 7 días, una conversión posterior no se puede vincular de vuelta al clic en el anuncio. Terminas con "hubo un clic, pero el resultado no se acredita".

4. Los usuarios nuevos se inflan

Conforme se acumulan los efectos 1 al 3, en Safari la misma persona se cuenta como nueva repetidamente, inflando el conteo de usuarios y la tasa de usuarios nuevos por encima de la realidad. Como el denominador se hincha, también se genera una distorsión secundaria: la tasa de conversión (CVR) se ve más baja de lo que realmente es.

No es solo Safari: todos los navegadores de iOS están afectados

Un detalle que muchos equipos pasan por alto: en iOS (iPhone y iPad), todos los navegadores — Chrome, Firefox, Edge y otros — usan el motor WebKit de Apple por debajo. La política de la App Store de Apple lo exige. Eso significa que las restricciones de cookies del ITP se aplican a todos ellos, no solo a la app de Safari.

En la práctica, esto significa que:

Un usuario que abre tu sitio en "Chrome en iPhone" sigue estando sujeto al mismo límite de 7 días para cookies y al bloqueo de cookies third-party que en Safari
Tus reportes de tráfico específicos de Safari subestiman el alcance real del impacto del ITP — las pérdidas se extienden a todo el tráfico de navegadores iOS
La proporción de usuarios afectados es mucho mayor de lo que sugiere la participación de mercado de Safari por sí sola

Al estimar el impacto, mira el tráfico total de iOS, no solo las sesiones de Safari.

El bloqueo de cookies third-party también entra en juego

Además del límite de vida útil, el ITP bloquea por defecto las cookies third-party establecidas por otros dominios. Históricamente, el retargeting publicitario y la medición cross-domain se apoyaban en estas cookies third-party.

Como Safari no las permite:

Los usuarios no se pueden identificar entre sitios, así que tu audiencia de retargeting se reduce
Vincular una compra completada entre múltiples dominios (por ejemplo, tu sitio principal y un dominio de pagos) se rompe con más facilidad
Cuanto más depende tu medición de tags de dominios externos, mayor es la pérdida en Safari

En resumen, Safari aplica una doble restricción — "cookies first-party de corta vida" más "cookies third-party denegadas por defecto" — así que si corres la misma implementación que en Chrome, no sorprende que los números no cuadren.

Por qué las conversiones caen aunque el tag "se dispare"

El tag se está ejecutando (se dispara), pero los números del reporte caen. Este es el patrón más confuso con el ITP. La razón: el disparo (se envía una solicitud) y la medición (identificación continua basada en cookies) se desacoplan.

En Safari, incluso cuando el tag se dispara correctamente y las solicitudes salen:

Las cookies desaparecen en 7 días, así que no se puede identificar continuamente a la misma persona (los recurrentes se disfrazan de nuevos)
Cuando el almacenamiento del click ID expira, pierdes de vista qué anuncio generó el resultado
Las cookies third-party no están disponibles, así que la conexión cross-site y cross-domain se rompe

Entonces, aunque confirmes "la solicitud se dispara en Network", si la cookie detrás de ella se está acortando o expira, no queda registrada como una conversión continua y utilizable para publicidad. Revisar solo si el tag se dispara nunca revelará un problema de ITP.

El costo oculto: los algoritmos de anuncios se degradan cuando faltan señales

El impacto del ITP va más allá de reportes inexactos — degrada activamente qué tan bien rinden tus campañas publicitarias. Plataformas de anuncios como Google Ads y Meta Ads dependen de señales de conversión para entrenar sus modelos de machine learning. Cuando las conversiones de Safari (y de iOS) no se reportan:

Smart Bidding y la optimización de campañas reciben datos incompletos. El algoritmo ve menos conversiones de las que realmente ocurrieron, así que subvalora audiencias y ubicaciones que sí convierten — especialmente las que se inclinan hacia dispositivos Apple.
Las campañas pueden entrar en estado de "aprendizaje limitado". Cuando las conversiones reportadas de una campaña caen por debajo del umbral de la plataforma (a menudo alrededor de 50 por semana), el algoritmo no puede salir de la fase de aprendizaje, lo que lleva a una entrega errática y costos más altos.
Las audiencias similares (lookalike) pierden precisión. Con un grupo de conversiones sesgado que subrepresenta a los usuarios de iOS, la plataforma construye modelos de audiencia que se inclinan hacia perfiles demográficos no-Apple, potencialmente dejando fuera a tus clientes de mayor valor.

Esto crea un círculo vicioso: menos conversiones reportadas llevan a una peor optimización, lo que lleva a menos conversiones reales, lo que produce aún menos señal para el algoritmo. Romper este ciclo requiere devolver los datos de conversión a la plataforma a través de una ruta que evite las limitaciones de cookies del lado del navegador — ahí es donde entran el server-side tagging y las Conversions API.

Qué puedes hacer: mitigaciones para el ITP

No puedes "apagar" el ITP, pero puedes suavizar su impacto cambiando cómo se establecen las cookies. La dirección es: "reemplazar las cookies establecidas vía JavaScript por un método de mayor duración".

1. Establece cookies first-party desde el servidor (cookies HTTP)

Una cookie first-party establecida por el servidor a través del encabezado de respuesta HTTP (Set-Cookie) — en lugar de vía JavaScript (document.cookie) — tiene muchas menos probabilidades de estar sujeta al límite de 7 días del ITP. Trasladar el almacenamiento del identificador al lado del servidor es la mitigación más fundamental.

2. Usa server-side tagging (server-side GTM)

Esto mueve el procesamiento de los tags fuera del navegador y a través de un servidor que controlas. Como las cookies se pueden manejar del lado del servidor (en tu propio dominio), están menos expuestas a los límites de vida útil y al bloqueo. La implementación es más pesada, pero es una medida de alto impacto contra las pérdidas en Safari.

3. Envía directamente desde el servidor con una Conversions API (CAPI)

En lugar de pasar por el navegador, esto envía las conversiones desde tu servidor directamente a la plataforma de anuncios (como la CAPI de Meta). Como depende menos de la situación de las cookies del navegador, puede recuperar pérdidas en Safari. Combinar una CAPI con enhanced conversions fortalece la tasa de coincidencia al enviar datos first-party con hash junto con el evento de conversión.

Error común: aunque creas haber migrado a server-side, no es raro que la cookie real siga siendo establecida vía JavaScript (no un encabezado Set-Cookie). "Haberlo implementado" y "que la cookie realmente se emita como una cookie HTTP" son dos cosas distintas. Necesitas confirmar, en los encabezados de respuesta de producción, que la cookie realmente es emitida por el servidor.

Cuidado: la regla de coincidencia de IP puede anular tu solución server-side

Desde Safari 16.4, WebKit aplica una verificación adicional: si el prefijo de la dirección IP del servidor que emite el encabezado Set-Cookie no coincide con el prefijo de la dirección IP del servidor de origen del sitio web, la cookie queda limitada a 7 días — incluso si se estableció del lado del servidor.

Esto atrapa un patrón de despliegue común: tu sitio corre en un proveedor de hosting mientras tu contenedor de server-side GTM corre en una nube diferente (Google Cloud, un servicio sGTM administrado, etc.). Como las IPs están en rangos distintos, Safari sobrescribe silenciosamente la expiración de tu cookie de vuelta a 7 días, y tu mitigación deja de funcionar sin que te des cuenta.

Qué revisar:

Confirma que tu endpoint de sGTM y tu sitio web resuelven a direcciones IP dentro del mismo rango de prefijo
Si usas un subdominio CNAME (por ejemplo, data.tusitio.com) que apunta a un servidor de tracking de terceros, la detección de CNAME cloaking de WebKit también puede limitar la cookie
Después del despliegue, verifica la expiración real de la cookie en un navegador Safari de producción — el encabezado Set-Cookie por sí solo no garantiza que el navegador respetó la expiración que configuraste

Lo que revisar en tu propia máquina no te puede decir

Una vez que hayas mitigado el ITP, naturalmente querrás confirmar "¿está funcionando?" Pero probar una sola vez en tu propia máquina tiene dos puntos ciegos específicos del ITP:

Tu entorno no es igual al de un usuario real de Safari. Un navegador de desarrollo difiere de un visitante típico en extensiones, caché y estado de sesión. El ITP en particular se comporta distinto según "¿hubo una navegación cross-site?" y "¿este navegador ya tocó el dominio antes?" — así que en el entorno no limpio de un desarrollador, la expiración a 7 días o el acortamiento a 24 horas que afecta a usuarios reales puede no reproducirse. Terminas con el desajuste de "en mi Safari sí se vinculó" mientras se rompe para un visitante general de primera vez.
Cualquier cosa que involucre un clic en anuncio es difícil de reproducir. Para ver correctamente "cómo trata Safari a alguien que llegó con un gclid de un clic en anuncio y convirtió unos días después", tendrías que hacer clic en un anuncio real para recrear el recorrido y el paso del tiempo — lo cual conlleva el riesgo de una violación de política publicitaria por autoclic.

Los problemas del ITP ocurren en el recorrido del "usuario de producción de Safari de primera vez", no en el de "tu entorno ya mitigado". El hecho de que se vincule bien cuando pruebas es precisamente lo que genera un exceso de confianza.

Cómo verificar "cómo se están manejando las cookies ahora mismo" en producción

Método 1: revisa el método de emisión y la expiración de la cookie en DevTools

La verificación más básica. Tanto en Safari como en Chrome, en DevTools la sección "Application" (o "Storage") → "Cookies" muestra la expiración (Expires / Max-Age) de cada cookie.

¿La expiración de tu cookie de medición (como _ga) se está truncando a menos de 7 días?
¿Esa cookie se establece vía JavaScript o del lado del servidor (HttpOnly)?

Qué te dice: si, en producción ahora mismo, tu cookie de identificador está siendo acortada por el ITP, y si ya fue reemplazada por una emitida del lado del servidor.

Método 2: revisa `Set-Cookie` en los encabezados de respuesta

En la pestaña Network, abre los encabezados de respuesta de la página y revisa si la cookie se emite mediante un encabezado Set-Cookie. Si tu cookie de identificador aparece aquí, eso es evidencia de que se emite del lado del servidor (como cookie HTTP). Si solo se establece vía JavaScript, no aparecerá aquí.

Qué te dice: si tu mitigación de ITP (emisión del lado del servidor) realmente está funcionando, no solo declarada.

Método 3: verifica en Safari, incluyendo el paso del tiempo

La esencia del ITP es que "las cookies desaparecen conforme pasa el tiempo". Así que necesitas revisar no solo justo después de la emisión, sino si el mismo identificador de usuario se conserva unos días después. En particular, en Safari, confirma que la expiración de la cookie no se haya reducido a 24 horas después de una navegación cross-site vía link decoration (con parámetros de query).

Qué te dice: si, bajo condiciones parecidas a producción de una primera visita y una navegación cross-site, el identificador está chocando contra el muro de 7 días / 24 horas.

Un checklist para verificar con confianza

¿Revisaste la expiración de tu cookie de medición (como _ga) en Safari de producción?
¿Esa cookie se establece del lado del servidor (Set-Cookie) o vía JavaScript?
Después de una navegación cross-site (link decoration), ¿la expiración no se redujo a 24 horas?
¿El almacenamiento de gclid / fbclid sigue siendo válido unos días después (no expiró)?
¿La tasa de usuarios nuevos vía Safari no está anormalmente alta (sospecha de recurrentes recontados como nuevos)?
¿El server-side tagging / CAPI realmente están emitiendo y enviando — no solo "implementados"?
¿Verificaste bajo condiciones reales de Safari, no solo en Chrome (no juzgues desde tu entorno no limpio)?

Preguntas frecuentes

P. ¿Cuánto caen las conversiones bajo el ITP de Safari? R. Varía. El tamaño depende en gran medida de la proporción de usuarios de Safari, la duración de tu ventana de atribución, y si tu negocio es de compra recurrente. Lo que es cierto en todos los casos: cuanto más involucra un recorrido revisitar o volver a convertir después de 7 días, mayor es el impacto.

P. ¿Es esto un bug de Safari? ¿Puedo arreglarlo? R. No es un bug — es una especificación, resultado de la protección de privacidad de Safari (WebKit), el ITP. No es algo que "arreglar"; la respuesta realista es mitigar el impacto con emisión de cookies del lado del servidor, una CAPI, y demás.

P. Entonces, ¿Chrome está bien? R. Chrome permitió cookies third-party durante mucho tiempo, pero el movimiento hacia mayor privacidad es común a todos los navegadores. El ITP es un nombre específico de Safari, pero prepararte para "cookies first-party de corta vida" y "cookies third-party restringidas" te conviene más allá de Safari, hacia el futuro.

P. Estoy almacenando gclid, pero los resultados no se atribuyen. ¿Por qué? R. Si almacenas gclid en una cookie first-party vía JavaScript, el ITP puede eliminarla después de 7 días (24 horas tras una navegación cross-site). Si la conversión ocurre después de esa ventana, no se puede atribuir. La solución es cambiar al almacenamiento del lado del servidor — consulta tracking de conversiones con datos first-party para una estrategia más amplia sobre cómo reducir la dependencia de identificadores gestionados por el navegador.

P. ¿El server-side tagging lo resuelve por completo? R. Reduce drásticamente las pérdidas, pero no "por completo". Si un error de implementación deja la cookie aún establecida vía JavaScript, o falta la conexión cross-domain, el efecto es limitado. Después de implementarlo, es esencial confirmar que realmente se está emitiendo una cookie HTTP en producción.

P. ¿El impacto del ITP es el mismo para GA4 y para anuncios? R. La raíz es la misma (acortamiento y bloqueo de cookies), pero se manifiesta de forma diferente. En GA4 aparece como inflación de usuarios nuevos y fragmentación de sesiones; en anuncios aparece como expiración de click ID y atribución perdida. Es más seguro revisar los dos por separado.

Conclusión: verifica con "el usuario de Safari de producción de primera vez", no con "tu entorno limpio"

El problema de las conversiones que caen por el ITP de Safari no se puede diagnosticar observando si el tag se dispara. Lo que importa es verificar — bajo condiciones reales de Safari — cómo se emiten realmente las cookies, cuánto duran, y si la identificación se mantiene conforme pasa el tiempo. Esto es una especificación de privacidad, no un mal funcionamiento, así que asúmelo como un dato de partida, mitígalo con emisión del lado del servidor y demás, y luego mide si "realmente está funcionando".

ConversionOK ejecuta tu página en vivo en un navegador independiente y aislado e intercepta las solicitudes reales enviadas y las cookies emitidas (su método de emisión y expiración), y luego las verifica — sin necesidad de hacer clic en tu propio anuncio y sin interferencia de tu entorno de oficina. Empieza con una verificación estática gratuita para confirmar cómo se maneja el punto de entrada de tu medición bajo condiciones reales de navegador.