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.
Diagrama genérico. No reproduce una arquitectura de cliente.
Una decisión se alimenta de cosas que se mueven a ritmos distintos. Los hechos estables del cliente viven en el perfil. El dato que cambia por su cuenta, como el stock o el precio, se consulta contra un conjunto de datos en el momento de decidir. El valor de página o de sesión llega en la propia petición.
Separarlos mantiene el perfil acotado y permite reutilizar la misma decisión entre canales. Conviene comprobar antes qué guarda cada ruta: en edge, el contexto que se envía en la petición se queda en el perfil.
Señales en producción
- Profile contiene datos de página o sesión.
- La misma elegibilidad está copiada en varios journeys.
- Cambiar un ranking requiere editar cada canal.
Arquitectura recomendada
Clasificar cada input por lo que dura y por quién lo consume, antes de modelarlo.
Centralizar la decisión, no todos los datos ni todo el journey.
Comprobar que la consulta a conjunto de datos está disponible antes de diseñar apoyándose en ella.
Cuándo no aplicarlo
- No migrar un journey que funciona si no hay beneficio en tiempo de petición o entre canales.
- No dar por hecho que el contexto de la petición es efímero, porque en edge se queda en el perfil.