La medición de marketing ya no se sostiene sobre un identificador único que sigue al usuario entre sitios. El plan de Google de retirar las cookies de terceros descarriló, pero Safari y Firefox llevan años bloqueándolas, los consentimientos GDPR reducen el dato observado y buena parte de la conversión ocurre fuera del navegador. Montar una medición fiable exige un stack nuevo: first-party, server-side, consentimiento gestionado y modelado.
Este artículo aterriza qué ha cambiado realmente, qué piezas componen una medición viable en 2026 y cómo se combinan sin depender de tecnologías inestables. El foco está en decisiones de negocio, no en checklists técnicos vacíos: cada bloque incluye el porqué y qué hacer con él.
Resumen
Medir marketing sin cookies de terceros exige combinar cuatro palancas en paralelo: datos first-party recogidos con consentimiento, server-side tagging que traslada la recolección del navegador al servidor propio, Consent Mode v2 con modelado de conversiones para recuperar la señal que se pierde cuando el usuario rechaza y modelos de atribución probabilísticos o de mezcla de medios que no dependen de un identificador cross-site. Lo que diferencia a las empresas que salen adelante en este contexto no es la tecnología, sino la voluntad de trabajar con métricas agregadas, ventanas más cortas y un CRM limpio. Las que sigan esperando que «vuelva el dato completo» van a decidir a ciegas.
Qué queda de las cookies de terceros y por qué la medición ya no puede depender de ellas
Las cookies de terceros siguen activas por defecto en Chrome, pero medir marketing como en 2019 ya no funciona. Safari (ITP) y Firefox (ETP) las bloquean por defecto desde hace años, los navegadores móviles añaden restricciones propias y el consentimiento explícito del RGPD deja una parte del tráfico sin trazar aunque técnicamente pudieran usarse. El identificador cross-site fiable dejó de existir en la práctica.
El giro definitivo llegó el 17 de octubre de 2025, cuando Google anunció la retirada de la mayor parte de Privacy Sandbox. En sus propias palabras: «we’ve decided to retire the following Privacy Sandbox technologies: Attribution Reporting API (Chrome and Android), IP Protection, On-Device Personalization, Private Aggregation (including Shared Storage), Protected Audience (Chrome and Android), Protected App Signals, Related Website Sets […], SelectURL, SDK Runtime and Topics (Chrome and Android)». La razón oficial fue la baja adopción de estas APIs y la decisión de mantener las cookies de terceros en Chrome (Google — Update on Plans for Privacy Sandbox Technologies).
El resultado es un escenario híbrido y confuso: las cookies de terceros existen, pero una parte enorme del tráfico las rechaza o las bloquea; y las APIs pensadas para reemplazarlas no van a llegar. La medición seria en 2026 se construye asumiendo que no hay un identificador universal de usuario cross-site y que la señal siempre va a estar parcialmente incompleta. A partir de ahí se decide con lo que hay.
First-party data: el nuevo eje de la medición
El first-party data —el que una empresa recoge en sus propios dominios y con consentimiento del usuario— es la única capa de identidad estable que queda. Sustituye al «quién es este usuario cross-site» por un «quién es este usuario en mis propios activos», que es mucho menos ambicioso pero mucho más defendible legal y técnicamente.
El eje pasa a ser el CRM y no el navegador. Cada punto de contacto donde el usuario deja un dato identificable —formulario, checkout, login, cita, reserva, descarga— se convierte en el ancla de medición. La conversión offline (llamada, visita, cita atendida) se vincula al mismo identificador y se devuelve a las plataformas publicitarias vía Enhanced Conversions, Conversions API u ofrecimiento de audiencias hasheadas.
Un user_id o email hasheado que persiste entre sesiones y dispositivos siempre que el usuario esté logueado o rellene un formulario. Sustituye al client_id de las cookies como llave principal.
La cookie del propio dominio no está afectada por el bloqueo de terceros. Se usa para reidentificar sesiones y ligarlas al user_id cuando el usuario vuelve, sin necesidad de infraestructura externa.
Preferencias, intereses y contexto que el usuario aporta voluntariamente en formularios o cuentas. Compensa la falta de tracking silencioso con información que muchas veces es mejor: intencional.
El punto donde ganan las empresas con conversión mixta: cruzar leads generados online con ventas cerradas offline (CRM, ERP, call center) y devolver ese dato a las plataformas de ads.
Para que este eje funcione hay que aceptar dos cambios de mentalidad. Primero, buena parte del tráfico no se identifica nunca y hay que operar con él en agregado, no individualmente. Segundo, la calidad del CRM pasa a ser problema de marketing y no solo de comercial: si el email está mal formateado o el user_id no llega desde el checkout, el resto del stack se cae. Este cambio de peso conecta con lo que ya se explicaba en el post sobre por qué el modelo last-click miente: cuando el identificador cross-site desaparece, el last-click no solo miente por diseño, es que además pierde su única fuente de datos.
Server-side tagging: por qué cambia dónde vive el dato
El server-side tagging traslada la recolección de eventos desde el navegador a un servidor propio, normalmente un contenedor de Google Tag Manager corriendo en un subdominio del cliente. En lugar de que cada píxel dispare desde el navegador hacia decenas de destinos, el navegador envía un único evento al servidor propio y este redistribuye la información hacia GA4, Meta CAPI, Google Ads y donde haga falta.
El efecto sobre la medición es doble. Por un lado, evita que los bloqueadores de contenido y las políticas ITP corten la llamada antes de que llegue: el evento sale al mismo dominio del sitio, no a un tercero. Por otro, permite enriquecer el evento con datos que solo existen en servidor —user_id del CRM, ingresos reales, estado del pedido, márgenes, etapa del funnel— antes de reenviarlo. La ganancia no está en «recuperar cookies», está en tomar el control del payload.
La contrapartida es coste y responsabilidad. Un contenedor server-side necesita hosting, mantenimiento, monitorización y alguien que entienda tanto marketing como infraestructura. Para catálogos pequeños o negocios con volúmenes bajos suele ser desproporcionado; para ecommerce de tamaño medio en adelante, negocios lead-gen con LTV alto o cuentas de Google Ads que se juegan la rentabilidad en Enhanced Conversions, es una pieza justificada. La decisión conviene apoyarla en un análisis operativo, no en el «va con la moda».
Consent Mode v2 y modelado de conversiones: recuperar señal perdida
Cuando un usuario rechaza cookies, los tags de Google no dejan de disparar: envían un ping sin identificadores. Ese ping alimenta el modelado de conversiones, un sistema que reconstruye estadísticamente las conversiones perdidas a partir de patrones de usuarios que sí consintieron. Consent Mode v2 —obligatorio en el EEE desde marzo de 2024 para seguir usando remarketing y funciones de audiencia— es la puerta de entrada a este modelado.
La consecuencia práctica es que un 10-40% (varía por sector y calidad de banner) de las conversiones que antes se perdían al rechazar cookies vuelven a aparecer en Google Ads y GA4, pero como cifras modeladas, no observadas. Para que esa señal sea suficiente el modelo necesita volumen y estabilidad: si un anunciante tiene pocas conversiones al mes, o cambia constantemente el consent banner, el modelo se cae. La implementación correcta del gestor de consentimientos es tan crítica como el tag en sí, algo que también se aborda en la guía sobre cómo implementar Consent Mode v2 sin perder conversiones.
Hay dos advertencias importantes. La primera es que las conversiones modeladas no se pueden desglosar al usuario individual: sirven para tomar decisiones agregadas de campaña, no para reporting a nivel de contacto. La segunda es que exigen tráfico. Cuentas con menos de un centenar de conversiones mensuales estables por campaña no llegan al umbral y Google devuelve los datos sin modelar, lo que a veces se lee erróneamente como «el modelado no funciona».
Modelos de atribución que sobreviven sin identificador cross-site
Sin cookies de terceros, los modelos de atribución basados en journeys individuales rastreados entre sitios (last-click, first-click, lineal, U-shape, W-shape) se quedan sin materia prima fuera del propio dominio. Lo que sobrevive es otro tipo de atribución: modelos que trabajan con datos agregados o con señales probabilísticas, y que responden a preguntas distintas.
El modelo de GA4 y Google Ads reparte el crédito entre puntos de contacto usando aprendizaje automático sobre los datos observados y modelados de la propia cuenta.
«Reparto entre canales dentro del ecosistema Google»
Regresión estadística sobre datos históricos agregados (inversión por canal, ventas, estacionalidad, factores externos) para estimar el ROI incremental de cada canal.
«¿Cuánto vende cada canal en agregado?»
Test geo o de audiencia holdout: apagar la inversión de un canal en una región durante un periodo y medir la caída real de ventas frente al grupo de control.
«¿Este canal aporta ventas incrementales o canibaliza?»
Preguntar directamente al usuario cómo ha llegado («¿Cómo nos conociste?») y usar esa respuesta como capa de calibración sobre los modelos técnicos.
«El usuario cuenta lo que las cookies ya no ven»
La combinación que hoy funciona en cuentas medianas es DDA para reparto táctico dentro de plataformas + MMM trimestral para reparto estratégico + tests de incrementalidad puntuales para validar. Cada modelo responde a una pregunta distinta y ninguno responde a todo: creer que un modelo único va a sustituir al journey completo es la trampa que hace que los equipos pierdan meses persiguiendo un dato que ya no existe. Este marco enlaza directamente con la forma de medir el ROAS real por canal más allá del reporting nativo.
Encuestas de atribución y self-reported data: la palanca infravalorada
Preguntar al cliente cómo ha llegado —en el checkout, en el formulario, en el onboarding— es una de las palancas más rentables de la medición sin cookies, y una de las que más se ignora. Aporta información que ningún modelo técnico puede reconstruir: intención declarada, canal recordado, motivo real de la conversión. El coste es un campo más en un formulario; el impacto sobre la calibración de la atribución es enorme.
La clave para que sirva es diseñarla bien. Preguntas cerradas con opciones curadas (Google, recomendación, redes sociales, email, evento, otros), campo opcional, no obligatorio, y presencia consistente en todos los puntos de conversión. Los datos declarados se comparan con los modelos técnicos y las divergencias son casi siempre reveladoras: un canal que aporta muchísimo pero que no se ve en DDA suele ser recomendación boca-oreja, prensa o vídeo en YouTube fuera del ecosistema medible.
Este dato no reemplaza a las plataformas técnicas: convive con ellas como capa de calibración. En cuentas donde la conversión cierra por teléfono o presencialmente, la encuesta atributiva es habitualmente la mejor señal disponible para decidir dónde invertir en awareness y branding, dos categorías especialmente invisibles para GA4 y Meta.
Métricas y KPIs que ganan peso cuando cae el dato observado
Cuando el dato individual se degrada, las métricas útiles cambian de forma. Ganan peso las que se pueden calcular con datos propios, las que operan en agregado y las que responden a decisiones de asignación de presupuesto. Bajan las que dependen de un journey cross-site completo o de una atribución exacta al usuario.
Coste de adquisición por canal calculado con inversión real ÷ conversiones observadas y modeladas. Sirve para reasignar presupuesto, no para asignar cada venta a un canal concreto.
Estimación del volumen de ventas que se pierde si un canal se apaga. Se calcula con MMM y tests de incrementalidad. Es lo que responde a «¿me merece la pena seguir invirtiendo aquí?».
Valor del cliente a lo largo del tiempo cruzado con la respuesta a «¿cómo nos conociste?». Distingue canales que traen clientes rentables de los que traen churn temprano.
Porcentaje de conversiones observables que se logra ligar a un contacto identificado del CRM. Es la métrica de salud del stack: si baja, se rompe la atribución agregada.
La operativa práctica que funciona es cruzar estas métricas con almacenamiento propio. GA4 exportado a BigQuery como data warehouse permite combinar el dato observado con el CRM y con las respuestas declaradas en la misma tabla, lo que abre la puerta a modelos internos personalizados sin depender de las limitaciones de la interfaz de GA4. Esa capacidad de cruzar fuentes es hoy más valiosa que tener el evento perfectamente trazado en el navegador.
Errores frecuentes al montar una medición sin cookies de terceros
Los tropiezos suelen ser de estrategia, no de configuración. Los siguientes son los que aparecen una y otra vez al auditar cuentas y explican por qué muchos stacks «modernos» siguen tomando decisiones ciegas pese al gasto en herramientas.
-
1Reproducir el reporting anterior sobre un dato ya distinto
Intentar seguir viendo «conversiones asignadas a keyword individual» cuando la atribución de journey cross-site ya no existe. Genera reports técnicamente estables pero conceptualmente falsos. Antes de replicar un dashboard, decidir qué preguntas de negocio sigue respondiendo el dato.
-
2Implementar server-side sin necesidad real
Un contenedor server-side sin volumen que lo justifique añade coste, complejidad y punto único de fallo. Antes de contratarlo hay que haber roto los límites de GTM cliente-side bien implementado: si el basic aún da margen, ese es el trabajo primero.
-
3Consent Mode mal configurado y luego culpar al modelado
Cuando el gestor de consentimientos no informa correctamente los flags a Google, no hay pings sin cookies y el modelado no arranca. Se ven caídas del 30-60% en conversiones registradas y se echa la culpa al algoritmo. La verificación con GA4 DebugView y el modo debug de Google Tag Manager evita el mal diagnóstico.
-
4Ignorar el Pixel de Meta + Conversions API
Meta Ads es el otro gran ecosistema afectado por la caída del dato en navegador. Configurar solo el Pixel sin CAPI reduce la calidad de las señales que optimizan las campañas y encarece los CPA. El estándar 2026 es Pixel + CAPI en paralelo, con event matching sobre datos hasheados.
-
5No preguntar al cliente cómo llegó
Prescindir de la encuesta atributiva es renunciar a la mejor señal disponible para canales invisibles: boca-oreja, prensa, YouTube, podcast, eventos. Una pregunta de 5 opciones en el formulario da más contexto de asignación de presupuesto que la mitad del stack técnico.
-
6Tratar cada plataforma como fuente de verdad independiente
Cada plataforma (GA4, Google Ads, Meta) contabiliza conversiones de forma distinta, con ventanas y modelos propios, y en ausencia de journey cross-site las diferencias se amplifican. Sumar las conversiones reportadas por cada una duplica y triplica ventas. El árbitro tiene que ser el CRM, no las plataformas.
El patrón común en los seis es tratar la nueva medición como una réplica de la anterior con parches encima. La medición sin cookies de terceros pide asumir la agregación, dar peso al CRM y aceptar que ciertas preguntas del pasado ya no tienen respuesta exacta —y que estaban devolviendo respuestas exactas equivocadas antes también—.
Preguntas frecuentes
¿Se puede seguir midiendo marketing en Google Ads sin cookies de terceros?
Sí, combinando Enhanced Conversions con datos first-party del CRM, Consent Mode v2 con modelado y atribución data-driven. Google Ads mantiene reporting fiable a nivel de campaña, aunque las conversiones a nivel de keyword individual pierden precisión y conviene decidir en agregado por grupo de anuncios o campaña.
¿El server-side tagging es imprescindible para medir sin cookies de terceros?
No. Es útil para cuentas de volumen medio-alto o con LTV alto, pero un GTM cliente-side bien implementado con Consent Mode v2, Enhanced Conversions y CAPI cubre la mayoría de los casos. El server-side aporta control del payload y esquivar bloqueadores, no «arreglar» la desaparición de cookies.
¿Qué tecnologías sobreviven de Google Privacy Sandbox?
Tras el anuncio de Google del 17 de octubre de 2025 solo se mantienen CHIPS (Cookies Having Independent Partitioned State), FedCM (Federated Credential Management) y Private State Tokens. El resto —Topics, Protected Audience, Attribution Reporting API, IP Protection, Private Aggregation y otros— se están retirando de Chrome.
¿Qué diferencia hay entre atribución modelada y atribución observada?
La observada mide conversiones con un identificador real del usuario en cada punto del journey. La modelada reconstruye estadísticamente las conversiones perdidas usando patrones agregados de usuarios similares. En 2026 la mayor parte del reporting es una mezcla de ambas: los datos observados alimentan al modelo y este rellena los huecos que dejan los rechazos de consentimiento.
¿Cuánto tiempo hace falta para tener un stack de medición sin cookies de terceros operativo?
Entre 4 y 12 semanas dependiendo del punto de partida. Las 4 semanas cubren un GTM cliente-side con Consent Mode v2, Enhanced Conversions y CAPI en una web sencilla; las 12 incluyen server-side, integración con CRM, exportación a BigQuery y calibración con encuesta atributiva. La mayor parte del tiempo no se va en configuración técnica sino en gobernanza de datos.
Este es el marco de trabajo que aplica el servicio de análisis de datos de Advanze cuando un cliente pide «recuperar la medición que se ha roto». No se trata de restaurar el stack anterior, sino de sustituirlo por otro que trabaje bajo las nuevas reglas: menos precisión aparente por usuario, más fiabilidad agregada, y decisiones de presupuesto que dejan de moverse por corazonadas.
¿Vuestra medición está tomando decisiones con un stack que ya no encaja con 2026?
Auditamos qué señales se pierden, qué queda usable, y cómo montar un stack first-party + server-side + modelado que sostenga las decisiones de inversión sin depender de tecnologías que ya no van a volver.