Saltar al contenido principal
Adrià García

Guía de arquitectura

¿Qué tiene que salir del warehouse?

Tener los pedidos en el warehouse no decide la arquitectura. Primero hay que saber si necesitas el detalle, una audiencia o mantener una copia actualizada.

Fuentes revisadas:

Tres recorridos del dato

  1. Ingestar

    1. Datos del origen
    2. Dataset en AEP
    3. Uso configurado

    Se copia el dato necesario. Ingerirlo en el data lake no lo incorpora por sí solo a Real-Time Customer Profile.

  2. Federar con FAC

    1. Consulta en el warehouse
    2. Audiencia o atributos
    3. Uso en AEP

    El detalle se consulta en origen. Los resultados necesarios para crear o enriquecer audiencias o perfiles sí pueden incorporarse a AEP.

  3. Sincronizar con Data Mirror

    1. Altas, cambios y bajas
    2. Esquemas relacionales
    3. Datos mantenidos en AEP

    Se trasladan cambios del origen. Hay datos persistidos en AEP; no es una consulta federada ni una promesa de copia cero.

Son opciones para necesidades diferentes, no un ranking. Un mismo diseño puede combinar ingesta y federación con alcances delimitados.

Qué está documentado

La ingesta y Profile se configuran por separado

Los esquemas describen el dato ingerido. Real-Time Customer Profile utiliza datos habilitados para Profile; no toda tabla del data lake forma parte del perfil.

Adobe: XDM and Platform services

FAC reduce el movimiento del detalle

Federated Audience Composition permite crear y enriquecer audiencias consultando bases externas. La ausencia de una copia del detalle no elimina el resultado de la composición ni el trabajo en el warehouse.

Adobe: Federated Audience Composition

Data Mirror necesita un modelo y habilitación compatibles

Sincroniza cambios mediante esquemas relacionales y claves de registro. Está disponible con AJO Orchestrated campaigns; en CJA, como lanzamiento limitado según licencia y habilitación. Hay que confirmar el acceso antes de diseñar sobre él.

Adobe: Data Mirror overview

Mi criterio para revisarlo

  • Definir quién necesita el dato y cuándo. Una campaña programada y una respuesta durante la visita no tienen la misma exigencia de frescura.
  • Revisar coste de consulta, transferencia y persistencia, además de la licencia. Identificar quién opera cada conexión y resuelve sus fallos.
  • Probar correcciones y borrados, no solo altas. Seguir su efecto en audiencias, copias y aplicaciones consumidoras.

Comparación de arquitectura basada en documentación pública. No describe una implantación propia de FAC o Data Mirror ni garantiza latencia, coste o disponibilidad para cualquier contrato.

Explorar con ejemplos

Servicios relacionados