En algún momento de los últimos años tus dashboards empeoraron — y no hiciste nada para merecerlo. Las mismas campañas, el mismo píxel, el mismo checkout, pero las conversiones reportadas bajaron, las audiencias de remarketing se encogieron y el costo por compra de la plataforma dejó de coincidir con los pedidos que contabas a mano. No rompiste nada. Lo que se rompió fue la capa de medición debajo de tus anuncios.
Este post explica qué se rompió — App Tracking Transparency, el Intelligent Tracking Prevention de Safari, la muerte lenta de la cookie de terceros —, qué perdieron de vista las plataformas, por qué llegaron las conversiones modeladas y por qué la salida duradera es trackear en tu propio dominio y servidor.
La Maquinaria Que Hacía el Trabajo
La medición de anuncios corría sobre dos piezas de plomería compartida.
La primera era la cookie de terceros. El píxel de la plataforma corría en millones de sitios, y todos leían y escribían la misma cookie del dominio de la plataforma. Ese único identificador hilaba la navegación de una persona por toda la web: la plataforma veía la impresión, el clic, la página de producto y la compra, todo enlazado a un solo perfil.
La segunda era el ID de dispositivo móvil (el IDFA de Apple, el advertising ID de Google). Dentro de las apps, donde no hay cookies, cumplía el mismo rol: un identificador estable, disponible por defecto, que unía el toque en un anuncio en una app con la compra hecha en otra.
Ambos funcionaban entre propiedades de empresas distintas, sin esfuerzo del anunciante. Esa propiedad es exactamente la que eliminaron.
Qué Cambió Realmente el ATT
Con iOS 14.5, Apple lanzó App Tracking Transparency. Se lo suele describir como "Apple mató el tracking"; lo que hizo fue algo más acotado y más consecuente: puso el IDFA detrás de un permiso explícito, app por app — el famoso diálogo "Pedir a la app que no rastree" — y convirtió el rechazo en el default práctico, porque la mayoría, al ser preguntada con claridad, dice que no.
Tres detalles importan:
- El ATT gobierna apps, no la web. Bloqueó el ID de dispositivo y el intercambio de datos entre apps. El lado web del colapso vino de la política de los navegadores (siguiente sección).
- El identificador no se degradó — desapareció. Para quien rechaza no hay versión aproximada del IDFA: el enlace entre un toque en un anuncio de Instagram y una compra en otra parte deja de existir.
- Lo que Apple ofreció a cambio es agregado. El reporte estilo SKAdNetwork devuelve conteos demorados, con umbrales, a nivel de campaña — útil en lo direccional, inútil para unir una conversión con un clic concreto.
Para plataformas cuya entrega se calibraba con feedback de conversión por usuario, fue una pérdida estructural, no una molestia de reporting.
El ITP de Safari y la Cookie de 24 Horas
La historia en la web es el Intelligent Tracking Prevention de Safari. El ITP bloquea las cookies de terceros por completo — el identificador cross-site descrito arriba ya no existe en Safari, y Firefox aplica un bloqueo parecido. Chrome pasó años anunciando restricciones mientras lanzaba APIs de reemplazo.
Las plataformas se adaptaron con la decoración de enlaces: agregar un ID de clic a la URL de destino (gclid, fbclid, ttclid), hacer que el píxel lo guarde en una cookie first-party vía JavaScript y leerlo de vuelta en la conversión. El ITP respondió directo: Safari limita la vida de las cookies escritas por JavaScript a 7 días, y a apenas 24 horas cuando la visita llega decorada con parámetros de tracking desde un dominio rastreador conocido.
En la práctica — cuenta ilustrativa, no un estudio: un cliente con iPhone hace clic en tu anuncio el martes y compra el sábado. La cookie con el ID del clic expiró hace días. Para la plataforma, el comprador del sábado es un desconocido. La conversión ocurrió; su atribución, no.
Qué Dejaron de Ver las Plataformas
| Señal | Antes | Después de ATT + ITP |
|---|---|---|
| ID de dispositivo (IDFA) en apps | Disponible por defecto | Permiso opt-in; rechazado en su mayoría |
| Cookie de terceros | Un perfil por toda la web | Bloqueada en Safari y Firefox; restringida en el resto |
| Cookie first-party escrita vía JS | Duraba meses | Limitada a 7 días / 24 horas en Safari |
| ID de clic al convertir | Leído de una cookie duradera | Desaparece, salvo que tú mismo lo captures y guardes |
| Conteo de conversiones | Eventos observados | Observados más estimaciones modeladas |
Los síntomas son los que sentiste: audiencias de remarketing más chicas, frequency caps que dejaron de funcionar entre sitios y conteos que subreportaban el tráfico de iOS y Safari.
Conversiones Modeladas: Tapar el Hueco con Matemática
Las plataformas no dejaron los huecos vacíos. Donde el enlace determinístico se rompió, Google, Meta y TikTok introdujeron el modelado de conversiones: estimaciones estadísticas de cuántas conversiones probablemente ocurrieron en el segmento no observable, basadas en el comportamiento de los usuarios que todavía pueden ver.
Siendo justos: a escala de plataforma, modelar es razonable, y un número modelado suele quedar más cerca de la realidad que un subconteo crudo. Pero cambia lo que tu dashboard es. Parte de la columna "Compras" ya no es un conteo de eventos — es una inferencia. No puedes unir una conversión modelada a un número de pedido, auditarla contra tu tienda, ni saber qué campañas absorbieron más conjetura. Y quien produce la estimación es la misma entidad que te vende los anuncios.
Por Qué el Tracking First-Party Sobrevive
Todos los mecanismos rotos de arriba tienen algo en común: dependían de que un tercero identificara a tu visitante en sitios ajenos. Ese comportamiento es el que los navegadores y los sistemas operativos decidieron terminar, sin marcha atrás.
Lo que ninguna de esas políticas restringe es tu relación con tu propio visitante en tu propio dominio. Una arquitectura first-party invierte el diseño:
- El script de tracking se sirve desde tu dominio y envía eventos a tu endpoint — tu sitio observando tu tráfico, no un rastreador observando la web.
- Los IDs de clic y las UTMs se capturan al aterrizar y se guardan en el servidor, en tu base de datos. Una fila en Postgres no expira a las 24 horas porque Safari lo diga.
- La verdad de la conversión viene de eventos server-side — un webhook del checkout de Shopify o Stripe con el pedido real y el monto real —, no de un script en el navegador.
- La unión entre clic y pedido ocurre en tu servidor, bajo reglas que puedes inspeccionar. Esa es la arquitectura sobre la que está construido Decisa: captura de clics en tu propio dominio, pedidos vía webhook y una atribución auditable pedido por pedido.
El resultado es una medición a la que no le importa qué cambie la próxima versión de iOS, porque nada en la cadena depende de identidad cross-site.
Qué Hacer Esta Semana
- Captura los IDs de clic en first-party. Guarda
gclid,fbclid,ttclidy las UTMs al aterrizar, en el servidor — no solo en una cookie. - Lleva la verdad de la conversión al servidor. Los webhooks de tu checkout, y no los eventos del navegador, definen qué es un pedido.
- Devuelve las conversiones verificadas vía la Conversions API de Meta y las conversiones avanzadas de Google, para que los algoritmos de puja aprendan de pedidos reales en lugar de modelados.
- Reubica tus decisiones. Usa los números de la plataforma para optimizar dentro de ella; decide presupuesto y escalado con tus propios datos cruzados.
El tracking no se rompió porque configuraste mal un píxel. Se rompió porque toda una arquitectura — identificar personas en las propiedades de otras empresas — fue retirada. El reemplazo no es un píxel mejor. Es ser dueño del camino del dato.