Patrones de producción
Patrones de arquitectura
Notas breves y visuales sobre decisiones de customer data que se vuelven caras cuando un CDP llega a producción.
Mapa de los patrones
Mapa de los once patrones de arquitectura sobre el recorrido del dato de cliente, en cuatro etapas y una banda de cimiento. Primera etapa, identidad, con dos patrones: el 01, perfiles partidos, sobre la identidad como contrato con el origen, y debajo el 08, personas que no cuadran, sobre la persona que se mide frente a la que se activa. Segunda etapa, perfil y estado, con tres: el 02, un objeto para todo, sobre separar el estado operativo del estado de cliente; el 03, escrituras que pisan, sobre las escrituras de Profile como estado compartido; y el 10, todo a Profile, sobre qué va a Profile y qué se queda en el data lake. Tercera etapa, decisión: el patrón 06, elegibilidad duplicada, sobre modelar los inputs de Decisioning por consumo. Cuarta etapa, activación, con dos: el 05, cada canal de cero, sobre reutilizar la base de datos entre canales, y debajo el 11, remitente de otra marca, sobre la marca como relación y no como atributo de la persona. Debajo, una banda de cimiento que atraviesa las cuatro etapas con los tres patrones que no pertenecen a ninguna: el 04, lo temporal se queda, sobre la salida que necesita una arquitectura MVP; el 07, solo tú sabes operarlo, sobre el traspaso operativo como arquitectura; y el 09, un no que no se aplica, sobre el consentimiento como cadena. Cada celda enlaza con su ficha, y la lista completa con los títulos largos está justo debajo del mapa.
11 patrones
Identidad → Operación- Identidad
La identidad es un contrato con el origen
Un grafo resuelve evidencia. No inventa relaciones que los orígenes nunca emiten.
Leer patrón → - Estado de cliente
Separar estado operativo y estado de cliente
La orquestación inmediata y los hechos consultables no necesitan la misma representación.
Leer patrón → - Gobierno del perfil
Las escrituras de Profile son estado compartido
Varios procesos escribiendo convierten el perfil en estado operativo compartido.
Leer patrón → - Delivery
Una arquitectura MVP necesita una salida
Empezar estrecho es válido. Hacer permanente lo temporal por accidente no lo es.
Leer patrón → - Canales
Reutilizar la base de datos entre canales
Añadir canales reutilizando cliente y decisión, no reconstruyéndolos.
Leer patrón → - Decisioning
Modelar los inputs de Decisioning por consumo
Los inputs de una decisión tienen ciclos de vida distintos y no caben todos en el perfil.
Leer patrón → - Operación
El traspaso operativo es arquitectura
Una arquitectura no está terminada hasta que otra persona puede operarla.
Leer patrón → - Identidad
La persona que mides no es la persona que activas
El grafo de identidades decide a quién activar ahora. El stitching de la analítica reconstruye quién fue. Son dos respuestas y se diseñan por separado.
Leer patrón → - Consentimiento
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ñó.
Leer patrón → - Perfil y retención
Profile es para activar; el data lake, para recordar
Qué entra en Profile y cuánto tiempo se queda es una decisión de arquitectura. También decide lo que cuenta en la licencia.
Leer patrón → - Activación multimarca
La marca es una relación, no un atributo de la persona
Una marca principal no describe todas las relaciones de la persona. Cada envío debe identificar su marca y comprobar el permiso correspondiente.
Leer patrón →
Lente de arquitectura
Una forma consistente de leer arquitectura
Cada patrón responde las mismas cinco preguntas antes de recomendar una solución.
- 01Qué se rompe
- 02Dónde vive el estado
- 03Quién es responsable
- 04Qué trade-off aceptamos
- 05Cómo evoluciona