Cuando un usuario rechaza cookies en tu ecommerce y no tienes Consent Mode v2, esto es lo que pasa: el tag de Google no dispara, no sale ningún dato del navegador, y esa conversión desaparece. Para Google Ads, ese usuario nunca existió. Con Consent Mode v2 en modo Advanced, el tag dispara igualmente pero degradado: envía un cookieless ping —sin cookies, sin identificadores de usuario— y Google usa esos pings para conversion modeling: reconstruye estadísticamente las conversiones que no puede observar. La diferencia entre ambos escenarios, en un ecommerce europeo con tasas de rechazo del 20-40% (rango habitual del sector, varía por CMP y vertical), es una parte relevante de tu señal de conversión. Y Smart Bidding puja con la señal que tiene, no con la que existe.

Aquí está la frase que deberías tatuarte antes de seguir: el modeling no salva lo que no mides. Sin pings, no hay modelo específico de tu cuenta. Solo un modelo genérico rellenando huecos a ciegas.

Este post cubre la capa de consentimiento: qué exige Google, Basic vs Advanced, los errores que vemos en auditorías y cómo encaja con el server-side tracking que ya explicamos en el setup de sGTM en Cloud Run y en Cloudflare Workers + CAPI con deduplicación. Aquello era la tubería. Esto es la llave de paso.

Consent Mode es la API con la que tu web comunica a los tags de Google el estado de consentimiento del usuario. La v2, obligatoria para tráfico del Espacio Económico Europeo desde marzo de 2024 si quieres usar audiencias, remarketing y personalización de anuncios, añade dos señales a las dos que ya existían:

SeñalQué controlaDesde
ad_storageCookies de publicidad (p. ej. atribución de clic)v1
analytics_storageCookies de analítica (p. ej. duración de sesión, _ga)v1
ad_user_dataEnvío de datos de usuario a Google con fines publicitariosv2
ad_personalizationPublicidad personalizada (remarketing, audiencias)v2

Las dos nuevas no gestionan cookies: gestionan permiso de uso de datos. Sin ad_user_data y ad_personalization concedidos, Google no puede usar a ese usuario para remarketing ni audiencias, aunque ad_storage esté aceptado. Y sin señales de consentimiento correctamente comunicadas, incumples la política de consentimiento de usuarios de la UE de Google, con las restricciones de cuenta que eso implica.

Traducción para ecommerce: si vendes en España o en cualquier mercado EEA y tus campañas usan remarketing dinámico, Customer Match o audiencias de GA4, Consent Mode v2 no es opcional. Es el peaje de entrada.

Basic vs Advanced: la decisión que define cuánta señal conservas

Hay dos formas de implementar Consent Mode, y la diferencia práctica es enorme.

Basic mode

Los tags de Google se bloquean por completo hasta que el usuario consiente. Si rechaza, no sale ni un byte del navegador. Google ni siquiera sabe que hubo una visita.

  • Modeling: existe, pero se basa en un modelo general — variables agregadas como tipo de navegador, tipo de conversión y hora del día. No en el comportamiento real de tu sitio.
  • Ventaja: posición conservadora en privacidad. Nada se envía sin consentimiento explícito.
  • Coste: máxima pérdida de señal observable propia.

Advanced mode

Los tags cargan siempre, antes del banner. Si el usuario rechaza, no se escriben cookies ni se envían identificadores, pero el tag emite cookieless pings con datos no identificativos: timestamp, user agent, referrer y el estado de consentimiento.

  • Modeling: Google entrena un modelo específico de tu cuenta con tus propios pings. Las conversiones modeladas reflejan el comportamiento real de tu tráfico, no una media del sector.
  • Ventaja: conservas la mayor parte del valor de medición del tráfico que rechaza.
  • Coste: envías pings (sin cookies, pero pings) de usuarios que han dicho que no. La interpretación de si eso es compatible con la ePrivacy/RGPD en tu caso concreto no es una decisión de marketing: es de tu asesoría legal o DPO. Hay autoridades de protección de datos europeas que lo miran con lupa. Nosotros te contamos el trade-off técnico; el dictamen jurídico no es nuestro trabajo ni el de este post.

Comparativa rápida

BasicAdvanced
Tags con rechazoBloqueadosDisparan sin cookies
Datos enviados sin consentimientoNingunoCookieless pings (no identificativos)
Conversion modelingModelo generalModelo específico de tu cuenta
Señal para Smart BiddingMínimaSustancialmente mayor
Riesgo legal percibidoMenorA evaluar con legal

Nuestro criterio en ecommerce: Advanced cuando legal lo valida, Basic cuando la política de riesgo de la empresa manda. Lo que no es aceptable es la tercera opción que nos encontramos en la mayoría de auditorías: ninguno de los dos bien configurado.

Los 4 errores que vemos en auditorías de ecommerce

Consent Mode exige un comando default antes de que cargue cualquier tag de Google, y un update cuando el usuario decide. El error clásico: el CMP dispara el update pero nadie configuró el default, o el default se ejecuta después de que GTM ya haya disparado tags. Resultado: los primeros hits de cada sesión salen con estado de consentimiento indefinido, y Google los trata de forma inconsistente. En GTM esto se resuelve con la plantilla del CMP o un tag de inicialización de consentimiento en Consent Initialization — All Pages, no en All Pages a secas.

Ironía habitual: implementas Advanced mode para conservar pings, pero el CMP está configurado en modo bloqueo de scripts (prior blocking) y no deja cargar gtag/GTM hasta el consentimiento. Has pagado Advanced y estás operando en Basic sin saberlo. El CMP debe comunicar el estado de consentimiento vía Consent Mode, no estrangular los tags por su cuenta. Son dos mecanismos distintos y mal combinados se anulan.

3. Nadie lo ha testeado con Tag Assistant

Consent Mode falla en silencio. La web funciona, el banner sale, los informes muestran datos… de los que aceptan. La única forma de verificarlo es abrir Tag Assistant, simular rechazo y comprobar en la pestaña Consent que el default llega antes que cualquier tag, que el update refleja la elección real y que los hits salientes llevan gcs/gcd coherentes (los parámetros que codifican el estado de consentimiento en cada ping). Si nunca has visto el parámetro gcd de tus propios hits, no sabes qué estás enviando.

4. Duplicación con CAPI/server-side sin deduplicación consciente del consentimiento

Si tienes Meta CAPI o GA4 vía server-side y además tags client-side, ya deberías tener deduplicación por event_id / transaction_id — lo explicamos en detalle en el post de Cloudflare Workers y CAPI. El matiz nuevo: cuando el usuario rechaza, el evento client-side desaparece o se degrada a ping, pero tu servidor puede seguir enviando el evento completo por CAPI. Ahora no tienes duplicación: tienes un bypass del consentimiento, que es peor. El estado de consentimiento tiene que viajar con el evento hasta el servidor y aplicarse también allí.

Consent Mode v2 + server-side: no es “o”, es “y”

Aquí está la confusión más cara de 2026. Nos llegan ecommerces que han montado sGTM o un Worker de Cloudflare y creen que eso “arregla el tema cookies”. No.

  • Consent Mode v2 decide QUÉ señal sale del navegador. Es la capa de permisos: con consentimiento sale el evento completo, sin él sale un ping anónimo (Advanced) o nada (Basic).
  • Server-side decide CÓMO viaja esa señal. First-party, sin bloqueos de ITP/adblockers, con enriquecimiento y deduplicación — todo lo que cubrimos en el setup de sGTM.

El server-side recupera señal que se pierde por razones técnicas (bloqueadores, ITP, tags que no cargan). Consent Mode gestiona señal que se pierde por razones legales (el usuario dice no). Son pérdidas distintas con soluciones distintas:

CapaPérdida que atacaHerramienta
ConsentimientoUsuario rechaza cookiesConsent Mode v2 + CMP
TransporteAdblockers, ITP, tags rotossGTM / Cloudflare Workers
DeduplicaciónDoble conteo client+serverevent_id compartido

Montar server-side sin Consent Mode v2 te deja fuera de audiencias y remarketing en EEA e incumpliendo la política de Google. Montar Consent Mode sin server-side te deja perdiendo el 20-40% adicional de señal técnica que sí podrías capturar legalmente. Necesitas las tres filas de la tabla.

Y un aviso: el server-side no es una vía para esquivar el consentimiento. El estado de Consent Mode debe propagarse al contenedor server y respetarse ahí. Un endpoint first-party que reenvía datos de usuarios que rechazaron no es ingeniería, es una sanción esperando fecha.

Checklist de implementación (GTM + CMP)

Orden real de trabajo, probado en stacks Shopify/WooCommerce con Cookiebot o Usercentrics:

  1. Elige CMP certificado por Google (Cookiebot, Usercentrics, CookieYes, OneTrust…). Los certificados implementan las 4 señales de v2 de serie; con un banner casero tendrás que cablear gtag('consent', ...) a mano.
  2. Configura el consent default. En GTM: plantilla oficial del CMP disparada en Consent Initialization — All Pages, con las 4 señales en denied por defecto para EEA (o el default que legal determine). Verifica que ningún otro tag dispara en ese trigger.
  3. Decide Basic vs Advanced con legal presente. Documenta la decisión. Si Advanced: desactiva el prior blocking del CMP para los tags de Google y deja que Consent Mode gobierne (error #2 de arriba). Si Basic: activa el bloqueo y asume el modelo general.
  4. Activa los consent checks nativos en GTM. Revisa en cada tag de Google la sección Consent Settings. Los tags de Google traen comprobaciones integradas (built-in consent checks); los tags de terceros (Meta, TikTok, Klaviyo) necesitan additional consent checks configurados a mano.
  5. Propaga el consentimiento al server-side. Si usas sGTM o Workers, asegúrate de que el estado de consentimiento llega en el payload y de que el contenedor server filtra en consecuencia — incluido lo que sale hacia Meta CAPI.
  6. Testea con Tag Assistant, en los dos caminos. Sesión aceptando todo y sesión rechazando todo. Comprueba: orden default→update, parámetros gcs/gcd en los hits, y que en rechazo con Advanced salen pings sin cookies (y con Basic, nada).
  7. Verifica el estado en las plataformas. En Google Ads: Objetivos → Configuración de conversiones → Diagnóstico de consentimiento. En GA4: Administración → Señales de consentimiento. Ambos te dicen si están recibiendo las señales v2 correctamente.
  8. Espera y mide. El conversion modeling específico de cuenta necesita volumen de pings y días de datos. No juzgues el impacto en 48 horas.

Cuánta señal conservas en cada escenario

Estimaciones orientativas para un ecommerce EEA con ~30% de rechazo de cookies. No son datos de clientes ni cifras de Google: son rangos ilustrativos para entender las magnitudes; tu caso depende de CMP, vertical, mix de dispositivos y tasa de rechazo real.

EscenarioSeñal observadaSeñal modeladaSeñal total aprox.
Sin Consent Mode v2 (tags bloqueados sin señal)~70%~0%*~70%
Basic mode~70%+5-10% (modelo general)~75-80%
Advanced mode~70%+15-25% (modelo específico)~85-95%

*Sin señales de consentimiento comunicadas, Google no puede aplicar modeling sobre ese hueco — y además pierdes audiencias y remarketing en EEA por incumplir el requisito de v2.

La lectura correcta de la tabla no es “Advanced recupera un 20%”. Es: la diferencia entre no hacer nada y hacerlo bien es del orden del 15-25% de tu señal de conversión, que es exactamente la señal con la que Smart Bidding decide tus pujas y tu presupuesto. Un 20% menos de señal no es un 20% menos de datos en un dashboard: es un algoritmo pujando con un mapa incompleto.

¿Sabes qué está saliendo (o no) de tu web ahora mismo?

La mayoría de ecommerces que auditamos no pueden responder a tres preguntas: qué estado de consentimiento llevan sus hits, si su CMP está anulando su Consent Mode, y si su CAPI respeta los rechazos. Son 20 minutos de Tag Assistant y valen más que cualquier informe de ROAS.

En la auditoría de tracking de Sellencia revisamos exactamente eso: Consent Mode v2 (default, update, señales v2, Basic/Advanced), integración CMP+GTM, propagación de consentimiento a server-side y deduplicación con CAPI. Sin humo: sales con la lista de lo que está roto y el orden en que arreglarlo.

Pide tu auditoría de tracking →

Fuentes oficiales:

Preguntas frecuentes

¿Consent Mode v2 es obligatorio si mi ecommerce solo vende en España?
Sí. España es EEA y desde marzo de 2024 Google exige ad_user_data y ad_personalization para remarketing y audiencias. Sin ellas incumples su política de consentimiento de la UE.
¿Advanced mode es legal en España?
No hay respuesta única. Advanced envía pings sin cookies de usuarios que rechazan; si eso encaja en ePrivacy/RGPD es decisión documentada de tu asesoría legal o DPO, no de marketing.
¿El conversion modeling sustituye a las conversiones reales?
No. Estima las conversiones no observables a partir de las observables y de los pings. Sin pings propios, Google solo aplica un modelo genérico: el modeling no salva lo que no mides.
¿Si ya tengo sGTM o Cloudflare Workers necesito Consent Mode igualmente?
Sí. El server-side resuelve la pérdida técnica (ITP, adblockers); Consent Mode, la capa legal. Y el contenedor server debe recibir y respetar el estado de consentimiento del usuario.