Servicio
Primer caso de uso en producción
Construyo un primer caso de uso completo, desde la fuente acordada hasta una activación o journey que el equipo pueda operar.
Qué incluye
- 01
Diseño de schemas y modelo de identidades para el caso acordado.
- 02
Un flujo de ingesta configurado y validado.
- 03
Una audiencia activada en un destino, o un primer journey si el alcance incluye AJO.
- 04
Criterios de validación y observabilidad operativa.
- 05
Runbook con dependencias, monitorización y recuperación, más una sesión de traspaso para el equipo interno.
Diagrama del stack de Adobe. A la izquierda, cinco vías de entrada: Web SDK con alloy.js, Edge Network en tiempo real, Kafka en streaming, CRM y almacén por lotes, y Federated Audience Composition, que consulta sin copiar el dato. En el centro, Adobe Experience Platform: cuatro aplicaciones, Real-Time CDP para segmentación, Journey Optimizer para journeys y decisioning, Customer Journey Analytics para análisis y Query Service para consulta y reconciliación, apoyadas todas sobre un cimiento común de XDM, grafo de identidad, perfil, Data Prep y consentimiento. A la derecha, los destinos: canales de email, push y SMS, plataformas publicitarias, comercio y Adobe Target, que no está construido sobre la plataforma sino sobre Experience Cloud y recibe las audiencias igual que un destino externo.
Experiencia y criterio relacionados
-
Construido 2025–2026
La arquitectura del CDP, con el porqué de cada decisión escrito
La arquitectura obvia no funciona, y hay que medirlo para saberlo. Un journey que escribe en el perfil no deja nada en el data lake, así que todo estado calculado dentro de un journey necesita una reconciliación nocturna para existir en SQL. De ahí sale el resto: esquemas, identidad y qué se persiste en cada sitio. Con el porqué escrito.
- Arquitectura
- AEP
- Modelo de datos
- Identidad
-
Construido 2025–2026
Resolución de identidades con Data Prep y Query Service
Identidades resueltas en la ingesta con Data Prep y reconciliadas después mediante consultas programadas en Query Service. Los perfiles duplicados bajaron alrededor de un 30% y los emails sin mapear pasaron del 100% a menos del 50%.
- Data Prep
- Query Service
- Identidad
-
Construido 2025–2026
Consentimiento del bus de eventos al perfil y la activación
Pipeline de consentimientos desde Kafka hasta AEP, con una carga separada para el estado histórico que ya existía. Las dos cadencias importan: el consentimiento que llega en streaming y el que entra por detrás en una carga masiva tienen que acabar significando lo mismo.
- Kafka
- AEP
- Consentimiento
- Carga histórica
-
Construido 2025–2026
Personalización en app con estado operativo recuperable
Patrones de personalización en Adobe Journey Optimizer para la app, con la reconciliación necesaria para que el estado operativo fuera auditable, recuperable y transferible. Sin eso, el journey funciona hasta el primer fallo y nadie sabe cómo dejarlo como estaba.
- AJO
- Estado operativo
- Traspaso
-
Construido 2025–2026
El gestor de campañas, dentro de AJO y sin bucles
El gestor anterior devolvía en milisegundos qué incentivo aplicaba a cada cotización. Al desmontarlo quedó claro que era un motor de reglas, no de recomendación, así que Decisioning no era la respuesta para el primer alcance. Lo difícil era calcular N incentivos para N primas sin bucles en el editor de expresiones.
- Journey Optimizer
- Kafka
- Migración
- Decisioning
-
Construido 2024–2025
Arquitectura AEP para varias líneas de negocio
Modelo XDM, identidades, Web SDK y decisioning de ofertas para líneas de negocio distintas sobre una misma instancia. La primera línea nunca es el problema. El problema es que la segunda no obligue a rehacer el modelo de la primera.
- XDM
- Identidades
- Web SDK
- Decisioning
-
Construido 2024–2025
El canal en AJO, con Pega intacto como decisor
Coordiné la migración del canal a Adobe Journey Optimizer sin tocar el sistema de decisión, integrando Pega con AEP y AJO, y consolidando más de 30 campañas de email. Cambiar el canal y el decisor a la vez es la forma más rápida de no poder aislar qué se rompió.
- AJO
- Pega
- Migración
- Banca
-
Construido 2024–2025
Experience Decisioning de Journey Optimizer en banca
Trabajo sobre Experience Decisioning, la capacidad de decisión actual de Adobe Journey Optimizer, no el Decision Management heredado del offer decisioning anterior. La diferencia cambia dónde vive la oferta, cómo se pide y qué puede decidir el canal en el momento.
- Experience Decisioning
- Journey Optimizer
- Banca
-
Construido 2024–2025
Atributos de perfil o de contexto: de dónde sale cada dato
Personalizar un envío tiene dos fuentes, y elegir mal cuesta caro. Lo que el CDP ya sabe del cliente sale del perfil. Lo que solo se sabe en el momento de disparar, y por tanto no se puede anticipar, viaja como atributo de contexto en la propia llamada. Definí cuál de las dos alimenta cada dato.
- Journey Optimizer
- Personalización
- Streaming API
-
Construido 2024–2025
Retargeting con las ofertas vistas guardadas en el navegador
Retargetizar ofertas sin montar un backend. Las últimas que el usuario ha visto se guardan en el navegador, en una cola corta que alimenta el evento de selección de las tarjetas. Vuelven en la siguiente petición de decisioning, para que la respuesta no repita lo mismo.
- Decisioning
- GTM
- Retargeting
-
Construido 2021–2024
Adobe Target como destino del CDP, con las audiencias gobernadas
Target no como isla, sino como destino de activación del CDP con personalización en el edge. Publicar las audiencias desde la analítica tiene cupo y tarda horas en ser accionable, así que la regla se escribió al revés: las audiencias se crean en el CDP y nunca en la herramienta de personalización.
- Adobe Target
- Real-Time CDP
- Gobierno
- Activación
Preguntas frecuentes
Tenemos la licencia y no hemos arrancado. ¿Es normal?
Es lo más común que me encuentro. La licencia trae la plataforma, no el caso de uso: falta acordar la fuente, el modelo de datos, la identidad y quién opera después. Ese es exactamente el trabajo de este encargo.
¿Por qué solo un caso de uso?
Porque uno completo en producción enseña más que cinco a medias, y deja construida la base que reutilizan los siguientes. Abrir cinco frentes a la vez suele terminar con cinco cosas que casi funcionan y ninguna operando.
¿Qué pasa cuando terminas? ¿Nos quedamos colgados?
El traspaso es parte del entregable, no un correo final. Se entrega con la documentación operativa, el estado recuperable y una prueba de que vuestro equipo puede ejecutar el proceso sin mí. Si eso no se cumple, el trabajo no está hecho.
¿Y si elegimos mal el caso de uso?
Para eso está el taller inicial. El caso se elige por valor de negocio y por dependencias que se puedan resolver en el plazo, no por el más vistoso. Un caso que depende de un dato que nadie tiene se descarta antes de empezar.
¿Encaja con tu problema?
Cuéntame el contexto y te diré si este alcance es el adecuado o conviene empezar por otro sitio.