Saltar al contenido principal
Adrià García
← Volver a los simuladores

Experience Platform y Journey Optimizer · varias marcas

¿Persona o cuenta?

Grupo Nordal tiene tres marcas, cada una con su dominio de envío, su remitente y su consentimiento. Laura es clienta de Moda y de Casa: acepta el marketing de Moda y rechaza el de Casa. Marc solo es cliente de Sport. Cambia el modelo de datos y mira con qué remitente llega cada envío.

¿Quién está comprando?

Compara el modelo en AEP: una persona que compra para sí, un equipo que compra para su empresa y una clienta de varias marcas.

Ir al simulador de envíos ↓

Laura compra para ella

La pregunta es qué ha hecho Laura y qué necesita. Su perfil y sus eventos permiten construir esa audiencia.

Persona

LauraPerfil individual

Actividad

Compra de LauraEvento con producto y marca

Contexto de la compra

Nordal ModaLa marca que le vende

La unidad de selección es la persona. Tener relaciones con productos o tiendas no convierte este modelo en B2B.

A quién puedes seleccionar
Personas que compraron en Moda y aceptan su marketing. Aquí la candidata es Laura.
Cómo lo activas
Por ejemplo, una audiencia de personas para AJO estándar. Antes del envío se comprueban el consentimiento y la configuración del canal.
Ver el detalle de AEP y las fuentes
  • XDM Individual Profile representa a Laura; XDM ExperienceEvent, su actividad. La marca es contexto del ejemplo, no una cuenta empresarial.
  • B2C también admite segmentación multientidad con relaciones hacia entidades como productos o tiendas. No es un modelo sin relaciones.

Laura e Inés compran para una empresa

La empresa compra. Laura e Inés participan con funciones distintas. El modelo conserva a cada persona y añade la cuenta y sus relaciones.

Personas

LauraPerfil individual
InésOtro perfil individual

Relación con la cuenta

Laura ↔ empresaResponsable de compras
Inés ↔ empresaResponsable técnica

Cuenta compradora

Empresa de ejemploUna cuenta, varias personas
Oportunidad: renovación del servicio Vinculada a esta cuenta. También se puede registrar qué personas participan en la oportunidad.

Compartir una cuenta no fusiona a Laura e Inés. Una relación de negocio no es un enlace de identidad personal.

A quién puedes seleccionar
Por ejemplo, contactos de cuentas con una oportunidad de renovación abierta. La cuenta aporta contexto sin borrar a las personas.
Cómo lo activas
RT-CDP B2B no obliga a usar AJO B2B. Si eliges sus account journeys, AJO B2B orquesta y una instancia dedicada de Marketo Engage entrega el email.
Ver el detalle de AEP y las fuentes
  • La persona sigue usando XDM Individual Profile. XDM Business Account, Opportunity y las clases de relación añaden el modelo empresarial.
  • Las clases B2B necesitan RT-CDP B2B o B2P para participar en Profile. Dibujar cuentas o crear sus esquemas no habilita esa capacidad.
  • Marketo no es obligatorio como origen de RT-CDP B2B. Los grupos de compra y los account journeys pertenecen a AJO B2B, no al grafo de identidad.

Laura compra para ella en dos marcas

Moda y Casa venden; Laura compra. Pertenecer al mismo grupo no convierte a esas marcas en cuentas compradoras.

Persona

LauraEl mismo perfil individual

Relación por marca

Laura ↔ ModaAcepta marketing de Moda
Laura ↔ CasaRechaza marketing de Casa

Marcas vendedoras

Nordal ModaSu remitente de email
Nordal CasaOtro remitente de email

Mi propuesta aquí: conservar las preferencias por marca en el perfil. No contrataría B2B solo para distinguir remitentes.

A quién puedes seleccionar
Laura puede recibir marketing de Moda, pero no de Casa. Ser clienta de ambas no equivale a aceptar ambas.
Cómo lo activas
En este diseño, AJO estándar selecciona el contexto de marca y comprueba su permiso. La relación guardada no elige el remitente por sí sola.
Ver el detalle de AEP y las fuentes
  • El dibujo representa relaciones de negocio. En esta propuesta son datos por marca dentro del perfil, no clases XDM Business Account.
  • Una relación entre esquemas para segmentar en AEP no se convierte en un lookup de AJO estándar. Sus data sources no admiten esas relaciones.

Son ejemplos ficticios para comparar modelos, no tres configuraciones del envío. Debajo puedes probar qué falla al escribir a Laura en el grupo Nordal. Ir al simulador de envíos ↓

Escenario

Modelo de datos

Los tres primeros modelos usan AJO estándar. El último cambia a AJO B2B: cada marca se representa como una cuenta.

El email es identidad

Solo se enlazan las identidades marcadas como identidad.

Merge policy (ID stitching)

Aquí suponemos que ninguna linking rule impide enlazar los identificadores de marca por el email compartido. Private graph usa esos enlaces; None no.

Cómo se elige el remitente

En AJO estándar comparamos configuraciones por marca con cabeceras del perfil. El ejemplo B2B usa tokens de cuenta; otras arquitecturas quedan fuera.

Consentimiento de email
El evento del pedido lleva la marca

En AJO estándar, una condición lee campos del evento que dispara el journey. El pedido queda fuera del escenario B2B simulado.

Escenario ilustrativo ↑ Volver a los controles
Supuestos del ejemplo

Grupo, marcas, dominios y cifras ficticios. El tope diario ilustra marketing, no calcula entregas reales ni evalúa el pedido transaccional. No se simulan arquitecturas híbridas ni B2B Prime.

Journey Optimizer · envíos

Con qué remitente llega cada envío

Arriba, los perfiles de cada persona. Debajo, una fila por envío: si sale, con qué remitente, si respeta el consentimiento y cuánto capping recibe.

Licencias y veredictos

Qué hace falta y qué falla

Las licencias que pide el modelo elegido y lo que conviene cambiar.

La recomendación

Una persona con una relación por marca, no una persona por marca

Para este escenario recomiendo AJO estándar con relaciones por marca en el perfil. El remitente depende del envío y el permiso, de lo que la persona aceptó para esa marca.

  1. 01

    La relación con cada marca, en el perfil

    Una colección de relaciones identificadas por marca, cada una con su consentimiento. Laura puede aceptar Moda y rechazar Casa. La activación comprueba la preferencia correspondiente.

  2. 02

    El evento lleva la marca

    El evento transaccional incluye la marca y el journey la lee en una condición. Sin ella, la condición no sabe de qué marca es el pedido.

  3. 03

    Configuraciones de canal por marca

    Recomiendo separar las configuraciones por marca y tipo de mensaje. AJO estándar también permite compartir configuraciones con personalización. Eso exige resolver el remitente sin ambigüedad cuando una persona pertenece a varias marcas.

  4. 04

    Un perfil por persona

    No dupliques a la persona ni marques como identidad un email que pueda unir lo que no toca. Si lo marcas, con linking rules y probadas antes en Graph Simulation.

Nota de arquitectura · 11 La marca es una relación, no un atributo de la persona Una marca principal no describe todas las relaciones de la persona. Cada envío debe identificar su marca y comprobar el permiso correspondiente. Leer la nota →

Para revisar esta decisión