Esta guía es para tiendas de Shopify que eligen entre el modo básico y el avanzado de Consent Mode v2 —y también el estado en el que un banner bloquea las etiquetas pero no envía ninguna señal. Compara los tres a nivel de mecanismo: qué sale del navegador antes de una elección, cómo transporta la decisión la Customer Privacy API de Shopify y qué muestran después GA4 y Google Ads.
No clasifica modos ni herramientas, ni se pronuncia sobre tus obligaciones legales; eso es cosa de un abogado especializado en privacidad. Esto cubre la implementación técnica, no asesoramiento legal. No cita precios de proveedores; para el precio de las CMP, consulta la página de precios de cada proveedor.
¿Qué envía realmente el modo básico de Consent Mode v2 antes de una elección?
En el modo básico, la etiqueta de Google no se carga hasta que el visitante responde al banner, así que Google no recibe nada antes de ese punto —ni siquiera el estado de consentimiento por defecto— y nada si el visitante rechaza. Tras una concesión, la etiqueta se carga y envía los estados de consentimiento por defecto y actualizado.
En Shopify tienen que encajar dos mecanismos: el banner o la CMP escriben la decisión a través de la Customer Privacy API, y tu cargador de etiquetas la lee antes de inyectar la etiqueta de Google. Son independientes, y el fallo aparece cuando los dos no coinciden —la CMP registra una elección mientras un fragmento del tema, una etiqueta de app o un píxel web inyecta la etiqueta.
El coste es estructural: Google indica que, en el modo básico, el modelado de conversiones de Google Ads recurre a un modelo general.
¿Qué envía el modo avanzado de Consent Mode v2 antes de una elección?
El modo avanzado carga la etiqueta de Google al abrir la página con los valores de consentimiento por defecto en denied; mientras el consentimiento está denegado, la etiqueta envía pings sin cookies y ninguna medición completa, y solo cambia a medición completa y cookies con una concesión.
Google describe tres pings sin cookies mientras el consentimiento está denegado: pings del estado de consentimiento desde cada página donde Consent Mode está activado, pings de eventos clave y pings de Google Analytics.
Esos pings son mínimos, pero «sin cookies» no significa «sin identificadores». Google enumera su contenido como información funcional (marca de tiempo, user agent, referrer) e información agregada o no identificativa: si la página actual o una anterior llevaba parámetros de clic en anuncios como GCLID o DCLID, un estado de consentimiento booleano y un número aleatorio generado en cada carga de página. Con ad_storage denegado, Google indica que no se escriben nuevas cookies de publicidad ni identificadores de dispositivo y que no se lee ninguno, y que los productos de Ads truncan las direcciones IP en la recogida; aun así, la URL completa de la página, incluidos los parámetros de clic en anuncios, se sigue recogiendo. ads_data_redaction redacta esos identificadores en los pings de consentimiento y de eventos clave, y en las URL de página que los contienen.
El estado de consentimiento viaja en los parámetros de la solicitud. Google documenta que gcs transmite ad_storage y analytics_storage, y que gcd se envía siempre, esté activo o no Consent Mode.
El modo avanzado también habilita el modelo de conversiones de Google Ads específico del anunciante. El modelado del comportamiento de GA4 es un producto aparte con sus propios requisitos: Consent Mode en todas las páginas, etiquetas cargadas antes del diálogo de consentimiento en todos los casos, al menos 1.000 eventos al día con analytics_storage denegado durante al menos 7 días, y al menos 1.000 usuarios diarios que envían eventos con consentimiento concedido durante al menos 7 de los 28 días anteriores. Cumplirlos no garantiza la elegibilidad; el modelo aplica sus propias comprobaciones de calidad. El diagnóstico de conversiones de Google Ads distingue «Consent mode is implemented» de «Consent mode is implemented and modeling is active», y Google documenta un umbral de clics de Ads de 700 clics en 7 días.
En Shopify esa misma Customer Privacy API es una API JavaScript del storefront, mapeada de otra forma: la CMP traduce sus finalidades a los tipos de consentimiento de Google y envía la actualización con una elección. Los píxeles web son un contexto de ejecución aparte —estricto para los píxeles de apps, lax para los píxeles personalizados—, donde el píxel lee init.customerPrivacy y se suscribe a visitorConsentCollected. El gestor de píxeles de Shopify solo libera un píxel cuando el permiso del visitante cubre todas las finalidades declaradas, así que un píxel retenido hasta que existe el permiso no puede emitir pings de Google previos al consentimiento; esos vienen de la etiqueta de Google en el documento del storefront. Google indica que las etiquetas de Google dentro de un píxel personalizado de Shopify no son una implementación compatible.
¿Qué pasa si no usas ningún Consent Mode?
Un banner que bloquea tus etiquetas de Google sin llamar a ninguna API de consentimiento deja a Google sin poder verificar la elección del visitante; la guía de Google para el EEE dice que esto puede provocar pérdida de datos. Los modos básico y avanzado existen precisamente para corregirlo.
Esa misma documentación indica que los anunciantes deben recoger el consentimiento de los usuarios finales del EEE y compartir señales con Google para seguir usando las etiquetas aplicables de medición, personalización y remarketing; sin señales válidas, esas funciones quedan restringidas para el tráfico del EEE. La configuración de consentimiento de GA4 muestra, por flujo de datos, si están llegando las señales de publicidad y de analítica del comportamiento.
Así que no usar Consent Mode no es neutro: es el estado que las otras dos opciones existen para mejorar.
Comparación lado a lado
La tabla compara los tres estados según los criterios que deciden la mayoría de las implementaciones en Shopify. Describe compromisos y no los clasifica; ninguno repara un evento purchase roto por motivos que no tienen relación.
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Criterio | Consent Mode v2 básico | Consent Mode v2 avanzado | Sin Consent Mode (solo bloqueo de la CMP) |
|---|---|---|---|
| Origen de los eventos | La etiqueta se inyecta solo después de que el visitante elija | La etiqueta se carga al abrir la página, con los valores por defecto en denied | Decide el cargador o la CMP; no se llama a ninguna API de consentimiento |
| Cobertura de purchase y reembolsos | Ninguno de los dos modos instrumenta las compras o los reembolsos; tu tema, tu app o tu píxel deben enviar el purchase, y los reembolsos necesitan su propia ruta de datos de pedido | La misma instrumentación; Consent Mode solo gobierna cuándo la señal puede llevar medición completa | La misma instrumentación, pero los eventos llegan a Google sin ningún estado de consentimiento adjunto |
| Deduplicación | Se hereda de tu ruta de compra de Shopify; no cambia con el modo | Igual | Igual |
| Gestión del consentimiento | Etiquetas retenidas hasta la concesión; estados enviados después de conceder | Valores por defecto en denied, actualización con la elección, pings mientras está denegado | Lo registra la CMP, pero no se señala a Google |
| Control y destino de los datos | El comerciante controla la carga de etiquetas; nada llega a Google antes de una concesión | El comerciante controla los valores por defecto y las actualizaciones; las solicitudes sin cookies llegan a Google mientras está denegado | La CMP controla el bloqueo; Google recibe solicitudes sin estado de consentimiento |
| Dependencia y lock-in | Depende del cargador de la CMP y de tu propio bloqueo | Depende del mapeo de la CMP a los tipos de consentimiento de Google | Depende enteramente de la CMP |
| Carga de mantenimiento | Revisar el bloqueo cuando cambie el cargador o la CMP | Revisar los valores por defecto, las actualizaciones y la lógica por región | Solo hay que construir el bloqueo de la CMP; las funciones del EEE siguen restringidas |
| Para quién encaja | Tiendas que no quieren cargar una etiqueta de Google antes de tiempo | Tiendas que quieren elegibilidad para el modelado y cobertura en el EEE | Tiendas dispuestas a perder la medición de Google en el EEE |
Tabla de decisión
Relaciona tu situación con un punto de partida. Son valores por defecto para casos habituales, no reglas.
Tabla comparativa — desplázate horizontalmente para ver todas las columnas
| Si tu situación es… | Elige… |
|---|---|
| Los visitantes del EEE son una parte significativa del tráfico y necesitas el modelado de conversiones de Google Ads específico del anunciante | Avanzado: el básico no envía ninguna señal previa al consentimiento y modela desde el modelo general de Google |
| Quieres que el modelado del comportamiento de GA4 sea elegible | Avanzado: Google exige que las etiquetas se carguen antes del banner en todos los casos |
| Ninguna solicitud a Google puede producirse antes de una elección | Consent Mode v2 básico |
| Usas el modo básico y quieres saber qué modelado te queda | El modelo general de conversiones de Ads de Google; el avanzado solo si necesitas el específico del anunciante |
| Tu CMP registra el consentimiento pero Google no recibe ninguna señal | Implementa Consent Mode; el básico es un primer paso válido |
| Tu evento purchase ya está roto o duplicado | Ninguno: arregla primero la ruta de compra |
| No sabes qué recibe Google actualmente | Audita el valor por defecto y la actualización antes de elegir un modo |
Cuándo no usar cada opción
El básico renuncia a profundidad de modelado, el avanzado envía pings sin cookies antes de una elección y no usar Consent Mode pone en riesgo tus funciones del EEE.
No elijas el modo básico si necesitas el modelado del comportamiento de GA4 —sus requisitos previos exigen que las etiquetas se carguen antes del diálogo en todos los casos— o si el modelo general de Ads no basta para tu puja en el EEE. El básico sí admite el modelo general de conversiones de Google Ads.
No elijas el modo avanzado cuando tu posición legal prohíba cualquier solicitud a Google antes de una elección; cuando tu CMP no pueda mapear las finalidades a los cuatro tipos de consentimiento de Google; o cuando nadie pueda verificar el valor por defecto y la actualización, porque el modo avanzado falla en silencio cuando la actualización nunca se dispara.
No prescindas de Consent Mode cuando anuncias a usuarios del EEE, necesitas públicos o remarketing allí, o estás tratando «el banner bloquea las etiquetas» como equivalente a Consent Mode.
Cómo verifico esto en implementaciones reales
La verificación cubre qué establece la página antes de cualquier etiqueta, qué cambia con el consentimiento, qué informa cada plataforma y si las compras cuadran con los pedidos.
- Lee el valor por defecto en Tag Assistant. Confirma que los cuatro parámetros —
ad_storage,ad_user_data,ad_personalization,analytics_storage— están en denied antes de que se ejecuten las etiquetas. - Concede el consentimiento y lee la actualización. Confirma que los cuatro están en granted y comprueba después qué etiquetas se dispararon o quedaron bloqueadas. Una actualización ausente apunta al cableado de la CMP.
- Inspecciona las solicitudes. Confirma que el estado de consentimiento está presente en los parámetros de la solicitud, que el modo avanzado envía una solicitud con estado denegado antes de una elección y que el básico no envía ninguna. Repítelo con una ubicación del EEE simulada.
- Lee lo que informan las plataformas. En el diagnóstico de conversiones de Google Ads, distingue «Consent mode is implemented» de «Consent mode is implemented and modeling is active», teniendo en cuenta un retraso documentado de hasta dos semanas. DebugView de GA4 muestra los eventos llegando en directo.
- Comprueba el lado de Shopify. Confirma en qué contexto de ejecución se ejecuta cada etiqueta: la Customer Privacy API y la etiqueta de Google pertenecen al documento del storefront, mientras que un píxel web está en su propio sandbox, lee
init.customerPrivacyy se suscribe avisitorConsentCollected. Un píxel que Shopify todavía no ha liberado no puede ser el origen de un ping previo al consentimiento. Donde también haya eventos de Meta, Test Events de Events Manager debería mostrar que el píxel obedece el mismo bloqueo. - Concilia con los pedidos. Compara los purchase de GA4 con una exportación de pedidos de Shopify de un periodo cerrado usando el método estándar a nivel de pedido. Consent Mode cambia la calidad de la señal, no cómo concilias: la conciliación de pedidos es donde se ve una diferencia real.
Modos de fallo habituales
Consent Mode puede fallar en el cableado aunque el modelo esté sano: un valor por defecto establecido demasiado tarde, una actualización que nunca se dispara, un valor por defecto por región que contradice el banner o una CMP que registra una elección que ninguna etiqueta lee.
- Valor por defecto establecido después de que una etiqueta ya se haya ejecutado, así que Consent Mode no afecta a la solicitud ya enviada.
- Actualización llamada al descargarse la página, así que el navegador cancela la solicitud y el estado concedido nunca llega a Google.
- La elección no se persiste, así que un visitante que concedió recarga en el valor por defecto denegado en la página siguiente.
- Ninguna actualización —el banner registra una decisión mientras la etiqueta se queda en su estado por defecto, en cualquier dirección.
- Lógica por región ausente o contradictoria, así que los valores por defecto del EEE se filtran a otro tráfico o contradicen el banner.
- Mapeo de finalidades incompleto, o dos rutas de etiqueta de Google activas a la vez y cargando etiquetas con valores por defecto distintos.
Limitaciones
Consent Mode cambia lo que Google recibe y lo que puede modelar. No convierte en verdadera una cifra sin conciliar, no recupera el tráfico que un visitante rechazó ni sustituye al asesoramiento legal; todo modo queda acotado por la elección del visitante y las protecciones del navegador.
Los datos modelados son estimaciones, no observaciones. Google indica que el modelado del comportamiento se incluye solo cuando la confianza en la calidad del modelo es alta, y que cuando no hay suficiente tráfico con consentimiento para alimentar el modelo, los eventos de los usuarios que rechazan el consentimiento no se informan en absoluto. Varias funciones de GA4 nunca lo incluyen, entre ellas los públicos, el explorador de usuarios, los informes de retención, las métricas predictivas y la exportación a BigQuery. En los informes, el modelado se aplica a las métricas de usuario, sesión y usuario nuevo, pero no a recuentos de eventos como page_view.
El sandbox de píxeles de Shopify y el documento del storefront son contextos de ejecución separados: el píxel que observa el consentimiento no es la etiqueta de Google que actúa en consecuencia, así que pueden discrepar si las finalidades declaradas, el mapeo de la CMP y los valores por defecto de la etiqueta se separan. Ningún Consent Mode arregla las diferencias de atribución entre GA4, Google Ads y los pedidos de Shopify: cuentan cosas distintas con relojes distintos.
Alternativas
Si tu problema no es qué modo usar, otra capa puede ayudar: el envío server-side para la pérdida de transporte, la conciliación cuando las plataformas discrepan y una auditoría cuando no sabes qué se envía.
Para el trabajo de consentimiento en sí, el servicio de Consent Mode v2 cubre la integración de la CMP, el bloqueo por región y la propagación al servidor, y la entrada de Consent Mode v2 en la base de conocimiento define las señales y los tipos de consentimiento. Si las solicitudes se pierden después del consentimiento y no antes, eso es transporte, y el tracking server-side es la capa que hay que examinar.
Si las plataformas simplemente discrepan, empieza por por qué los ingresos de GA4 no coinciden con Shopify. Si el bloqueo por consentimiento empuja sesiones legítimas al grupo equivocado, consulta tráfico no asignado y la comprobación de tráfico no asignado en GA4. Si no puedes saber qué se envía en absoluto, eso es una auditoría de tracking.
