El contenedor server-side enviaba email, nombre, país y código postal a Meta CAPI, TikTok Events API y Google Ads incluso con el consentimiento de publicidad denegado.
Auditoría de Consent Mode v2 sobre 154 tags: 128 con gates ausentes o mal configurados, más una race condition en el CMP que marcaba consentimiento concedido antes de la interacción del usuario.
Gates de ad_storage y ad_user_data implementados en los 15 tags server-side afectados, bloqueando publicación hasta cerrar el gap.
Eliminación total del envío de PII fuera de consentimiento antes de producción. Corrección de riesgo legal real bajo RGPD, no un ajuste de tracking.
Contexto
El contenedor llevaba meses en producción reportando con normalidad — campañas activas, conversiones registrándose, nada que levantara sospecha desde fuera. La auditoría no partió de un incidente, sino de una revisión preventiva de cumplimiento antes de una campaña con mayor inversión en publicidad, precisamente el tipo de revisión que la mayoría de cuentas nunca llega a hacer hasta que ya es tarde.
Cómo se resolvió, en detalle
Por qué 128 de 154 tags fallaban y no se notaba
El fallo no estaba concentrado en un punto único fácil de encontrar — estaba repartido: tags configurados en distintos momentos por distintas personas, sin un estándar único de cómo aplicar el gate de consentimiento. Cada uno individualmente parecía razonable. Solo auditando el 100% del contenedor, tag por tag, se veía el patrón real: la ausencia de gate era la norma, no la excepción.
La race condition que lo empeoraba
El CMP, en determinadas condiciones de carga de página (conexión lenta, caché de navegador vacía), marcaba el consentimiento como concedido antes de que el usuario hubiera visto siquiera el banner. En pruebas manuales rápidas, con la página ya cacheada, el orden salía correcto casi siempre — razón por la que nadie lo había detectado en meses de uso normal.
Por qué se corrigió antes de la campaña, no después
Con la campaña de mayor inversión programada, cualquier corrección posterior al lanzamiento habría significado semanas de datos de conversión contaminados con el mismo problema, imposibles de limpiar retroactivamente. Cerrar el gap antes de encender el gasto era la única forma de que los datos de esa campaña fueran defendibles desde el primer día.
Un contenedor que "funciona" a nivel de negocio (las campañas reportan, los dashboards se llenan) no dice nada sobre si respeta el consentimiento del usuario. Son dos preguntas completamente distintas, y solo la auditoría tag a tag responde la segunda.
Preguntas frecuentes
¿Cómo se detecta este tipo de fuga sin acceso completo al contenedor?
De forma parcial: con la pestaña Network del navegador se ve qué se envía a qué dominio y con qué señal de consentimiento, sin necesidad de credenciales. Para corregirlo sí hace falta acceso, pero para sospechar que existe, no.
¿Este tipo de gap se puede prevenir con un checklist fijo?
Reduce el riesgo, pero no lo elimina — el checklist no detecta una race condition en el CMP, que solo aparece bajo condiciones de carga específicas. Por eso la auditoría real necesita revisar comportamiento en Network, no solo configuración estática.