Medición sin cookies de terceros: el stack que funciona

¿Cuál es el estado real de las cookies en 2026?

Tres hechos verificables:

1. Chrome mantiene la elección del usuario. El anuncio de Privacy Sandbox de abril de 2025 confirma que no habrá un prompt independiente y que se conserva el enfoque actual. El modo Incógnito ya bloquea cookies de terceros por defecto.
2. Privacy Sandbox se recortó fuerte. En octubre de 2025, Google anunció el retiro de varias tecnologías por baja adopción, entre ellas Topics, Protected Audience, Attribution Reporting API, Private Aggregation y Related Website Sets. Siguen adelante CHIPS, FedCM y Private State Tokens, y Google continúa participando del estándar interoperable de Attribution en el proceso de estándares web.
3. Las cookies first-party tampoco son eternas. Google documenta que los navegadores limitan la vida de las cookies first-party si el usuario no vuelve: máximo de 400 días en Chrome y 7 días en Safari. Las cookies _ga y _ga_<container-id> de Google Analytics 4 (GA4) tienen una expiración por defecto de 2 años, pero el navegador manda.

Traducido: la estrategia no cambia porque Chrome no cambió. La medición robusta ya no puede depender de un identificador de navegador que puede desaparecer en siete días.

El stack de respuesta, capa por capa

1. First-party data: la base

Todo lo demás se apoya aquí. Sin identificadores propios (email, teléfono, ID de cliente, order ID) recolectados con consentimiento y almacenados de forma consistente, las capas siguientes no tienen materia prima. En la práctica esto significa: pedir el dato en el momento correcto del journey, normalizarlo, unificarlo entre canales y poder recuperarlo en el momento de la conversión para enviarlo hasheado.

2. Consent Mode: básico vs avanzado

Consent Mode es la API de Google que permite que los tags ajusten su comportamiento según la decisión de consentimiento del usuario. Controla cuatro señales independientes: ad_storage, analytics_storage, ad_user_data y ad_personalization.

La diferencia entre los dos modos de implementación es sustancial: en el modo básico, los tags se bloquean hasta que el usuario interactúa con el banner y no se transmite absolutamente nada antes de esa interacción; en el modo avanzado, los tags cargan con valores por defecto denegados, envían pings sin cookies cuando el consentimiento se rechaza y eso habilita un modelado de conversiones específico del anunciante. El modo básico solo da acceso al modelo general —menos detallado— de Google.

Si vas a implementar Consent Mode, implementa el avanzado. Es la única versión que habilita modelado específico de tu cuenta y la única que alimenta el circuito de modelado descrito en la sección siguiente.

Para la explicación completa de cada parámetro, la matriz de comportamiento según el estado de consentimiento y la secuencia de adopción recomendada, revisa la guía de Consent Mode v2.

Construye una medición que siga funcionando cuando falten cookies

Te ayudamos a priorizar consentimiento, recuperación de señal y datos propios según lo que realmente se pierde en tu operación.

• 1

  Diagnóstico gratuito de tu stack GMP

  Un especialista revisa tu implementación actual (GA4, GTM, DV360, Ads) y te dice qué priorizar primero.

• 2

  Plan de acción a medida

  Sales de la llamada con next steps concretos para tu cuenta, no con una plantilla genérica.

• 3

  Sin compromiso, sin venta forzada

  Hablas con un especialista técnico, no con un vendedor. Si no encajamos, te lo decimos.

GMP Sales Partner · Implementamos GMP end-to-end · Equipo LatAm

Respuesta a la brevedad

Diseñar mi medición sin cookies

Completa el form y coordinamos una asesoría sobre tu caso.

Cargando el formulario seguro de HubSpot…

Este formulario lo provee HubSpot y los datos que envíes se procesan allí. Consulta nuestra política de privacidad .

Sin compromiso · Google Marketing Platform Sales Partner

3. Modelado de conversiones y comportamiento

En GA4, el modelado de comportamiento para Consent Mode usa machine learning para estimar el comportamiento de usuarios que rechazaron cookies analíticas, entrenando sobre el comportamiento de usuarios similares que sí aceptaron. No se activa solo: la propiedad tiene que cumplir requisitos publicados por Google:

• Consent Mode habilitado en todas las páginas del sitio o pantallas de la app.
• Implementación avanzada (los tags cargan antes del banner y en todos los casos).
• Al menos 1.000 eventos por día con analytics_storage='denied' durante al menos 7 días.
• Al menos 1.000 usuarios diarios enviando eventos con analytics_storage='granted' durante al menos 7 de los 28 días previos.

Cumplir estos umbrales no garantiza elegibilidad: el modelo aplica criterios adicionales de calidad. Cuando se activa, los datos modelados se ven eligiendo la identidad de reporte Combinada (Blended).

El ciclo completo, de punta a punta

El modelado suele explicarse como una caja negra que “estima lo que falta”. No lo es: es un circuito de cuatro etapas que se puede auditar en cada punto.

1. Implementación. Instalas Consent Mode en el sitio o la app. Sin esta pieza, el circuito no arranca.
2. Pings de estado de consentimiento. Cuando el usuario deniega, los tags no escriben cookies pero sí envían pings que comunican el estado de consentimiento y la actividad, sin identificadores.
3. Ajuste del comportamiento del tag. El tag modifica lo que hace según la señal recibida: qué almacena, qué envía y por qué dominio lo envía.
4. Reporte. Google usa esos pings, junto con el comportamiento observado de los usuarios que sí consintieron, para modelar el tramo no observable y devolverlo al reporte.

El ejemplo más claro de qué recupera este circuito es el de la atribución perdida. Supongamos 100 usuarios que hacen clic en un anuncio y 20 que convierten, pero solo una parte consintió el almacenamiento. Sin Consent Mode, las conversiones de los usuarios que no consintieron no se pueden vincular al clic: quedan sin atribuir y suelen terminar contabilizadas en el bucket de “Directo”, como si el anuncio no hubiera existido. Con Consent Mode y modelado, esas conversiones vuelven a atribuirse al canal que efectivamente las generó.

Eso cambia una discusión concreta: la caída de conversiones que muchas cuentas atribuyen a “el consentimiento nos rompió la medición” es, en buena parte, atribución que se mudó a Directo. El modelado no inventa conversiones; reasigna las que ya existían.

El modelado no vive solo en Google Ads

Es un punto que se pierde con frecuencia porque la documentación de modelado suele leerse desde GA4: el modelado de conversiones opera también en Display & Video 360, Campaign Manager 360 y Search Ads 360, además de Google Ads. Para un anunciante que compra medios a través de la Google Marketing Platform, eso significa que la calidad de la implementación de Consent Mode en el sitio impacta el reporte de toda la plataforma, no solo el de search.

La contracara es la prudencia del modelo: Google solo incorpora conversiones modeladas cuando su nivel de confianza es alto. Cuando no lo es, las deja sin asignar en lugar de repartirlas, precisamente para no sobreestimar el resultado. Es la razón por la que el modelado no “tapa” un tagging pobre: si la señal de entrada es débil, el modelo se abstiene.

4. Enhanced conversions

Enhanced conversions complementa tus conversiones existentes enviando datos first-party hasheados con el algoritmo de una vía SHA256 antes de salir del navegador. Google usa ese hash para hacer match con cuentas de Google que interactuaron con tus anuncios.

Hay dos variantes:

• Enhanced conversions for web: para ventas y eventos que ocurren en el sitio. Mejora la medición de conversiones online.
• Enhanced conversions for leads: para ventas que se cierran fuera del sitio a partir de un lead web. Combina el dato hasheado del formulario con la importación de conversiones offline.

Para operaciones B2B y de generación de leads en LatAm, la segunda variante suele ser la que más señal recupera, porque cierra el hueco entre el formulario y el CRM.

5. Server-side tagging (sGTM)

Google identifica tres razones para mover el tagging al servidor: mejorar los controles de privacidad, mejorar el rendimiento del sitio y mejorar la calidad del dato.

• Privacidad y control: el contenedor de servidor actúa como buffer. Puedes validar, parsear, anonimizar o bloquear requests antes de que salgan hacia los proveedores, y obscurecer vectores de fingerprinting como la IP y otras cabeceras HTTP.
• Rendimiento: el cliente envía un único stream de datos al contenedor de servidor en lugar de múltiples requests casi idénticos a cada proveedor, y carga menos librerías JavaScript.
• Calidad del dato: al correr en contexto first-party, las cookies del navegador se pueden escribir con el flag HttpOnly, lo que las hace más duraderas y seguras. Además permite enriquecer el dato con información que no debería exponerse en el navegador: secrets de API, márgenes, datos personales.

Apps iOS: On-Device Measurement

Todo lo anterior resuelve la web. En apps iOS el problema es distinto y anterior: desde que Apple exige el prompt de ATT para acceder al IDFA, buena parte de las conversiones de campañas de apps no se pueden vincular al clic que las originó. La respuesta de Google para ese escenario es On-Device Measurement (ODM), y no está cubierta por ninguna de las cinco capas de arriba.

Cómo funciona

La idea central es invertir el lugar donde ocurre el match. En lugar de enviar identificadores a un servidor para cruzarlos ahí, el cálculo se hace dentro del dispositivo mediante cómputo privado multiparte. El resultado es que ninguna información identificable sale del teléfono ni se revela a terceros; lo que viaja es la conversión medida, no el dato que permitió medirla.

El flujo, en cuatro momentos:

1. El usuario ve un anuncio de tu app en una propiedad de Google y hace clic.
2. Google deposita en el dispositivo la información de ese clic, en forma protegida.
3. El usuario instala la app y completa una acción relevante: se registra, inicia sesión, compra.
4. El SDK de Google Analytics para Firebase realiza el cómputo en el dispositivo y, si hay coincidencia, reporta la conversión.

Hay dos variantes según qué usa para el match: la de datos first-party, que trabaja con el email o el teléfono que la app recolecta en su propia experiencia de login, y la de datos de evento, que usa datos de evento desidentificados y temporales derivados de señales del dispositivo.

Qué hace falta para activarlo

• App con iOS 12 o superior e integración con el SDK de Google Analytics para Firebase. Para la variante de datos de evento, Google requiere una versión reciente del SDK (11.14.0 o posterior).
• Para la variante de datos first-party: una experiencia de registro o login que capture email o teléfono, y la llamada a la API de medición on-device con ese dato.
• Para la variante de datos de evento: la propiedad de Google Analytics vinculada a la cuenta de Google Ads que corre las campañas de apps iOS.
• Restricción regional: Google documenta que la función está inactiva para usuarios ubicados en el Espacio Económico Europeo, Reino Unido y Suiza.

La conclusión operativa para un anunciante con app: si estás corriendo campañas de apps en iOS y tu SDK de Firebase está desactualizado, no es una deuda técnica menor. Es la diferencia entre optimizar con conversiones observadas y optimizar a ciegas.

Orden de implementación recomendado

No es una lista de compras: es una secuencia.

1. Auditar el tagging actual. Antes de agregar capas, verifica que lo que ya tienes dispara bien. Puedes empezar con la auditoría de tagging y Consent Mode.
2. Consent Mode avanzado con un CMP serio. Sin esto, el modelado no existe.
3. Enhanced conversions en Google Ads, web y leads según corresponda.
4. BigQuery export de GA4 desde el día uno, para tener el dato crudo bajo tu control.
5. sGTM cuando el volumen y la complejidad lo justifiquen.
6. Higiene de UTMs, porque nada de lo anterior arregla un tagging de campañas inconsistente. El generador de UTMs evita el problema de raíz.

Si tu propiedad todavía no está bien configurada, arranca por GA4: qué es y cómo configurarlo, donde están los pasos de instalación, conversiones y vinculación con Google Ads.

El checklist de fondo

La secuencia de arriba es el orden de trabajo. Esta es la lista contra la que Google recomienda verificar que la medición esté preservada, y sirve como control final:

• Tagging sitewide con el Google tag o con Google Tag Manager, cubriendo Google Ads, Google Analytics y Floodlight. Si compras medios en la Google Marketing Platform, esto incluye el formato de tag de Floodlight para Campaign Manager 360, Search Ads 360 y Display & Video 360.
• Enhanced conversions implementadas, en su variante web o de leads según el modelo de negocio.
• Google Analytics en uso como capa de medición, no solo como reporte paralelo.
• Consent Mode implementado, y en su modalidad avanzada.
• Tags de Floodlight etiquetados y organizados, con una convención de nombres que permita reconocer qué mide cada uno. Un Floodlight sin nomenclatura clara es un dato que nadie va a poder usar dentro de seis meses.

Qué no hacer

• Implementar Consent Mode básico “porque es más rápido”: pierdes el modelado específico del anunciante.
• Enviar datos sin hashear: enhanced conversions hashea en el cliente antes de transmitir, no después.
• Suponer que sGTM arregla un tagging mal armado. Lo amplifica.
• Esperar a que “se caigan las cookies” para actuar. La señal ya se degradó por consentimiento y por límites de vida de cookies, independientemente de la decisión de Chrome.

Mide primero dónde estás parado: ejecuta el GA4 Data Strength Score para tener un diagnóstico de tus datos en 15 preguntas. Para construir la estrategia estructurada de datos propios que sostiene este stack a largo plazo —captura con consentimiento, consolidación y activación—, revisa la guía de estrategia de first-party data. Si quieres un plan de implementación priorizado para tu operación, así trabajamos la recuperación de señal y la activación de datos propios.