iOS 27 rompió a los proveedores de identidad, no tu cuenta de anuncios
El bloqueo de Safari golpeó la infraestructura de los proveedores de identidad, no tu píxel. Una prueba de dos ventanas para saber si tu cuenta quedó expuesta.
La restricción de Apple cayó sobre la capa de identidad, y la capa de identidad no es donde se cuentan tus conversiones. El primer movimiento correcto después de lo publicado esta semana es medir tu propia cuenta en dos ventanas iguales, no reconstruir el stack.
El 28 de octubre Digiday reportó que las restricciones de Safari vigentes desde septiembre alcanzaron a un grupo con nombre y apellido: Audigent (una empresa de Experian), ID5, LiveRamp (hoy parte de Publicis Groupe), Permutive y el servidor de anuncios de The Trade Desk, según pruebas en vivo hechas durante la semana del 19 de octubre. La reacción de la industria ya se ve: ID5 está migrando más infraestructura de identidad a server-side y otros se están alineando con el Trusted Server Framework del IAB Tech Lab.
Las dos cosas son movimientos de proveedores para mantener vivo su propio producto. Ninguna te dice si tu cuenta perdió una sola conversión.
El bloqueo nunca apuntó a tu píxel
Lee la explicación de Apple, reportada por Digiday el 20 de octubre, y el objetivo está dicho sin rodeos: identificadores derivados de datos como las direcciones de correo, usados para reconocer a la misma persona en distintos sitios sin consentimiento explícito. La objeción es que un tercero sentado de forma invisible en páginas donde la gente escribe su correo puede armar un perfil que sobrevive al cierre de sesión, a la baja del boletín y al cambio de dispositivo.
Eso describe un grafo de identidad. No describe un evento de conversión.
Las propias pruebas de Digiday encontraron que la mayoría de las direcciones de ad tech que revisaron seguían cargando, y que el bloqueo había atrapado a un puñado de empresas. El mismo reporte cuenta que el servidor de anuncios de The Trade Desk quedó bloqueado por error y lo volvieron a encender. Dicho de otro modo: la lista es angosta, en parte accidental y se mueve. Quien reconstruyó su medición en la primera semana de octubre reaccionó a un incidente de proveedor, no a sus propios datos.
Qué está bloqueado y qué no
| Petición | ¿Bloqueada? | Qué significa para el anunciante |
|---|---|---|
Llamada entre sitios a un dominio de identidad de la lista (id5-sync.com, rlcdn.com, permutive.com, ad.gt, uidapi.com) | Sí | El enriquecimiento, la sincronización de audiencias y la identidad entre sitios se detienen en Safari. No aparece ningún error. |
| Reconocer a una persona entre sitios a partir de un correo hasheado | Sí — es el objetivo declarado | La pierna de Safari del matching entre sitios desaparece. Tu registro en el CRM no. |
| Que un sitio use sus propios datos para personalizar a sus propios clientes | No | Apple dice que eso no es tracking. La personalización first-party sigue funcionando. |
| Navegar a tu sitio y las peticiones a tu propio dominio | No | Tus páginas, formularios y endpoints propios quedan intactos. |
| Tu píxel de Meta y la Conversions API, la recolección de Google y GA4 | No están en la lista publicada | La capa de medición que nombra la prensa no era el objetivo. |
| El servidor de anuncios de un DSP | Lo estuvo, y lo restauraron | Atrapado por error, según Digiday. La lista cambia. No tomes la primera semana como línea base. |
La distinción que importa es entre reconocer a una persona y registrar un evento. Apple fue por la primera. Tu reporte de conversiones depende de la segunda. Cuando las dos cosas viven en el mismo contenedor de etiquetas —y en muchos setups de CDP viven juntas— aparece un daño colateral que se ve como problema de identidad y se comporta como problema de medición.
Tres multiplicadores definen tu exposición real
La exposición no es sí o no. Es más o menos el producto de tres factores, y si cualquiera de ellos está cerca de cero, tu exposición también.
1. Peso de Apple en tu tráfico. La participación de Safari varía enormemente por mercado y por audiencia. Una audiencia B2B en Estados Unidos y una audiencia de consumo en Brasil no cargan el mismo iOS. Si no sabes cuál es tu porcentaje de Safari por dispositivo y geografía, no puedes dimensionar esta historia: cada titular que leas es la audiencia de otro.
2. Dependencia de identidad de terceros. Semillas de lookalike armadas con segmentos de proveedores, enriquecimiento que se pega a los formularios, sincronización de audiencias desde el CDP, límites de frecuencia entre sitios. Si tu segmentación se apoya en listas propias, segmentación amplia y prospección guiada por creatividad, tenías muy poco que perder aquí.
3. Si tu llamada de conversión vive solo en el navegador. Un píxel solo, en una sesión de Safari, es el caso frágil. Píxel más Conversions API con deduplicación es el resistente, y por eso las cuentas que ya corrían ambos absorbieron el cambio de septiembre como ruido.
Multiplica esos tres y obtienes un número entre "esto no es mi problema" y "perdí señal en una porción medible de mi tráfico". Casi nadie que entró en pánico en octubre había hecho la multiplicación.
La prueba de dos ventanas
Este es el orden que seguimos cuando el volumen de conversiones de un cliente se mueve sin que haya cambiado la campaña. Toma una tarde y responde la pregunta antes de que alguien toque la arquitectura.
Paso 1 — Primero el CRM, después la plataforma. Elige dos ventanas iguales de al menos 14 días cada una, con los primeros reportes del cambio de Apple como frontera. Que no caiga una promoción, un cambio de precio o un feriado dentro de ninguna de las dos. Saca las conversiones reportadas por la plataforma y los leads u órdenes verificados en el CRM para ambas. Después calcula la proporción entre las dos.
La proporción es el instrumento. El volumen se mueve por una docena de razones: estacionalidad, presupuesto, creatividad, presión de subasta. La proporción entre lo que la plataforma dice y lo que tu CRM confirma se mueve por una sola: cambió la ruta de medición.
Paso 2 — Fija el umbral con tu propio historial. Toma las ocho semanas previas al cambio y calcula la variación semanal de esa proporción. Ya tienes la varianza normal de la cuenta. Si el delta posterior cae dentro de ese rango, no tienes señal: tienes clima. Si queda fuera y se sostiene dos semanas seguidas, tienes una falla que vale la pena atender.
Este es el paso que todos se saltan. Comparan este octubre con el octubre pasado y llaman tendencia a la diferencia.
Paso 3 — Lee cobertura y calidad de coincidencia como dirección, no como puntaje. El Event Match Quality y la cobertura de eventos son diagnóstico, no verdad absoluta. Un número de cobertura que baja mientras los leads del CRM se mantienen apunta a la llamada del navegador perdiendo eventos. Un número de cobertura plano durante meses no dice nada sobre septiembre. Si quieres la mecánica de esa señal, desarmamos cómo el EMQ mueve el rendimiento y qué hacen los eventos automáticos de Meta con la cobertura.
Paso 4 — Revisa la composición de audiencias antes de la arquitectura. Tamaño de semillas, audiencias coincidentes, alcance de lookalikes. Los proveedores de identidad alimentan esta capa, así que una semilla que se encoge es el primer lugar donde aparece un bloqueo, y aparece como entrega inestable, no como mensaje de error.
Solo si los pasos 1 a 3 apuntan en la misma dirección tocas la arquitectura. Y para entonces ya sabes qué capa tocar, que es todo el punto.
La decisión según el tipo de anunciante
| Tipo de anunciante | Dónde cae la exposición | Primera acción |
|---|---|---|
| Generación de leads B2B en LinkedIn y Meta | Click IDs del Insight Tag, enriquecimiento, sincronización de audiencias | Verifica el conteo de leads del CRM por geografía contra el número de la plataforma. No muevas las pujas. |
| Ecommerce DTC en Meta y Google | Calidad de semillas de lookalike, matching entre sitios, algo de cobertura | Observa tamaño de audiencia y estabilidad de entrega dos semanas antes de cambiar nada. |
| Marca y reconocimiento en programática | Metodología de entrega y medición de alcance | Pregunta al proveedor cómo calcula la entrega post-bloqueo. Esa pregunta vale más que mover presupuesto. |
El patrón se repite: mientras más lejos está tu gasto de un evento de respuesta directa, más probable es que hayas quedado expuesto, y menos probable es que la exposición aparezca en un tablero que revisas a diario.
Por qué "nos vamos a server-side" no es tu solución
Aquí me separo de casi toda la cobertura. Server-side se está vendiendo como respuesta a dos problemas distintos y solo resuelve uno.
Para medición, server-side funciona, y funciona por una razón aburrida: la petición que Safari habría interceptado ya no nace en el navegador. Eso es real, es durable y debería ser tu configuración por defecto desde antes. Desarmamos la versión capa por capa en la auditoría de dominios que corremos en stacks de clientes.
Para identidad, server-side no es una solución. Es una mudanza. Mathieu Roche, CEO de ID5, le dijo a Digiday lo que casi nadie dice en voz alta: "Ir a server-side es más resistente porque ya no estás en el dispositivo, así que no hay nada que el dispositivo pueda hacer para bloquearte". Es una descripción exacta de la resiliencia frente a un control del navegador. También es la descripción de mover la resolución de identidad entre sitios a un lugar donde el navegador de Apple no la ve, que es justo la práctica que la explicación de Apple objeta.
Los críticos del Trusted Server Framework del IAB Tech Lab llegan al mismo punto por el otro lado: más infraestructura, más dependencia de proveedores de nube, dudas sobre fingerprinting y un riesgo real de que los publishers inviertan fuerte en un rodeo que Apple ya señaló que no le gusta. Otra ronda de gato y ratón no es una base estable para un plan de medición.
Así que cuando un proveedor te dice que se muda a server-side, la traducción correcta es: está protegiendo la continuidad de su producto. Pregúntale qué cambia en los eventos que puedes verificar en tu propio CRM. Si la respuesta es nada, no es tu proyecto.
Qué hacer esta semana
No reconstruyas. Corre la proporción. Si se mantuvo, gastaste una tarde y aprendiste que tu cuenta está más sana de lo que sugería la noticia, lo cual vale, porque la próxima historia así llega en unas seis semanas y vas a correr la misma prueba en una hora.
Si la proporción se rompió, arregla lo angosto: saca la llamada de conversión del navegador por el endpoint server-side de la propia plataforma, agrega deduplicación —el mismo patrón de nuestra reconstrucción de atribución de 2026— y detente ahí. La reparación de identidad y audiencias es otra decisión, con otro presupuesto, y merece una conversación con el proveedor, no un sprint.
Si quieres una segunda lectura sobre cuál de los tres multiplicadores es realmente el tuyo, esa es la conversación que tenemos con clientes antes de dimensionar cualquier reconstrucción: nuestro equipo de publicidad digital lo hace como diagnóstico, no como venta. Las cuentas que pasaron septiembre intactas no fueron las del stack más nuevo. Fueron las que sabían cómo se ve una semana normal.
Preguntas frecuentes
¿Mi píxel de Meta está afectado?
Ningún reporte público pone el píxel de Meta ni la Conversions API en la lista restringida. Las empresas nombradas son infraestructura de identidad y audiencias. Si tus conversiones reportadas por Meta cayeron, empieza por la cobertura de eventos y la deduplicación en tu propia configuración antes de asumir que un navegador te bloqueó.
¿Debo pausar la inversión en mercados con mucho Safari hasta que esto se aclare?
No. Las subastas no cambiaron; en la mayoría de las cuentas, si acaso, cambió la capa de medición. Pausar le entrega a la competencia el historial de entrega que pagaste por construir y te quita justamente los datos que necesitas para correr la prueba.
¿Cada cuánto debería repetir esta prueba?
Cada vez que cambie una plataforma y el cambio mencione medición, y una vez por trimestre en cualquier caso. El valor no está en la lectura única, sino en tener una línea base de cómo se ve tu varianza normal, para que el próximo titular te tome una hora y no una semana.
Preguntas Frecuentes
¿iOS 27 rompió el seguimiento de conversiones de Meta Ads?
No hay evidencia pública de que lo haya hecho. Los dominios que la prensa especializada identifica como afectados son proveedores de identidad y audiencias —ID5, LiveRamp, Permutive, Audigent y el servidor de anuncios de The Trade Desk—, no el píxel de Meta ni la Conversions API. Una caída de conversiones reportadas después de una actualización del sistema operativo suele ser un problema de cobertura de tus propios eventos, y la prueba de dos ventanas de este artículo separa eso de una pérdida real de segmentación.
¿Cómo sé si el bloqueo de identidad de Safari afectó mi cuenta?
Compara dos ventanas iguales y sigue la proporción entre conversiones reportadas por la plataforma y leads verificados en el CRM, no el volumen bruto. Si las dos series se mueven juntas, no se rompió nada en tu medición. Si las conversiones reportadas caen mientras los leads del CRM se mantienen, y la caída se concentra en segmentos con mucho Apple, tienes una falla de cobertura. Si los leads del CRM también caen, la entrega o la identidad sí se degradaron para ti.
¿Migrar a server-side resuelve el problema de identidad?
Resuelve la mitad. El enrutamiento server-side recupera las llamadas de conversión que el navegador se negaba a hacer, porque la petición ya no sale del navegador. No recupera la resolución de identidad entre sitios: solo la mueve fuera del dispositivo, que es justo lo que Apple objetó. Los proveedores que migran su grafo de identidad a server-side están protegiendo su producto, no reparando tu cuenta.
