Saltar al contenido principal
Adrià García

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

Cada patrón está donde aparece el problema. Los tres de la banda no tienen etapa porque las atraviesan todas.

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
  1. 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 →
  2. Gobierno del perfil

    Las escrituras de Profile son estado compartido

    Varios procesos escribiendo convierten el perfil en estado operativo compartido.

    Leer patrón →
  3. Delivery

    Una arquitectura MVP necesita una salida

    Empezar estrecho es válido. Hacer permanente lo temporal por accidente no lo es.

    Leer patrón →
  4. Canales

    Reutilizar la base de datos entre canales

    Añadir canales reutilizando cliente y decisión, no reconstruyéndolos.

    Leer patrón →
  5. 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 →
  6. Operación

    El traspaso operativo es arquitectura

    Una arquitectura no está terminada hasta que otra persona puede operarla.

    Leer patrón →
  7. 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 →
  8. 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 →
  9. 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 →
  10. 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.

  1. 01Qué se rompe
  2. 02Dónde vive el estado
  3. 03Quién es responsable
  4. 04Qué trade-off aceptamos
  5. 05Cómo evoluciona