Saltar al contenido principal
Adrià García
← Todos los servicios

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

  1. 01

    Diseño de schemas y modelo de identidades para el caso acordado.

  2. 02

    Un flujo de ingesta configurado y validado.

  3. 03

    Una audiencia activada en un destino, o un primer journey si el alcance incluye AJO.

  4. 04

    Criterios de validación y observabilidad operativa.

  5. 05

    Runbook con dependencias, monitorización y recuperación, más una sesión de traspaso para el equipo interno.

La identidad y el consentimiento son cimiento, no una capa que se añade al final. Target queda fuera: es Experience Cloud, anterior a la plataforma, y recibe audiencias como cualquier otro destino.

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.

Recorrer la arquitectura de Adobe, paso a paso →

Experiencia y criterio relacionados

  1. 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
  2. Construido 2025–2026

    Resolución de identidades con Data Prep y Query Service

    Los eventos y cargas de sistemas legacy generaban perfiles duplicados. Las identidades se resolvieron en la ingesta con Data Prep y se reconciliaron después mediante consultas programadas en Query Service. Los duplicados bajaron alrededor de un 30% y los emails sin mapear se redujeron a menos de la mitad.

    • Data Prep
    • Query Service
    • Identidad
  3. 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
  4. 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

Ver más trabajo en mi trayectoria →

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.

Hablar del alcance