Si tus tags, píxeles, chats o apps mandan datos antes del consentimiento, ya tenés un problema. En e-commerce, el riesgo no suele estar en el banner: está en lo que se activa por detrás, en qué sistemas reciben datos, y en si una baja se replica en todos los canales.
Yo lo resumiría así:
Hay un dato que pega directo: estudios citados en el artículo muestran un promedio de 33 cookies cargadas antes de que el usuario pueda elegir, y 18 de terceros. Y otro número suma presión: en 2024 se reportó una mediana de 69 riesgos por sitio en páginas con fallas de cumplimiento.
Bajo la Ley 25.326 en Argentina, esto no va solo de “informar”. Yo tengo que poder explicar qué datos salen, a quiénes van, para qué, y cómo se frena ese uso si la persona revoca el permiso.
Mi regla simple es esta: inventario, bloqueo previo, registro central y propagación de bajas. Si una de esas cuatro partes falla, el control queda incompleto.
| Punto | Qué reviso |
|---|---|
| Datos que salen | Nombre, email, historial de compra, IP, cookies, chats, dirección |
| Terceros que los reciben | GA4, Meta, Google Ads, CRM, pasarelas, envíos, afiliados, mensajería |
| Base para usar esos datos | Soporte y compra por un lado; marketing por otro |
| Prueba de cumplimiento | Timestamp, categorías aceptadas, versión de política y revocaciones |
| Riesgo más común | Tags y automatizaciones que corren antes o después de una baja |
Si quiero compartir datos con terceros sin desorden, no me alcanza con una CMP sola. Necesito que sitio, tags, CRM y mensajería lean el mismo estado de consentimiento.
Gestión de Consentimiento en E-commerce: 4 Pasos Clave
El riesgo aparece cuando estas integraciones se activan sin tener claro qué datos salen, a dónde van y con qué base legal. Y ahí es donde el problema deja de ser abstracto. Se vuelve visible en tres áreas muy concretas: la medición, el soporte y los programas de terceros.
Cuando una persona entra a una tienda, los scripts de analítica y publicidad suelen ejecutarse casi al instante. Antes incluso de que vea un banner o elija qué aceptar, herramientas como Google Analytics 4 o el píxel de Meta ya pueden registrar la página visitada, el dispositivo usado, la IP, la URL de referencia y, si esa persona está identificada, un email codificado con hash o un ID de cliente.
Los estudios de privacidad a gran escala muestran algo incómodo: en promedio, se cargan 33 cookies antes de que el usuario pueda dar su consentimiento, y 18 de ellas son de terceros.
El punto crítico es técnico, no solo legal. Si una etiqueta se dispara sin una condición de consentimiento, el banner llega tarde. El dato ya salió.
| Categoría de herramienta | Datos típicos que se comparten | Propósito principal | Consentimiento |
|---|---|---|---|
| Analítica web (ej. GA4) | Páginas vistas, IP, dispositivo, URL de referencia, eventos | Análisis de tráfico y conversiones | Sí (no esencial) |
| Píxeles de conversión (ej. Meta, Google Ads) | Compras, valor del pedido en ARS, IDs de producto, email codificado con hash | Medir rendimiento publicitario y retargeting | Sí (marketing) |
| Tags funcionales (carrito, autenticación) | ID de sesión, contenido del carrito | Operar el sitio correctamente | No (estrictamente necesario) |
| Herramientas de A/B testing | Variantes de comportamiento, métricas de rendimiento | Optimizar UX y conversión | Sí (no esencial) |
Y esto no queda solo en “medir”. Muchas veces, el mismo dato que entra por una etiqueta después termina usándose para atender, segmentar o vender.
Los widgets de chat y las integraciones de mensajería mezclan dos usos que no son lo mismo. Si un cliente escribe por WhatsApp para consultar el estado de un pedido, ese intercambio puede tener un fin operativo. Pero si después esa misma información se usa con fines promocionales, hace falta un consentimiento aparte.
Burbuxa sincroniza pedidos, clientes y conversaciones para operar soporte y ventas en WhatsApp e Instagram. Por eso, hay que separar con claridad qué datos quedan dentro del circuito de soporte y cuáles pueden pasar a campañas o flujos de recuperación de carrito.
Dicho simple: una cosa es ayudar a una persona con su compra; otra, muy distinta, es usar ese contacto para empujar una venta.
El ecosistema de afiliados funciona con cookies de rastreo y parámetros de URL que registran qué publisher o contacto trajo la visita. Si esa visita termina en compra, el sistema envía el ID del pedido, el valor total en pesos y otros atributos a la plataforma de afiliados para calcular comisiones. Esas cookies no son estrictamente necesarias para que la tienda funcione.
Lo mismo pasa con herramientas de encuestas post-compra, plataformas de reseñas y programas de fidelización. Todas toman datos de pedidos y de contacto desde la tienda para operar. El problema aparece cuando no existe un mapa claro de ese recorrido: si una persona retira su consentimiento, ese cambio puede no llegar a todos los sistemas.
Cuando cada app guarda su propio consentimiento, el control manual ya no alcanza.
Con esos flujos ya definidos, el problema aparece cuando el consentimiento se gestiona a mano.
El punto no es solo mostrar un banner. El punto es conectar esa elección con lo que de verdad se activa en el sitio.
Si los píxeles y tags no esperan el activador de consentimiento, el dato sale antes de la decisión del usuario. Y ahí ya hay un problema.
Detectarlo no suele ser complicado. Una prueba en incógnito alcanza: si ves actividad de analítica o marketing antes de tocar el banner, hay una falla de cumplimiento.
Ese mismo desorden técnico también aparece cuando el consentimiento se guarda en un sistema y se aplica en otro. En los papeles parece simple. En la práctica, se corta por algún lado.
CMP, CRM, email, publicidad y mensajería pueden guardar versiones distintas del consentimiento. Las automatizaciones de WhatsApp e Instagram, como Burbuxa, gestionan bajas por palabra clave en su propio canal. Cuando el cliente se da de baja, ese cambio no siempre llega a todos los sistemas al mismo tiempo.
Sin una sola fuente de verdad, cada equipo trabaja con un consentimiento distinto.
Y cuando cada herramienta guarda su propia versión, el error deja de ser aislado. Pasa a ser un problema operativo del día a día.
Cada nueva integración o campaña puede volver a abrir brechas si el consentimiento no se propaga solo.
| Dimensión | Manejo manual o informal | Gestión integrada de consentimiento |
|---|---|---|
| Defensabilidad legal | Registros dispersos, difíciles de presentar ante la AAIP | Log centralizado, con marca de tiempo e historial de cambios |
| Propagación de revocación | Puede no aplicarse en todos los canales ni quedar registrada | Se distribuye a todos los procesadores y queda documentada |
| Mantenimiento | Alto: cada cambio exige ajustes manuales en múltiples sistemas | Más bajo: propagación automática con reglas unificadas |
La revocación también queda incompleta si no se propaga sola. Un relevamiento de 2024 mostró una mediana de 69 riesgos por sitio en páginas con problemas de cumplimiento.
Sin integración, el consentimiento queda dividido entre herramientas que no comparten estado.
La salida no pasa por juntar más herramientas. Pasa por conectar el consentimiento con cada activación de datos. Para eso, el CMP, el tag manager y los canales donde circulan los datos tienen que trabajar como un solo sistema.
El CMP tiene que cargar antes que cualquier tag de analítica o marketing. Desde ahí, el tag manager lee el estado de consentimiento por categoría y dispara solo lo que la persona autorizó. Si un píxel no espera consentimiento por su cuenta, igual hay que bloquearlo por categoría hasta que el usuario dé el OK.
La lógica conviene dejarla simple, sin zonas grises. Definí cinco categorías:
Cada tag queda asociado a una sola categoría. Si esa categoría no fue aceptada, el tag no se dispara.
En Shopify, esto se resuelve con la Customer Privacy API. En VTEX o Tiendanube, la idea es la misma: usar flags de privacidad propios o integrarlo con el tag manager.
Pero ojo: bloquear la activación no alcanza. También necesitás poder demostrar qué aceptó cada persona y cuándo.
Cuando el CMP dice una cosa, el CRM otra, y mensajería otra distinta, el problema no tarda en aparecer. Por eso conviene tener un solo registro central. Ahí queda guardado, como mínimo, el identificador del usuario, la fecha y hora, el origen del consentimiento, las categorías aceptadas o rechazadas y el historial de revocaciones.
En ese mismo lugar también tienen que estar la lista al día de proveedores terceros, los contratos de tratamiento de datos (DPAs) firmados con cada uno y la política que vio el usuario en ese momento. Si sumás una herramienta nueva, primero se actualiza la política y después se la pasa a producción. No al revés.
En mensajería hay otro punto fino: una misma conversación puede ser operativa o promocional. Y el consentimiento tiene que distinguir esas dos cosas.
Las notificaciones transaccionales se apoyan en la relación contractual. En cambio, las campañas promocionales, los flujos de recuperación de carrito y las recomendaciones personalizadas solo deberían activarse si whatsapp_marketing o instagram_dm_marketing están en true.
La baja también tiene que seguir una lógica pareja. Si la revocación ocurre en el canal, el cambio tiene que impactar en el perfil central en el acto. Plataformas como Burbuxa rinden mejor cuando los opt-ins y opt-outs están centralizados: cada baja - ya sea por una palabra clave como STOP o basta - actualiza el perfil central y corta todas las automatizaciones al instante.
Cuando estas tres capas quedan alineadas, el control deja de depender de que alguien se acuerde de revisar algo. Pasa a estar metido en el sistema.
| Control | Acción concreta |
|---|---|
| Bloquear tags no esenciales | Habilitarlos solo cuando la categoría correspondiente está en true en el data layer |
| Registro central de consentimiento | Sincronizar CMP, CRM, publicidad y mensajería desde una única fuente de verdad vía API |
| Opt-ins de mensajería | Registrar cada opt-in con timestamp, canal y categoría en el perfil central |
| Opt-outs en WhatsApp/Instagram | Detectar palabras clave de baja y propagar el cambio a todas las automatizaciones vinculadas de forma inmediata |
| Proveedores y política pública | Actualizar lista de proveedores, DPAs y política de privacidad antes de activar cualquier herramienta nueva |
Cuando la CMP, el tag manager, los registros y los canales comparten el mismo estado de consentimiento, el cumplimiento deja de ser un parche y pasa a meterse en la operación de todos los días. Todo arranca con el inventario: sin ese mapa, no hay manera de saber qué datos salen, a dónde van y por medio de qué herramienta. Después viene lo más importante: hacer que esa misma regla corra igual en todos los canales, sin excepciones.
El punto más débil casi siempre aparece fuera del sitio. Ahí es donde también se mueven datos del cliente y donde suelen darse las desalineaciones. Si una baja de marketing entra por un canal, tiene que replicarse de inmediato en el resto. Si esa revocación no viaja a todos lados, el control central pierde sentido.
Cuando el consentimiento está bien conectado con el resto del sistema, pasan cosas bastante concretas: mejora la calidad de los datos, soporte trabaja con menos idas y vueltas, y se achican los errores al momento de decidir. Growth opera con datos trazables, soporte sabe qué información puede usar, y producto mira métricas que reflejan el consentimiento real, no una foto incompleta.
Usá esta rutina para mantener el flujo bajo control y evitar desalineaciones entre sitio, mensajería y proveedores.
| Acción | Frecuencia sugerida |
|---|---|
| Auditar el inventario de herramientas conectadas | Trimestral |
| Verificar qué tags se disparan en home, producto, carrito y checkout | Trimestral y ante cambios de stack |
| Simular combinaciones de consentimiento y confirmar qué scripts corren | Ante cada cambio de stack |
| Verificar la propagación de bajas en todos los canales | Trimestral y ante cambios relevantes |
| Actualizar política y banner antes de activar cualquier herramienta nueva | Antes de cada activación |
| Revisar contratos con proveedores que alojan datos fuera de Argentina | Trimestral |
Este ciclo - inventario, activación, registro, propagación y documentación - convierte el consentimiento en un sistema que funciona por proceso, y no en algo que depende de que alguien se acuerde a último momento.
Un dato compartido requiere consentimiento cuando se usa con un fin distinto del original, como marketing o retargeting, o cuando la norma pide una base legal explícita.
Bajo el GDPR, ese consentimiento debe obtenerse antes de recolectar datos personales para marketing o seguimiento. Además, tiene que ser claro, específico e inequívoco. En Argentina, la Ley 25.326 también exige transparencia y consentimiento previo.
Podés revisarlo desde las herramientas de desarrollo del navegador (Inspeccionar → pestaña Consola) para seguir la carga de scripts. La idea es simple: confirmá que analytics_storage pase de denied a granted solo después de que la persona usuaria haga una acción.
Si ves disparos antes de tiempo, aplicá un retraso de 500 ms en la carga de etiquetas. La otra opción es sumar un script en theme.liquid para que el consentimiento quede en denied por defecto hasta que cargue la herramienta de gestión.
Dicho de otro modo: primero se bloquea, después se habilita. No al revés.
Debe incluir quién dio el permiso, la fecha y hora, el canal o la fuente donde se obtuvo y el propósito específico que quedó autorizado.
Además, tiene que dejar registro del estado actual de las preferencias por canal, los identificadores del usuario, el opt-in para email, SMS o WhatsApp, las marcas de tiempo en formato ISO-8601 y cualquier actualización o revocación. La idea es simple: respetar siempre la última elección del usuario.
