El consentimiento es una cadena, no un campo
Se decide en la CMP, viaja por el SDK, se guarda en el perfil y lo aplica cada destino. Se rompe en el eslabón que nadie diseñó.
Diagrama genérico. No reproduce una arquitectura de cliente.
Un proyecto de consentimiento suele darse por cerrado cuando el banner guarda la decisión. Ahí empieza el recorrido. El SDK necesita saberla antes del primer evento, el perfil la necesita a tiempo para las audiencias y cada destino tiene que respetarla, o bloquear lo que no debe salir.
Cada tramo tiene un dueño y un ritmo distintos. Si uno llega tarde o no llega, la decisión de la persona deja de valer sin que ningún sistema dé un error.
Señales en producción
- Nadie sabe cuánto tarda un cambio de preferencia en llegar a una audiencia.
- El SDK recoge con consentimiento concedido por defecto donde la ley pide preguntar antes.
- Las preferencias que cambian fuera de la web llegan en un fichero nocturno.
- Cada destino filtra con una regla propia que nadie ha revisado.
Arquitectura recomendada
Dibujar el recorrido de cada finalidad de punta a punta, con responsable y latencia por tramo.
Probar escenarios completos: acepta, rechaza, cambia de opinión y no contesta.
Cuándo no aplicarlo
- No resolverlo solo en la CMP: el banner no aplica nada fuera del navegador.
- No copiar la decisión en campos sin dueño, porque acaban diciendo cosas distintas.
Pruébalo en un simulador
Escenarios interactivos donde este patrón se ve fallar y se ve resolverse.
- AEP · AJO
¿Puedo mandar esto?
¿Qué impide que un dato etiquetado salga a un destino o a un canal de AJO?
Abrir el simulador → - AEP · Web SDK · AJO
Dónde vive el consentimiento
¿Qué parte de lo que decidió Laura llega a su perfil, y quién lo aplica al activar?
Abrir el simulador → - Web SDK
El viaje de un evento
¿Qué eventos salen, cuándo se crea el ECID y a qué servicios llegan?
Abrir el simulador →