Protección contra el rastreo de Safari 27: qué significa para la medición de conversiones

Safari 27 salió como beta para desarrolladores en junio de 2026. Las notas oficiales de la versión hablan de correcciones en CSS y mejoras en la visualización. Nosotros hemos ido más allá y hemos revisado el código abierto de WebKit en github.com/WebKit/WebKit, la infraestructura de privacidad que realmente controla cómo gestiona Safari las solicitudes de seguimiento. Esto es lo que hemos descubierto.

Este artículo es la continuación de nuestro análisis de Safari 26. Si quieres conocer los detalles sobre la «Protección avanzada contra huellas digitales» y cómo funciona la «Protección contra el seguimiento de enlaces», empieza por ahí. En este artículo te contamos las novedades de la versión 27.

Las notas oficiales de la versión de Safari 27 beta de Apple están disponibles en la página web para desarrolladores de Apple.

Un cambio estructural que empeora todo lo demás

Antes de entrar en detalles, hay una conclusión de la fuente que es importante para que entiendas todo lo que viene a continuación.

Las normas de privacidad de Safari no están integradas en el archivo binario del navegador. Qué identificadores de clic se eliminan, qué scripts se restringen, qué direcciones IP se bloquean: Apple almacena todo eso en una biblioteca del sistema independiente que se actualiza al margen del propio Safari. Apple puede añadir un nuevo dominio de seguimiento, un nuevo parámetro de identificador de clic o un nuevo rango de IP de una red publicitaria a la lista de bloqueados sin necesidad de lanzar una actualización del navegador. Cualquier dispositivo que tenga Safari instalado puede recibir las normas actualizadas de forma silenciosa en segundo plano.

La consecuencia práctica es que, aunque Apple no anuncie nada sobre el seguimiento en una versión concreta de Safari, las normas que rigen tus campañas pueden cambiar en cualquier momento. La actualización de Safari 27 amplía esas listas, pero es posible que la próxima actualización de las mismas llegue sin ningún anuncio público.

La protección contra el rastreo de enlaces ahora abarca más plataformas

Safari lleva eliminando los parámetros de seguimiento conocidos de las URL desde la versión 17. En la navegación privada, en Mail y en Mensajes, los ID de clic desaparecen antes incluso de que se cargue la página de destino. La lista de parámetros afectados crece con cada nueva versión.

Como novedad en Safari 27, se añaden tres plataformas más al filtro:

• Hilos: se ha eliminado «xmt»
• YouTube: le quitan el «si»
• X (antes Twitter): se eliminan twclid, cn y cxt

Ya se han tratado los ID de clics de Google y Meta. Añadir Threads, YouTube y X es importante para cualquiera que lleve a cabo campañas de pago en esas plataformas.

twclid es el identificador principal de clics de X, el mismo papel que desempeña gclid para Google Ads. si es un identificador de origen de compartición y de sesión que se añade a los enlaces para compartir de YouTube. No es un identificador de clic pagado como lo es twclid, pero su eliminación sigue quitándole el contexto de origen al tráfico de YouTube en las sesiones de Safari. La pérdida de cualquiera de los dos en las sesiones de Safari genera la misma brecha de atribución que los anunciantes de Google Ads ya conocen por cómo gestiona Safari el gclid.

La LTP en la navegación normal (no privada) de Safari todavía se está implantando gradualmente. A partir de Safari 26, los ID de clics seguían transmitiéndose en las sesiones estándar. La estrategia de Apple ha sido ampliar primero la lista y, después, aplicar la norma a la navegación normal en una actualización posterior. Los parámetros ya están implementados. El siguiente paso lógico es aplicar la norma en todas las sesiones.

AFP no es un bloque binario

La mayoría de los artículos sobre la «Protección avanzada contra el rastreo mediante huellas digitales» la describen diciendo que «Safari bloquea estos scripts». El código fuente ofrece una visión más detallada, y eso es importante para entender qué partes de tu sistema de rastreo dejan de funcionar realmente.

Cuando Apple clasifica un script como herramienta de identificación, no se limita a bloquearlo. Le asigna a ese script un conjunto específico de permisos: una lista de aquello a lo que el script puede y no puede acceder. Las categorías que Apple puede revocar de forma individual incluyen:

• Parámetros de consulta de la URL (ID de clics, valores UTM)
• Datos de referencia (fuente de tráfico)
• Acceso a las cookies
• Acceso al almacenamiento local
• API de Canvas (una superficie habitual para el fingerprinting)
• Tamaño de la pantalla y dimensiones de la ventana de visualización
• Información sobre la concurrencia del hardware
• Solicitudes de red

Un script clasificado podría perder el acceso a los parámetros de la URL y a los datos de referencia, aunque seguiría pudiendo realizar solicitudes de red. O bien, podría tener restringido el uso de las API de Canvas y de audio, pero seguiría teniendo acceso a las cookies. El impacto concreto depende de qué permisos te revoque Apple para ese script en concreto.

La etiqueta LinkedIn Insight Tag (snap.licdn.com) está en la lista de «fingerprinting». Para el seguimiento de conversiones, las restricciones más perjudiciales son la pérdida del acceso a los parámetros de consulta (no se puede leer el ID del clic) y la pérdida de los datos de referencia (no se puede atribuir la fuente del tráfico). Puede que el script siga pudiendo enviar una solicitud de red a los servidores de LinkedIn, pero sin los identificadores necesarios para relacionar una conversión con un clic, los datos que envía no se vinculan a ninguna campaña.

En esa misma lista figuran Tealium, Segment, DPG Media y Blueonic.

Cuando una CDP como Tealium o Segment se clasifica como herramienta de «fingerprinting», todas las etiquetas que activa heredan las mismas restricciones. Un píxel de conversión implementado a través de un contenedor de CDP restringido pierde el mismo acceso que un script clasificado directamente.

Apple está usando las propias listas de detección de anuncios de Chromium

La fuente muestra que el Monitor de recursos de Safari, la capa que bloquea puntos finales de seguimiento completos en lugar de solo parámetros, compila sus reglas en el mismo formato que usan las extensiones de bloqueo de contenido de Safari. Los datos reales del filtro provienen de la biblioteca del sistema de Apple.

Al revisar las reglas en un dispositivo con Safari 27 beta instalado, los patrones de bloqueo coinciden con las entradas de filtro de la infraestructura de detección de anuncios de código abierto de Chromium. Apple está utilizando los mismos datos de filtro que Google creó y puso a disposición como código abierto para los navegadores basados en Chromium.

Fuente: https://github.com/chromium/chromium-ads-detection

El bloqueo se ha trasladado por debajo de la capa de aplicación

Las versiones anteriores de la protección contra el rastreo de Safari funcionaban en la capa de aplicación. Los scripts se bloqueaban o se restringían antes de que pudieran ejecutarse, o las solicitudes de red se bloqueaban por nombre de dominio. Safari 27 traslada parte del bloqueo a la capa de transporte de red, que funciona por debajo de todo lo que hay en la página.

Cuando un script intenta enviar datos de conversión, abre una conexión de red con un servidor de destino. Safari 27 intercepta esa conexión antes de que se complete. No lo hace analizando el contenido de la solicitud, sino comparando la dirección IP de destino con una lista de subredes de redes publicitarias conocidas.

Por ejemplo, bat.bing.com es el punto final UET de Bing. Se resuelve en la infraestructura publicitaria de Microsoft. Si el rango de direcciones IP del servidor publicitario de Microsoft está en la lista de bloqueados, la conexión se corta antes de que ningún dato salga del navegador. No importa de dónde provenga el script, desde qué dominio se haya cargado ni cómo se haya construido la solicitud.

Las configuraciones de proxy de primera parte son una solución habitual en la que se carga un script de seguimiento desde tu propio subdominio. Esa solución no sirve en este caso. El script se carga desde tu dominio, pero aún así tiene que enviar sus datos a los servidores de una plataforma publicitaria. Esos servidores tienen direcciones IP fijas. Y es precisamente la conexión a esas direcciones IP lo que bloquea Safari.

En el código fuente también hay indicios de que existe una categoría aparte de dominios configurados de forma fija como bloqueables sin condiciones, independientemente de la configuración de privacidad que haya activado el usuario. El mecanismo se ve en el código; el contenido específico de esa lista no, ya que está en un archivo de Apple que no se ha publicado. Considera que la existencia de la categoría es un hecho comprobado y que su alcance exacto no está verificado.

El historial de bloqueo de Safari, capa por capa

Cada versión importante añade una nueva superficie.

• 2017: La ITP introdujo restricciones sobre las cookies y plazos de caducidad
• Safari 17: ATFP ha añadido el bloqueo de red a nivel de dominio en la navegación privada y la eliminación del identificador de clics de los enlaces
• Safari 26: La AFP ha añadido la clasificación de scripts mediante huellas digitales en todos los modos de navegación, con la posibilidad de revocar permisos para cada script
• Safari 27: bloqueo de rangos de IP en la capa de transporte de red, un filtro de ID de clics ampliado y CDP en la lista de huellas digitales

Las medidas de protección anteriores se centraban en lo que los scripts podían leer o almacenar. El bloqueo a nivel de red se centra en adónde pueden ir los datos. Puedes cambiar el nombre de un archivo de script, una ruta URL o un subdominio propio. ¿Y las direcciones IP en las que están alojados los servidores de anuncios de Microsoft o LinkedIn? Esas no cambian.

Dónde encaja TAGGRS

El GTM server-side cambia la arquitectura de tal forma que las restricciones a nivel del navegador de Safari dejan de tener importancia. No porque eluda nada de forma ingeniosa, sino porque las solicitudes de seguimiento que bloquea Safari nunca pasan por el navegador.

Con una configuración estándar del lado del cliente, el navegador ejecuta el script, lee lo que necesita de la página y envía la solicitud de conversión al punto final de una plataforma publicitaria. La capa de red de Safari detecta esa conexión saliente y la bloquea.

Con sGTM, el navegador envía una solicitud a tu propio servidor, tu propio subdominio, tu propia IP. A partir de ahí, el servidor se encarga de todo. Procesa los eventos y reenvía los datos a Google, Meta, LinkedIn o Bing a través de llamadas de servidor a servidor que nunca pasan por el navegador del usuario. Safari no tiene nada que interceptar.

bat.bing.com y snap.licdn.com están bloqueados a nivel de dominio y de IP. Con sGTM, tu configuración nunca accede a esas URL desde el navegador. Las conexiones con las plataformas publicitarias se realizan en el servidor una vez que ya se ha registrado la interacción del navegador.

El script de seguimiento mejorado de TAGGRS añade otra capa de protección: cifra la solicitud que va del navegador al servidor, lo que evita que los bloqueadores de anuncios, al comparar patrones, identifiquen la solicitud como tráfico de seguimiento antes incluso de que salga de la página.

En el caso de LinkedIn, la solución práctica es usar LinkedIn CAPI a través del contenedor sGTM, sustituyendo el Insight Tag por una llamada de conversión server-side. Para Bing, se usa el equivalente de la API de Microsoft Ads. Ambas opciones eliminan la dependencia de la ejecución de scripts en el navegador, algo que Safari ahora bloquea.

Las ventajas se acumulan. Como la solicitud de conversión nunca llega al punto final de una plataforma publicitaria desde el navegador, la capa de red de Safari no tiene nada que interceptar, y el bloqueo simplemente no tiene dónde actuar.

Además, tienes el control total sobre los datos propios : el evento llega primero a tu servidor, así que tú decides qué se reenvía y cómo. Los tiempos de carga mejoran, ya que las etiquetas pesadas del lado del cliente desaparecen de la página. La configuración es más duradera que las soluciones provisionales del navegador. Cuando Apple amplía una lista de bloqueo o lanza una nueva versión de Safari, no hace falta volver a parchear una arquitectura server-side, porque, para empezar, nunca ha dependido de la ejecución en el navegador.

Lo que ya está en peligro

La versión estable de Safari 27 vendrá incluida con iOS 27 y macOS 27, cuyo lanzamiento está previsto para finales de 2026. El análisis del código fuente permite identificar los riesgos antes de que la actualización se lance al público.

Campañas de YouTube y X: «si» y «twclid» están incluidos en el nuevo filtro de identificadores de clics. La atribución para los usuarios de Safari que hagan clic en enlaces de YouTube o en anuncios de X tendrá lagunas una vez que la aplicación de LTP se amplíe a la navegación habitual. YouTube es una de las plataformas publicitarias con más tráfico. «twclid» es el identificador de clics principal de X. Ninguno de los dos es un caso aislado.

Las CDP que gestionan etiquetas de conversión —Tealium y Segment están en la lista de scripts de huellas digitales—. Cualquier píxel de conversión o etiqueta de remarketing que se active a través de una CDP restringida hereda las mismas restricciones de acceso. La propia CDP se convierte en el punto de fallo, no la etiqueta en sí.

LinkedIn Insight Tag y Bing UET: el Insight Tag está en la lista de «fingerprinting» y se le ha revocado el acceso a los parámetros de consulta y al referrer. El punto final de Bing UET está bloqueado tanto a nivel de dominio como por subred de IP. Ambos casos se han confirmado tras analizar la fuente.

Configuraciones de proxy propias: el bloqueo a nivel de red de Safari comprueba la IP de destino, no el dominio de origen del script. Un proxy en tu propio dominio sigue reenviando datos a los servidores de una plataforma publicitaria. Lo que se corta es la conexión con esos servidores.

Cualquier solución alternativa basada en el navegador, como los proxies propios, los scripts renombrados o los nuevos subdominios, queda fuera de los límites de lo que Safari bloquea actualmente. El seguimiento server-side saca los datos de conversión por completo de esas superficies, así que a Safari no le queda nada que interceptar.

Si quieres ver cómo funciona esa configuración en la práctica, nuestro análisis de Safari 26 te explica con detalle la arquitectura de sGTM.

¿Estás listo para empezar con el seguimiento server-side? Crea una cuenta gratuita en TAGGRS.

Preguntas frecuentes

¿De verdad bloquea Safari los rastreadores?

Sí. Safari bloquea en varios niveles: restricciones de cookies (Prevención Inteligente de Seguimiento), bloqueo de red a nivel de dominio en la navegación privada (Navegación Privada 2.0), restricciones a los scripts de huellas digitales (notas de la versión 26.0 de Safari según WebKit), y bloqueo de rangos de IP en la capa de transporte de red en Safari 27 (confirmado mediante el análisis del código fuente de WebKit, aunque aún no aparece en las notas de lanzamiento públicas de Apple). El seguimiento basado en el navegador para los usuarios de Safari es cada vez menos fiable con cada nueva versión. Las configuraciones server-side no se ven afectadas porque ninguna solicitud de seguimiento pasa por el navegador.

¿Qué parámetros elimina Safari 27 de las URL?

En el modo de navegación privada y cuando se abren enlaces desde «Correo» o «Mensajes», Safari elimina una lista cada vez mayor de parámetros de identificación de clics mediante la Protección contra el seguimiento de enlaces. Apple explica el mecanismo aquí: los parámetros de consulta de seguimiento conocidos se eliminan antes de la navegación, y los scripts de terceros de la página de destino no pueden leer la URL completa. Novedades en Safari 27: xmt (Threads), si (YouTube), twclid, cn, cxt (X/Twitter). Entre los parámetros que ya se habían eliminado están gclid, fbclid y msclkid. Si quieres saber por qué son tan importantes los identificadores de clic en las URL, échale un vistazo a la publicación de WebKit sobre ITP 2.3 y la decoración de enlaces. Los parámetros UTM estándar (utm_source, utm_medium, utm_campaign) no se ven afectados.

¿Estos cambios también afectarán a la navegación habitual en Safari?

La protección contra el seguimiento de enlaces en la navegación normal (no privada) se está implantando gradualmente. A partir de Safari 26, los identificadores de clics siguen transmitiéndose en las sesiones estándar. Safari 27 amplía la lista de filtros, pero Apple suele aplicar estas medidas por fases. Los usuarios ya pueden activar las protecciones más estrictas de la navegación privada para todas las sesiones mediante la «Protección avanzada contra el seguimiento y las huellas digitales » (configurada en «Toda la navegación» en los ajustes de Safari; consulta la guía de Safari de Apple). La aplicación completa en todas las sesiones sin necesidad de activar esa opción es el objetivo hacia el que se ha ido moviendo Apple.

¿Qué es AFP? ¿Bloquea por completo un script?

AFP (Advanced Fingerprinting Protection) clasifica los scripts como herramientas de identificación y aplica un conjunto específico de restricciones de acceso a cada uno de ellos. No se trata de un bloqueo total. El anuncio de Safari 26.0 de WebKit describe lo que se restringe: las API que revelan características del dispositivo (tamaño de la pantalla, concurrencia de hardware, canvas, audio), el almacenamiento gestionado por scripts (cookies, localStorage) y los datos de navegación (parámetros de consulta, document.referrer). Apple puede revocar algunas de estas restricciones y dejar otras intactas. El impacto práctico depende de qué acceso revoque Apple para ese script concreto. La versión original de la navegación privada se explica en la sección «Protección avanzada contra el fingerprinting» de WebKit.

¿Cuál es la diferencia entre AFP y ATFP?

La AFP (Protección avanzada contra el fingerprinting) limita el acceso de los scripts de fingerprinting clasificados. La ATFP (Protección avanzada contra el rastreo y el fingerprinting) es la opción de Safari visible para el usuario que, cuando está activada, amplía las protecciones de la Navegación privada —incluida la eliminación de parámetros de enlaces y el bloqueo de rastreadores a nivel de dominio— a la navegación normal. La publicación de WebKit sobre la Navegación privada 2.0 aborda ambos aspectos: AFP se encarga de las restricciones a los scripts de huellas digitales, mientras que el botón «Protección avanzada contra el seguimiento y las huellas digitales» controla si el LTP y el bloqueo de rastreadores se aplican fuera de la Navegación privada. La ATFP está activada por defecto solo en la Navegación privada. Las protecciones de AFP se han ampliado a todas las sesiones en Safari 26. La descripción general de Apple para los usuarios sobre estas funciones está en apple.com/privacy/features.