Saltar al contenido principal
← BlogRead this article in English →
AEMEdge Delivery ServicesAdobe TargetAEPWeb SDK

Cómo integrar Adobe Target con Edge Delivery Services usando Web SDK

Desglose técnico paso a paso de cómo EDS, AEP Edge Network y Adobe Target trabajan juntos para ofrecer personalización en tiempo real — sin tocar el DOM.

9 min de lectura

Adobe Edge Delivery Services (EDS) proporciona un stack web rápido y basado en documentos. Adobe Target ofrece capacidades de A/B testing y personalización. Integrar estos dos sistemas requiere entender algunas consideraciones arquitectónicas específicas. Esta guía cubre la integración completa, desde la configuración del schema en AEP hasta el renderizado de contenido personalizado en bloques de EDS, explicando el porqué de cada decisión técnica.

Los actores del sistema

Cuatro componentes forman la arquitectura de la integración:

Navegador (EDS)  ←→  AEP Edge Network  ←→  Adobe Target
                          ↑
                      Datastream

El navegador ejecuta Alloy (Adobe Web SDK) dentro de tu proyecto EDS. Alloy se comunica con la AEP Edge Network a través de un Datastream, que enruta los eventos hacia los servicios habilitados — incluido Adobe Target.

1. El XDM Schema — tu contrato de datos

Configura un XDM Schema en AEP como definición formal de la estructura de datos. Funciona como un contrato: los campos declarados pueden transmitirse; los no declarados se rechazan.

Elección de la clase: usa la clase Experience Event, ya que Alloy transmite eventos (sucesos con marca temporal: vistas de página, clics, interacciones) y no datos estáticos de perfil.

El schema define solo la estructura — no procesa datos por sí mismo. Los datos en runtime fluyen a través de Alloy.

Un schema mínimo incluye los campos XDM estándar (eventType, web.URL, web.name, timestamp) más los campos personalizados que necesite tu implementación — como userCountry para personalización geográfica.

2. El Datastream — el enrutador central

El Datastream es el objeto de configuración más crítico de esta arquitectura. Es el punto de entrada a AEP y determina qué servicios de Adobe reciben los datos de los eventos.

Datastream: "nombre-de-tu-datastream"
├── Recibe eventos de Alloy (Web SDK)
├── Valida contra tu XDM Schema
└── Reenvía a los servicios configurados:
    └── Adobe Target ✅ Habilitado

Cuando Alloy transmite un evento que incluye un datastreamId, la Edge Network localiza ese datastream, confirma que Target está habilitado y reenvía el evento a Target para la evaluación de actividades.

Esta capa de enrutado aporta modularidad: puedes añadir más adelante AEP Profile, Analytics o Audience Manager al mismo datastream sin modificar nada del código frontend.

3. La actividad de Target — las reglas de personalización

Crea una actividad de Experience Targeting (XT) en Adobe Target usando el Form-based Experience Composer. A diferencia del Visual Experience Composer (VEC), el composer basado en formulario trabaja con ubicaciones con nombre llamadas mboxes en lugar de selectores CSS.

Por qué importa: EDS construye el DOM de forma programática, lo que hace poco fiable la manipulación del DOM al estilo VEC. La composición basada en formulario devolviendo ofertas JSON es el patrón correcto.

Actividad: "Hero Background Personalization"
Location: hero-background
├── Regla 1: España (ES)
│   └── Devuelve la Experiencia B:
│       { "hero": { "backgroundImage": "/images/hero-bg-es.jpg" } }
└── Regla 2: Todos los visitantes (fallback)
    └── Devuelve la Experiencia A:
        { "hero": { "backgroundImage": "/images/hero-bg-default.jpg" } }

Target evalúa las reglas secuencialmente y devuelve la primera coincidencia. El valor de location (hero-background) es lo que conecta la actividad con tu JavaScript. Target devuelve JSON puro — sin HTML, sin CSS. Tu bloque de EDS decide cómo aplicarlo.

4. Alloy (Web SDK) — el mensajero

Alloy es la librería JavaScript de Adobe que hace de puente entre el navegador y la Edge Network. Inicialízala en el alloy-init.js de tu proyecto EDS:

await window.alloy('configure', {
  datastreamId: 'your-datastreamId',
  orgId: 'your-orgId@AdobeOrg',
  edgeDomain: 'edge.adobedc.net',
});

Tras la configuración, Alloy puede transmitir eventos mediante sendEvent. El paso de configuración especifica qué datastream usar. Como EDS carga los scripts de forma asíncrona, necesitarás un flag de disponibilidad (window.alloy_configured = true) al que los bloques puedan esperar antes de disparar eventos.

5. El flujo completo de la petición

Esta es la secuencia exacta cuando un usuario aterriza en la página:

  1. El usuario abre /landing-page en su navegador.
  2. scripts.js ejecuta initAlloy() — carga Alloy desde el CDN, lo configura con el datastreamId y establece window.alloy_configured = true.
  3. EDS decora el bloque Hero. hero.js llama a sendPageViewEvent(['hero-background']) y espera a que Alloy esté listo mediante waitForAlloy().
  4. Alloy envía un POST a edge.adobedc.net/ee/v2/interact con el payload del evento XDM y la petición decisionScopes: ['hero-background'].
  5. La Edge Network identifica el datastream, confirma que Target está habilitado y reenvía la petición a Target con el scope solicitado.
  6. Target evalúa la actividad. La IP del usuario resuelve a España → la Regla 1 coincide → se devuelve la Experiencia B.
  7. La Edge Network devuelve la respuesta a Alloy como un array de propositions.
  8. hero.js parsea el contenido de la proposition, extrae el valor de backgroundImage y renderiza el bloque hero con esa imagen.
  9. notifyDisplay() envía un evento decisioning.propositionDisplay de vuelta a AEP para que Target registre la impresión y alimente los informes de la actividad.

6. Por qué decisionScopes es innegociable

Este es el error más frecuente en integraciones de EDS + Target. Si no solicitas un scope explícitamente, Target solo evalúa el scope global __view__ — que corresponde a las actividades de VEC. Las actividades form-based permanecen invisibles para Target salvo que se soliciten por nombre.

Sin scope — Target no devuelve nada:

window.alloy('sendEvent', {
  renderDecisions: false,
  xdm: { /* ... */ }
})
// → propositions: []

Con scope — Target devuelve tu actividad:

window.alloy('sendEvent', {
  renderDecisions: false,
  decisionScopes: ['hero-background'],
  xdm: { /* ... */ }
})
// → propositions: [{ scope: 'hero-background', items: [...] }]

7. Por qué renderDecisions: false

Target puede aplicar las decisiones de dos maneras:

  • renderDecisions: true — Target modifica el DOM directamente. Está pensado para actividades VEC donde Target inyecta CSS o HTML. Esto se rompe en EDS porque EDS controla el proceso de construcción del DOM.
  • renderDecisions: false — Target devuelve las decisiones como JSON. Tu JavaScript decide qué hacer con ellas. Este es el enfoque correcto para EDS: mantienes el control sobre cómo y cuándo se aplica la personalización.

8. Cerrar el círculo del reporting con notifyDisplay()

La llamada a notifyDisplay() se pasa por alto con frecuencia, pero es esencial para que los informes de actividad de Target tengan sentido.

sendEvent (petición)        → Target sabe que alguien pidió hero-background
notifyDisplay (impresión)   → Target sabe que la experiencia se renderizó de verdad
(futuro) sendEvent de clic  → Target sabe si el usuario convirtió

Conclusión

Este patrón de integración — Datastream → actividad form-based → decisionScopes → propositions JSON → aplicación manual en el DOM — es la base de cualquier trabajo serio de personalización en EDS. Una vez entiendes el flujo, añadir más bloques, más actividades y más reglas de targeting se vuelve sencillo.