Apple sigue recortando la cantidad de información que la tecnología de tracking de terceros puede recoger en Safari. La primera beta de Safari 27 llegó el 8 de junio de 2026. Las pruebas del sector apuntan a un conjunto más amplio de parámetros de tracking limpiados y de recursos de tracking bloqueados. El comportamiento exacto de la beta todavía puede cambiar antes de la versión final, pero la dirección es la de siempre: la medición que depende por completo de scripts del navegador, requests a terceros e identificadores persistentes es cada vez menos completa.
Qué parece estar cambiando en Safari 27
Las notas de la beta de Safari 27 publicadas por Apple confirman la versión y en qué plataformas está disponible, pero no documentan todos los cambios en las listas de tracking. Publicaciones independientes del sector señalan que Safari 27 amplía los parámetros de tracking que elimina de los enlaces, incluidos identificadores usados en enlaces de plataformas como Threads, YouTube y X.
Esas mismas fuentes apuntan a un bloqueo más amplio de recursos conocidos de publicidad y fingerprinting. Entre los ejemplos están snap.licdn.com de LinkedIn y recursos asociados a herramientas como Microsoft Advertising UET, Segment, Tealium y BlueConic. Como Safari 27 sigue en beta, conviene que pruebes tu propia implementación en lugar de dar por hecho que cada regla publicada llegará sin cambios.
Por qué importa: Safari es uno de los grandes navegadores móviles
Cuota de Safari en el uso mundial de navegadores móviles, junio de 2026 (Statcounter)
No es un caso marginal. Statcounter situó a Safari en el 24,07% del uso mundial de navegadores móviles en junio de 2026, aproximadamente una de cada cuatro sesiones de navegación móvil de su conjunto de datos. En audiencias de mercados con mucha presencia de Apple o en segmentos premium, esa cuota puede ser bastante mayor.
Si mides de menos a los visitantes de Safari, los paneles mostrarán menos sesiones, conversiones y puntos de contacto asistidos de los que el negocio ha generado en realidad. Las campañas no tienen por qué estar rindiendo peor; es la capa de medición la que ve menos. Eso debilita la atribución, las audiencias de remarketing y las señales que usan las plataformas publicitarias para optimizar.
Dónde pierde información el client-side tracking
El tracking tradicional pide al navegador del visitante que cargue JavaScript de los proveedores, guarde identificadores y envíe requests directamente a dominios de publicidad o analítica. Safari puede intervenir en cada una de esas fases.
Parámetros de atribución
Cuando se eliminan los parámetros identificativos de la URL de la landing, resulta más difícil conectar la campaña o el clic original con una conversión posterior.
Requests a terceros
Un endpoint de píxel o tracker conocido puede bloquearse antes de que la request salga del dispositivo, así que el proveedor nunca recibe el evento.
Almacenamiento del navegador
WebKit limita el tracking entre sitios y puede poner un tope al almacenamiento que escriben los scripts, lo que dificulta enlazar de forma fiable recorridos de conversión largos.
Señales de fingerprinting
Reducir o aleatorizar las características del dispositivo hace que la identificación probabilística sea menos estable. Bueno para la privacidad, pero un problema para los sistemas de tracking que dependen de ella.
Cómo el server-side tracking gana resistencia
Con server-side Google Tag Manager, la web envía los datos de evento consentidos a un endpoint first-party de tu propio dominio. Tu server container valida y transforma el evento, y después reenvía solo los campos necesarios a destinos como GA4, Google Ads, Meta o TikTok.
Eso reduce el número de llamadas directas a terceros que hace el navegador y te deja una única capa de recogida bajo control. Puedes estandarizar los datos de campaña, quitar datos personales innecesarios, rechazar eventos mal formados y vigilar la entrega desde un solo sitio. Además, un endpoint gestionado y alojado en la UE mantiene la infraestructura predecible sin que tu equipo tenga que operar Google Cloud.
1. Recogida first-party
El navegador envía los datos de evento permitidos a tu subdominio de tracking propio.
2. Control en el servidor
Tu container de sGTM valida, enriquece y filtra el evento según tus reglas.
3. Entrega controlada
El servidor envía los datos aprobados a cada plataforma de analítica o publicidad.
Lo que el server-side tracking no hace
El server-side tracking no es una capa de invisibilidad y no debe usarse para sortear los controles de privacidad del navegador. No puede recuperar un identificador de clic que Safari eliminó antes de que tu página lo recibiera, ni inventar datos que un evento bloqueado en el navegador nunca llegó a recoger.
Los requisitos de consentimiento siguen aplicándose. Tu plataforma de gestión del consentimiento debe determinar qué eventos y destinos están permitidos antes de recoger o reenviar datos. El objetivo es una arquitectura first-party más fiable y respetuosa con la privacidad, no más tracking sin permiso.
Un plan práctico para llegar preparado a Safari 27
- 01
Mide tu brecha en Safari
Compara las tasas de conversión, la entrega de eventos y los ingresos atribuidos de Safari con los de otros navegadores. Segmenta Safari móvil por separado.
- 02
Audita las dependencias del navegador
Enumera cada píxel, script de terceros, parámetro de URL y cookie de navegador que usa tu stack de medición.
- 03
Protege los datos de campaña first-party
Captura pronto el contexto de campaña permitido, usa identificadores first-party duraderos cuando proceda y documenta las reglas de conservación.
- 04
Lleva la entrega al servidor
Enruta los eventos de GA4 y de publicidad que corresponda por un endpoint de sGTM en tu propio subdominio.
- 05
Prueba consentimiento y deduplicación
Verifica el comportamiento del consentimiento, los IDs de evento, la deduplicación entre navegador y servidor y los diagnósticos de cada proveedor antes de comparar totales.
- 06
Sigue Safari 27 hasta su lanzamiento
Vuelve a probar con cada actualización de la beta y con la versión final, porque las listas de trackers y el comportamiento pueden cambiar.
No esperes a que el panel se quede sin señal
La trayectoria de Safari en privacidad está clara, y su audiencia móvil es demasiado grande como para ignorarla. Los negocios que dependen solo de píxeles client-side deben contar con que los huecos de medición irán a más a medida que los navegadores se vuelvan más estrictos.
Una buena configuración server-side no va a derrotar a Safari, ni debería intentarlo. Lo que te da es un endpoint first-party más limpio, mejor gobernanza y una entrega más fiable de los datos que los usuarios te han permitido tratar.
Safari 27 y server-side tracking: preguntas frecuentes
¿Safari 27 bloquea todo el tracking?
No. Safari aplica varias protecciones de privacidad a trackers conocidos, identificadores en enlaces, almacenamiento del navegador y fingerprinting. El comportamiento exacto depende de la request y de la configuración, y Safari 27 todavía está en beta.
¿El server-side tracking recupera todas las conversiones perdidas en Safari?
No. Mejora la fiabilidad y el control de la entrega de eventos first-party permitidos, pero no puede restaurar información que Safari eliminó antes de la recogida ni eventos que nunca ocurrieron.
¿Sigo necesitando consentimiento con server-side tracking?
Sí. Trasladar el tratamiento a un servidor no elimina las obligaciones del RGPD, de ePrivacy ni de otras normas de consentimiento. El consentimiento debe controlar la recogida y cada destino posterior.
¿Por qué usar server-side GTM en lugar de enviar los eventos directamente desde el navegador?
El server-side GTM reduce las requests directas a terceros desde el navegador y aporta una capa central para validar, minimizar, enrutar, monitorizar y entregar según el consentimiento.