Atribución sin cookies explicada: lo que aún funciona en 2026

La pila de atribución de marketing que la mayoría de los equipos construyeron entre 2012 y 2019 dependía de dos cosas: una cookie de terceros depositada por la plataforma de anuncios en la landing page, y un píxel de navegador que se disparaba en la página de conversión y se emparejaba de vuelta con esa cookie. Ambas mitades de ese par están ahora degradadas. Ninguna se recuperará.

Este post no es un lamento por la cookie. Es un mapa de lo que realmente funciona en 2026 - qué rutas de atribución han sobrevivido, cuáles han sido comercializadas como soluciones sin ser realmente soluciones, y cómo se ve una pila funcional en la práctica para equipos que ejecutan adquisición pagada hacia tráfico de la UE.

TL;DR#

• ITP 2.3 de Apple, la Enhanced Tracking Protection de Firefox y la eliminación progresiva de cookies de terceros de Chrome en curso juntos significan que el 60-70% del tráfico web de la UE ahora bloquea o limita severamente las cookies de terceros por defecto.
• Dos rutas de atribución aún funcionan: identificadores del lado del servidor pasados a través de un click ID, y plantación de cookies de primera parte vía una cadena de redirección que tu dominio controla.
• Sin cookies no significa sin consentimiento. La Directiva ePrivacy 2002/58/CE y GDPR aún requieren consentimiento para analytics no esenciales, independientemente del mecanismo de almacenamiento.
• El stitching probabilístico por huella digital no es un respaldo conforme en la UE; el emparejamiento determinista por hash de email combinado con un click ID del lado del servidor es el único enfoque que se sostiene bajo tanto precisión como escrutinio regulatorio.

Qué cambió: una breve línea de tiempo#

Safari comenzó a restringir las cookies de terceros en 2017 con ITP 1.0. Las restricciones escalaron rápidamente. ITP 2.3, lanzado en septiembre de 2019, limitó la vida útil de las cookies de primera parte establecidas por script a siete días, y a veinticuatro horas cuando la cadena de referencia incluía un tracker entre sitios conocido. Ese cambio por sí solo rompió el traspaso estándar de click-ID-a-cookie en el que la mayoría de los vendedores de atribución se basaban.

La Enhanced Tracking Protection de Firefox lanzó Total Cookie Protection a todos los usuarios en 2022, particionando cada cookie de terceros por sitio de nivel superior. Una cookie establecida por pixel.example.com en tu página de pago y la página de pago de tu competidor son ahora dos cookies completamente separadas - la correlación entre sitios desaparece por construcción.

La línea de tiempo de Chrome ha cambiado varias veces desde que Google la anunció en 2019. La posición actual, documentada en el sitio de Privacy Sandbox (consultado el 2026-05-12), tiene la deprecación procediendo para un subconjunto de usuarios con un despliegue completo aún en progreso. Independientemente de la fecha final de Chrome, la imagen de la UE ya está establecida: Safari y Firefox juntos representan la mayoría del tráfico móvil y de escritorio consciente de la privacidad en los mercados de la UE. Las estrategias de atribución que requieren cookies de terceros ya están rotas para una gran parte de tu audiencia europea.

El efecto combinado medido a través de cuentas típicas de marketing de rendimiento de la UE: la atribución por píxel del lado del navegador está subcontando las conversiones en un 25-45% dependiendo de la mezcla de tráfico, con verticales pesadas en iOS (moda, belleza, apps, servicios de suscripción) en el extremo superior de ese rango.

Las dos rutas de atribución sobrevivientes#

Ruta 1: identificadores del lado del servidor#

La mecánica central es directa. Cuando un usuario hace clic en tu anuncio, la plataforma de anuncios añade un identificador de clic a la URL de aterrizaje - fbclid para Meta, gclid para Google, y así sucesivamente. Ese identificador existe en la URL, no en una cookie, así que ITP y la partición de cookies no lo tocan.

Tu landing page lee el click ID desde la URL y lo escribe en una cookie de primera parte en tu propio dominio, o lo pasa a tu carrito y eventualmente al registro del pedido. Cuando el usuario convierte, tu back-end lee el click ID del pedido y envía la conversión servidor a servidor a la API de conversiones de la plataforma de anuncios - Conversions API de Meta, GA4 Measurement Protocol, el endpoint de eventos del lado del servidor de Mixpanel.

Esta ruta funciona porque nunca toca cookies de terceros. El click ID está en la cadena de consulta de la URL en el momento del aterrizaje. Tu cookie de primera parte en tu propio dominio no está restringida por ITP de la misma manera que las cookies de terceros (aunque está sujeta al límite de 7 días en cookies establecidas por script si la cadena de referencia es sospechosa - más sobre esto a continuación). El evento de conversión fluye servidor a servidor, completamente fuera del navegador.

Los puntos débiles son reales. Si el usuario borra cookies entre el aterrizaje y la conversión, el click ID se ha ido. Si la conversión ocurre en un dispositivo diferente, no hay enlace entre dispositivos a menos que tengas un usuario con sesión iniciada con una dirección de email conocida. Y iOS 17 introdujo la Link Tracking Protection en Navegación Privada y Mail, que elimina parámetros conocidos de click ID de las URLs - fbclid, gclid, msclkid están en la lista de eliminación. Un usuario que llega vía la app de Mail con la protección de tracking de enlaces activada no llevará el click ID a tu sitio en absoluto.

Ruta 2: cadena de redirección de primera parte#

La segunda ruta sobreviviente usa una redirección que controlas como superficie de atribución. En lugar del click ID de la plataforma de anuncios, generas tu propio identificador persistente en el momento de la redirección en tu propio dominio.

Cuando un usuario hace clic en un enlace en tu dominio - ya sea un enlace corto, una redirección de aterrizaje de campaña o un deep link de marca - el manejador de redirección en tu edge se ejecuta antes de que se apliquen las restricciones de privacidad del navegador. Puede:

1. Establecer una cookie de primera parte con un click ID generado por el servidor en tu dominio.
2. Añadir el click ID como parámetro de URL a la URL de destino.
3. Registrar el evento de clic del lado del servidor con el contexto técnico completo (IP, user-agent, referrer, timestamp) en el momento del clic en lugar del momento de la carga de la página.

Debido a que este es tu dominio y tu cookie del lado del servidor, se sitúa fuera de las restricciones de cookies de terceros que ITP apunta. La cookie se establece por tu servidor vía una cabecera de respuesta Set-Cookie en la respuesta de redirección - las cookies establecidas por el servidor no están sujetas al límite de 7 días de ITP que se aplica a las escrituras document.cookie desde JavaScript.

Esta es la superficie de atribución que proporciona un acortador de URL que un píxel de navegador no puede. La redirección se resuelve en el dominio del acortador. Si ese dominio es tu propio dominio de marca, tu click ID es de primera parte, establecido por el servidor, y arquitectónicamente posicionado antes de cualquier restricción de privacidad del lado del navegador.

Cómo un enlace corto se convierte en la superficie de atribución#

El flujo de redirección funciona así. La URL de destino de tu anuncio es un enlace corto de marca - por ejemplo, go.acme.example/summer-sale. El usuario hace clic. La petición de redirección llega al manejador del edge de Elido, que:

• Busca la URL de destino.
• Genera un identificador elido_click y registra el evento de clic del lado del servidor.
• Establece una cookie de primera parte Set-Cookie: elido_click=<id>; Domain=go.acme.example; SameSite=Lax; Secure; Max-Age=604800 en la respuesta de redirección.
• Añade ?elido_click=<id> a la URL de destino antes de reenviar.

La página de destino recibe el click ID en la cadena de consulta. Tu gestor de tags o código de tema lo lee y lo almacena en el registro de carrito o pedido. Cuando la conversión ocurre, haces POST a POST /v1/conversions con el click ID y los detalles del pedido - Elido maneja el hash SHA-256 de los identificadores del cliente y el fan-out del lado del servidor a Meta CAPI, GA4 Measurement Protocol y Mixpanel.

El click ID nunca vivió en una cookie de terceros. Fue establecido por el servidor, de primera parte, registrado antes de que la capa de privacidad del navegador tuviera la oportunidad de interferir. Para la mecánica completa del paso de reenvío del lado del servidor, tracking de conversiones del lado del servidor vía enlaces cortos cubre la deduplicación, los requisitos de hash y la semántica de reintento en detalle.

Para la pregunta más amplia de cómo ITP degrada específicamente la atribución de clics y qué hace la cadena de redirección de enlace corto al respecto, atribución de clics después de Safari ITP es el compañero operativo de este post.

Stitching de identidad: qué funciona y qué no#

Los click IDs del lado del servidor resuelven el problema de atribución para usuarios que hacen clic en un enlace y convierten en la misma sesión de navegador en el mismo dispositivo, sin borrar cookies, sin que la protección de tracking de enlaces elimine el parámetro. Eso aún cubre la mayoría de las conversiones de e-commerce. Pero no cubre todo, y los enfoques que los equipos usan para llenar la brecha restante varían significativamente tanto en precisión como en exposición legal.

El emparejamiento determinista funciona. Si el usuario está con sesión iniciada, o proporciona su dirección de email en cualquier punto del embudo (captura de email, suscripción a newsletter, checkout), puedes hashear esa dirección de email con SHA-256 e incluirla en el evento de conversión. Meta CAPI, GA4 y Mixpanel aceptan email hasheado como señal de emparejamiento junto con o en lugar de un click ID. La tasa de emparejamiento para tráfico con email conocido es alta - Meta reporta internamente tasas de emparejamiento por encima del 90% cuando un email normalizado y hasheado está presente. Este es el mecanismo de stitching principal que sobrevive intacto a la deprecación de cookies.

El emparejamiento de deduplicación importa aquí. Cada evento de conversión necesita un event_id (para Meta) o transaction_id (para GA4) que es idéntico entre el píxel del lado del navegador y el envío del lado del servidor. Sin él, ambos eventos se ingieren y la conversión se cuenta dos veces. El ID del pedido es la clave de dedup estándar para eventos de compra.

El fingerprinting probabilístico no funciona - y no es legal en la UE. El fingerprinting del navegador ensambla un identificador único a partir de la combinación de resolución de pantalla, fuentes instaladas, zona horaria, user-agent, huella digital de renderizado de canvas y señales similares. El identificador es probabilístico - asigna un emparejamiento de alta confianza entre dos eventos sin una cookie compartida o login. Algunos vendedores de atribución ofrecen esto como una solución de "medición sin cookies".

En la UE, este enfoque tiene un problema legal específico. La Directiva ePrivacy 2002/58/CE, Artículo 5(3), requiere consentimiento para acceder o almacenar información en el equipo terminal de un usuario. La posición del EDPB, repetida en varias decisiones de autoridades supervisoras desde 2022, es que el fingerprinting cae dentro del alcance del Artículo 5(3) independientemente de si el identificador es técnicamente una "cookie". La DSB austriaca, la CNIL francesa y la Garante italiana cada una ha emitido acciones de aplicación sobre fingerprinting sin consentimiento. La afirmación "no usamos cookies, usamos fingerprinting" no es un argumento de cumplimiento; es el argumento que invita a un mayor escrutinio.

Incluso fuera de la exposición legal, el fingerprinting probabilístico se degrada en precisión a medida que la entropía del navegador disminuye. Los navegadores modernos centrados en la privacidad activamente reducen la entropía normalizando la salida del canvas y limitando la resolución de las APIs de tiempo. La calidad de la señal cae precisamente en la población - consciente de la privacidad, pesada en iOS - donde más necesitas una medición precisa.

El stitching entre dispositivos vía CRM es la brecha restante. Para usuarios que convierten en un dispositivo diferente del que hicieron clic, el emparejamiento determinista por email es el único enfoque que funciona. Si el usuario está con sesión iniciada en ambos dispositivos, el ID de usuario es el enlace. Si no están con sesión iniciada, el click ID en el dispositivo A y la conversión en el dispositivo B no pueden conectarse sin que el usuario proporcione voluntariamente un identificador (email, teléfono) que puedas hashear y emparejar. Esta brecha no puede cerrarse del lado del servidor. Es un límite real de atribución en el mundo sin cookies.

La capa de cumplimiento#

El encuadre de "atribución sin cookies" puede engañar a la gente a pensar que porque no se está estableciendo cookie alguna, no se requiere consentimiento. Eso no es lo que dice la ley.

La Directiva ePrivacy 2002/58/CE, Artículo 5(3), se aplica a cualquier almacenamiento o acceso a información en el equipo terminal de un usuario - no solo cookies. Una cookie de primera parte establecida para fines de analytics requiere el mismo consentimiento que una cookie de terceros establecida para fines de tracking, si esa cookie no es esencial. La cookie de click ID establecida por el servidor descrita arriba está adyacente a analytics; puede o no requerir consentimiento dependiendo de la evaluación de propósito de tu controlador y la implementación nacional aplicable de la Directiva.

Lo que el enfoque del lado del servidor sí hace - y esta es su ventaja real de cumplimiento - es desplazar el procesamiento fuera del dispositivo del usuario y hacia el servidor. El registro de eventos de clic, el reenvío de eventos de conversión, el stitch de identidad: estos ocurren en tu back-end y el back-end de Elido, no en un script de navegador. Eso significa que los bloqueadores de anuncios no los interceptan, las funciones de privacidad del navegador no los particionan, y la postura de minimización de datos es controlable por ti en lugar de dependiente de lo que un tag de terceros decida enviar.

La cuestión de la base legal de GDPR es separada de la cuestión de ePrivacy. Incluso con atribución del lado del servidor, necesitas una base legal bajo el Artículo 6 de GDPR para procesar datos de clic sobre sujetos identificables de la UE. Para analytics a nivel de campaña, la mayoría de los controladores basan esto en interés legítimo bajo el Artículo 6(1)(f) después de una Evaluación de Interés Legítimo. Para el perfilado a nivel individual o el retargeting, la base es más difícil. El cornerstone GDPR para acortadores de URL cubre el análisis del Artículo 6, 28 y 30 en detalle; el resumen aquí es que sin cookies ≠ sin consentimiento, y la capa de cumplimiento no desaparece porque el mecanismo de almacenamiento cambió.

Los valores por defecto de eventos de clic de Elido reflejan una postura de minimización de datos: las IPs se truncan a /24 (IPv4) antes de persistir, las cadenas completas de user-agent se analizan y se eliminan. Los datos de resolución completa están disponibles por workspace si tu caso de uso lo requiere, pero el predeterminado es el ajuste conservador. Eso importa para la conversación de la enmienda DPA con tus compradores. Para más sobre esa conversación, solutions/marketers cubre los puntos de contacto de compras para equipos de marketing.

Lo que renuncias#

La contabilidad honesta importa. La atribución sin cookies del lado del servidor recupera la mayor parte de la señal perdida a la degradación del lado del navegador, pero no recupera toda.

Identidad entre dispositivos en tiempo real. Como se señaló arriba: si un usuario hace clic en móvil y convierte en escritorio sin un evento de login vinculando los dos, la atribución se pierde. No hay solución conforme del lado del servidor para esto. La brecha es estructural.

Atribución view-through precisa. La atribución view-through - acreditar una campaña por una conversión que siguió a una impresión de anuncio, no a un clic - requiere que la plataforma de anuncios haya emparejado al usuario a través de ambos eventos. Las APIs de conversión del lado del servidor manejan bien la atribución basada en clic; view-through depende del propio gráfico entre dispositivos de la plataforma, que a su vez se degrada en proporción a la pérdida de señal. Espera que los informes view-through sean más ruidosos y menos fiables que los números basados en clic.

Ventanas de lookback largas. La mayoría de los endpoints de API de conversión del lado del servidor imponen un límite de lookback en cuán atrás en el tiempo se puede atribuir un clic a una conversión. El lookback estándar de Meta CAPI es 7 días para click-through. El Measurement Protocol de GA4 tiene una ventana de atribución que varía por canal. Estos límites son más cortos que las ventanas de 28 días o 90 días que algunos equipos usaron en el mundo basado en cookies. Los productos de suscripción y las compras consideradas con ciclos de investigación largos verán más conversiones caer fuera de la ventana atribuible.

Dominancia de último clic. Sin un gráfico de identidad multitoque, la atribución del lado del servidor por defecto va al último clic - el click ID más reciente en la cadena obtiene el crédito. Para campañas de conocimiento de marca que impulsan conversiones asistidas durante un período largo, la atribución de último clic del lado del servidor subvalorará sistemáticamente el gasto del embudo superior. La mitigación es el stitching de CRM vía email hasheado: si el email de cada usuario con sesión iniciada está en cada evento de conversión, puedes reconstruir una secuencia multitoque para la porción con sesión iniciada de tu audiencia. Para usuarios anónimos, el último clic es el techo.

Una pila práctica#

Dadas las restricciones anteriores, aquí está la pila de atribución que funciona para un equipo de marketing de rendimiento que ejecuta tráfico de la UE en 2026.

Click ID de enlace corto como punto de entrada. Todos los destinos de anuncios son enlaces cortos de marca en tu dominio. La redirección establece una cookie de primera parte del lado del servidor y añade el click ID a la URL de destino. Esto te da un identificador persistente, establecido por el servidor, que sobrevive a ITP y la partición de cookies para la sesión.

Tubería de carrito y pedido. El click ID se escribe en un atributo de carrito en la carga de página (desde el parámetro de URL o la cookie de primera parte). En la creación del pedido, el click ID está en los atributos personalizados del pedido. Este es el traspaso duradero - una vez que el click ID está en el pedido, no expira.

CAPI del lado del servidor a Meta. En el pedido pagado, tu back-end (o la función de reenvío de conversiones) hace POST a Meta CAPI con el click ID, el email hasheado con SHA-256 y los identificadores fbc/fbp de las cookies de primera parte. El event_id es el ID del pedido, coincidiendo con el píxel del lado del navegador. Meta deduplica dentro de la ventana de emparejamiento de 48 horas.

Measurement Protocol del lado del servidor a GA4. Simultáneamente, se envía un evento del lado del servidor de GA4 con transaction_id igual al ID del pedido. El client_id es el valor de la cookie _ga de GA4 si está disponible, el click ID como respaldo. GA4 deduplica en transaction_id dentro de la ventana de sesión.

Stitch de hash de email de CRM. Para cualquier conversión donde falta el click ID (orgánico, directo, búsqueda de marca), la dirección de email hasheada es la señal de atribución. Esto puebla el segmento "usuario conocido" de tu atribución y soporta la reconstrucción multitoque básica para clientes con sesión iniciada.

Importación de conversiones offline para lookback largo. Para productos de suscripción o pipelines B2B donde la conversión ocurre semanas después del clic, la importación de conversiones offline vía la API por lotes de la plataforma (eventos offline de Conversions API de Meta, conversiones offline de Google Ads) te permite enviar eventos de atribución más allá de la ventana de lookback en tiempo real. La clave de emparejamiento sigue siendo email o teléfono hasheado; la ventana de tiempo se extiende. Esto no resuelve la atribución anónima de ciclo largo, pero cierra el bucle para la porción de tu audiencia que proporcionó una dirección de email.

La pila anterior no requiere un CDP. Requiere un acortador de URL que genere y persista click IDs del lado del servidor, un back-end que canalice el click ID hasta el pedido, y una capa de reenvío de conversiones que maneje el hash y el fan-out de API. Para la implementación técnica de la capa de fan-out, tracking de conversiones del lado del servidor vía enlaces cortos tiene las formas de payload, la mecánica de deduplicación y la semántica de reintento. Para dónde encaja esto en un flujo de trabajo UTM de campaña completo, ver solutions/marketers.

La versión de esta pila que no funciona: una que depende del propio gráfico entre dispositivos de la plataforma de anuncios para resolución de identidad, espera que los usuarios de iOS tengan App Tracking Transparency habilitado de una manera que beneficie tu medición, o usa fingerprinting probabilístico para llenar las brechas. La primera está fuera de tu control. La segunda es ilusoria. La tercera es un pasivo de cumplimiento en la UE.

Trabaja con lo que se sostiene.