Saltar al contenido principal
Adrià García
Menú

Revisión técnica y privada

Revisión técnica de consentimiento y server-side

Seis decisiones para comprobar si una preferencia se aplica de forma coherente desde la recogida hasta cada destino.

Parte de categorías y decisiones ya definidas por el cliente. Elige la descripción más cercana al estado actual de su implementación técnica.

La revisión se ejecuta por completo en este navegador. No envía, guarda ni comparte tus respuestas.

01 Inventario y finalidades ¿Qué recoge cada tecnología, para qué y hacia qué destinos lo envía?
02 Estado de consentimiento ¿Cómo se representa y comparte la preferencia entre superficies y sistemas?
03 Control en la recogida ¿Qué ocurre antes de que exista una decisión válida y cuando esta cambia?
04 Minimización server-side ¿Qué datos atraviesan la capa server-side y qué se elimina antes del destino?
05 Aplicación en destinos ¿Cómo se demuestra que cada destino aplica la decisión recibida?
06 Operación y evidencia ¿Quién investiga un desvío y con qué evidencia puede reconstruirlo?
Todas las decisiones y qué hacer con cada respuesta

Inventario y finalidades

Por qué importa: No se puede aplicar una decisión técnica coherente cuando tags, finalidades y destinos no comparten un inventario vigente.

  • El inventario depende del escaneo automático o de lo que declara cada equipo.

    Siguiente comprobación: Recorrer una página y un flujo crítico y comparar red, gestor de tags, CMP y documentación.

  • Existe un inventario, pero propietarios, finalidades o destinos quedan desactualizados.

    Siguiente comprobación: Asignar responsable y fecha de revisión a cada tecnología antes de cambiar categorías o bloqueos.

  • Tecnologías, finalidades, datos, responsables y destinos forman un inventario común.

    Siguiente comprobación: Comprobar que altas, cambios y retiradas actualizan el inventario dentro del mismo flujo de publicación.

  • El inventario se contrasta con tráfico real y bloquea publicaciones sin clasificación.

    Siguiente comprobación: Mantener reconciliaciones periódicas y registrar excepciones con responsable y fecha de caducidad.

Leer el patrón relacionado: El traspaso operativo es arquitectura

Estado de consentimiento

Por qué importa: Si cada sistema traduce la preferencia por separado, una misma persona puede recibir tratamientos incompatibles en el mismo recorrido.

  • Cada herramienta interpreta categorías o señales según su propia configuración.

    Siguiente comprobación: Comparar los estados posibles en CMP, navegador, tag manager, CDP y dos destinos relevantes.

  • Hay un modelo común, pero algunas integraciones conservan traducciones o valores propios.

    Siguiente comprobación: Documentar traducciones activas y eliminar las que no tengan propietario ni caso de uso vigente.

  • Estados, versiones y reglas de propagación están documentados para cada consumidor.

    Siguiente comprobación: Probar cambios de preferencia y confirmar qué sistemas reciben el nuevo estado y con qué latencia.

  • La propagación se observa, prueba y reconcilia entre origen y consumidores.

    Siguiente comprobación: Mantener pruebas de transición y alertas sobre estados desconocidos, antiguos o contradictorios.

Leer el patrón relacionado: Las escrituras de Profile son estado compartido

Control en la recogida

Por qué importa: Un banner correcto no evita recogidas anticipadas, colas pendientes ni identificadores creados antes de aplicar la preferencia.

  • El banner carga primero y se confía en que los tags esperen su señal.

    Siguiente comprobación: Capturar una visita nueva con red limpia y verificar qué peticiones e identificadores aparecen antes de decidir.

  • Los tags principales respetan el estado, pero colas, SDKs o excepciones no se prueban igual.

    Siguiente comprobación: Inventariar cargas diferidas, colas y SDKs y probar aceptación, rechazo, retirada y cambio parcial.

  • La recogida tiene valores por defecto, bloqueo y transición definidos por propósito.

    Siguiente comprobación: Automatizar casos críticos y comprobar que una retirada detiene futuras recogidas según el diseño acordado.

  • Los estados se prueban en cada publicación y dejan evidencia revisable.

    Siguiente comprobación: Añadir pruebas negativas y de carrera para detectar cargas que ocurren antes de recibir la decisión.

Leer el patrón relacionado: Separar estado operativo y estado de cliente

Minimización server-side

Por qué importa: Mover el envío al servidor aumenta el control, pero también puede centralizar datos y replicarlos a más destinos de los necesarios.

  • La capa server-side reenvía el payload recibido y cada destino ignora lo que no usa.

    Siguiente comprobación: Comparar el payload de entrada con dos salidas y marcar campos sin finalidad técnica declarada.

  • Hay filtros por destino, pero dependen de configuraciones manuales y poco visibles.

    Siguiente comprobación: Versionar filtros y añadir una prueba que falle cuando aparezcan campos no autorizados en una salida.

  • Cada destino recibe una lista explícita de campos, condiciones y transformaciones.

    Siguiente comprobación: Revisar que nuevos campos no se propaguen por defecto y tengan aprobación dentro del flujo de cambio.

  • La minimización se valida por contrato y se observa en tráfico real.

    Siguiente comprobación: Mantener reconciliación entre contratos, configuración desplegada y muestras de tráfico de producción.

Leer el patrón relacionado: Reutilizar la base de datos entre canales

Aplicación en destinos

Por qué importa: Propagar una señal no demuestra que el destino la interprete, actualice su estado o detenga el tratamiento esperado.

  • Se considera correcto cuando el conector acepta la petición sin error.

    Siguiente comprobación: Elegir un destino y verificar la petición, la respuesta y el estado final visible en la plataforma.

  • Los destinos principales se prueban manualmente, sin una evidencia común ni periodicidad.

    Siguiente comprobación: Definir un caso reproducible por destino con entrada, salida esperada y responsable de revisión.

  • Cada destino tiene casos de aceptación, rechazo, retirada y actualización documentados.

    Siguiente comprobación: Ejecutar los casos tras cambios de CMP, conectores, APIs o modelo de consentimiento.

  • La aplicación se reconcilia y los desvíos generan una incidencia trazable.

    Siguiente comprobación: Revisar cobertura, tiempos de detección y destinos sin una señal final verificable.

Leer el patrón relacionado: Reutilizar la base de datos entre canales

Operación y evidencia

Por qué importa: Una configuración sin responsables, registros y procedimiento de cambio no puede mantenerse cuando evolucionan plataformas y finalidades.

  • Las incidencias dependen de quien configuró la CMP o el conector original.

    Siguiente comprobación: Tomar una incidencia reciente y comprobar si otra persona puede reconstruir estado, versión y destino afectados.

  • Hay documentación y registros, pero no un responsable claro por cada tramo del flujo.

    Siguiente comprobación: Asignar ownership a inventario, CMP, recogida, capa server-side y destinos críticos.

  • Cambios, pruebas, responsables y respuesta a fallos forman parte de la operación.

    Siguiente comprobación: Probar el procedimiento con un cambio real y corregir cualquier paso que dependa de conocimiento implícito.

  • El equipo puede detectar, contener y explicar un desvío sin depender de una persona.

    Siguiente comprobación: Mantener simulacros, revisión de deuda y rotación de responsables para conservar esa capacidad.

Leer el patrón relacionado: El traspaso operativo es arquitectura