Revisión de arquitectura CDP

Cada integración crea sus propios campos o atributos y nadie mantiene un contrato común.

Siguiente comprobación: Elegir un flujo prioritario y documentar fuente, significado, formato, responsable y consumidores de cada dato.

Hay modelos comunes, pero las excepciones y transformaciones se acumulan sin revisión.

Siguiente comprobación: Inventariar las excepciones activas y decidir cuáles se incorporan al contrato, se aíslan o se retiran.

Modelos, fuentes y transformaciones tienen responsables y usos documentados.

Siguiente comprobación: Comprobar que los consumidores validan los cambios antes de publicarlos y que existe una ruta de retirada.

Los contratos se versionan, se validan en ingesta y se revisan con sus consumidores.

Siguiente comprobación: Conservar el control y medir qué contratos generan más incidencias, excepciones o coste operativo.

Los identificadores se declaran según lo que trae cada conector, sin criterio compartido.

Siguiente comprobación: Clasificar los identificadores por origen, autoridad, persistencia y riesgo antes de modificar reglas de unión.

Existen namespaces y reglas, pero algunos orígenes siguen sin evidencia suficiente.

Siguiente comprobación: Localizar los orígenes con mayor fragmentación o uniones dudosas y validar la evidencia que realmente envían.

Cada familia de eventos declara identificadores, autoridad y persistencia esperada.

Siguiente comprobación: Verificar con muestras reales que cada origen cumple el contrato y que los fallos dejan una señal observable.

La fragmentación y las uniones dudosas se monitorizan y tienen responsables de origen.

Siguiente comprobación: Mantener umbrales, responsables y revisiones periódicas cuando cambien fuentes, SDKs o mecanismos de autenticación.

Las fuentes se incorporan al perfil por defecto o para resolver necesidades puntuales.

Siguiente comprobación: Inventariar qué datos escriben en el perfil, quién los consume y qué ocurriría si dejaran de estar disponibles.

Hay criterios informales, pero faltan consumidores, retención o precedencia explícitos.

Siguiente comprobación: Documentar para cada atributo crítico su fuente autorizada, precedencia, retención y activaciones dependientes.

Cada dato compartido tiene un uso, una regla de precedencia y un ciclo de vida.

Siguiente comprobación: Validar que los cambios de fuente, precedencia o retención tienen pruebas y responsables antes de publicarse.

Las escrituras, el volumen y los consumidores se revisan antes de ampliar estado compartido.

Siguiente comprobación: Conservar la revisión previa y añadir criterios de retirada para atributos, fuentes y consumidores que dejan de usarse.

Cada herramienta interpreta el consentimiento por separado y no existe una regla trazable.

Siguiente comprobación: Dibujar un propósito desde la CMP hasta un destino y registrar transformaciones, valores por defecto y puntos de bloqueo.

El consentimiento se captura, pero su propagación o aplicación depende del canal.

Siguiente comprobación: Comparar el mismo estado en web, app, perfil y destinos, y localizar dónde cambia o deja de aplicarse.

Propósitos, estado, marca temporal y fuente llegan a los consumidores definidos.

Siguiente comprobación: Probar revocación, estados desconocidos y llegadas fuera de orden, no solo el camino de aceptación.

Las políticas se prueban en activación y los fallos dejan una señal operativa revisable.

Siguiente comprobación: Mantener pruebas periódicas por propósito y destino, con responsables para investigar cualquier desviación.

Cada journey o canal mantiene su propia copia de las reglas y los atributos.

Siguiente comprobación: Elegir una decisión repetida y separar hechos del cliente, configuración, contexto de petición y resultado observable.

Algunas reglas se comparten, pero el perfil mezcla hechos estables con contexto efímero.

Siguiente comprobación: Localizar atributos efímeros guardados como perfil y decidir si pertenecen a configuración, petición o estado operativo.

Perfil, configuración y contexto de petición tienen límites y responsables distintos.

Siguiente comprobación: Validar que cada decisión registra inputs, versión de reglas y resultado para poder reproducirla y explicarla.

La misma decisión puede reutilizarse entre canales y cada resultado es observable.

Siguiente comprobación: Conservar la separación y revisar que los nuevos canales reutilizan la decisión sin crear otra copia de reglas y estado.

La operación depende de personas concretas y la documentación no refleja producción.

Siguiente comprobación: Elegir una incidencia reciente y comprobar si otra persona puede diagnosticarla con documentación, alertas y accesos actuales.

Hay procedimientos, pero ownership, alertas o condiciones de retirada siguen implícitos.

Siguiente comprobación: Asignar responsables, señales de fallo y condiciones de retirada a los flujos que más cambios o incidencias generan.

Decisiones, responsables, límites y respuesta a fallos forman parte del entregable.

Siguiente comprobación: Probar el traspaso con un cambio real y actualizar la documentación con lo que el equipo no pudo ejecutar sin ayuda.

El equipo interno prueba cambios, revisa deuda y puede evolucionar el sistema sin dependencia externa.

Siguiente comprobación: Mantener revisiones de deuda, simulacros de fallo y rotación de responsables para evitar que reaparezcan dependencias personales.