Revisión de activación multimarca

El perfil tiene un campo de marca principal y el resto de relaciones no se guarda.

Siguiente comprobación: Buscar personas que compran en más de una marca y ver qué marca muestra hoy su perfil.

Hay un campo por marca, pero sin estado ni fecha, y cada equipo lo rellena a su manera.

Siguiente comprobación: Acordar qué significa tener relación con una marca y quién escribe ese dato.

Cada marca tiene su relación en el perfil, con estado, pero se carga a mano o por proyecto.

Siguiente comprobación: Llevar la carga de relaciones al flujo de datos del grupo, con un responsable claro.

Una relación por marca, con estado y fecha, actualizada desde los sistemas de cliente del grupo.

Siguiente comprobación: Comprobar que una marca nueva se da de alta como relación y no como un campo más.

Hay un único consentimiento de email que vale para todas las marcas del grupo.

Siguiente comprobación: Comparar lo que pide el formulario de cada marca con el campo que llega al perfil.

Cada marca recoge su consentimiento, pero el perfil lo resume en un solo valor.

Siguiente comprobación: Separar el consentimiento por marca en el modelo antes de tocar audiencias o journeys.

Guardamos el consentimiento por marca, pero algunos envíos de marketing todavía no lo comprueban.

Siguiente comprobación: Identificar esos envíos de marketing y añadir la comprobación de marca antes de activarlos. Separar los mensajes transaccionales.

El consentimiento por marca se comprueba antes de cada envío de marketing, con escenarios de prueba.

Siguiente comprobación: Mantener los escenarios de prueba, como una persona que acepta una marca y rechaza otra.

Eventos y audiencias no llevan marca. Se deduce del perfil o del nombre del journey.

Siguiente comprobación: Añadir la marca al contrato de los eventos que disparan journeys, empezando por el de pedido.

Algunos eventos llevan marca, pero con valores distintos según la fuente que los envía.

Siguiente comprobación: Fijar una lista cerrada de valores de marca y validarla en la ingesta.

Eventos y audiencias llevan marca, pero no hemos comprobado cómo se usa para elegir el remitente.

Siguiente comprobación: En AJO estándar, probar condiciones sobre la marca del evento o journeys dedicados a una marca con configuración fija.

Cada envío tiene una marca inequívoca, mediante condiciones o un journey dedicado con configuración fija. Lo hemos probado.

Siguiente comprobación: Probar una compra en cada marca y comprobar el remitente y el consentimiento de marketing por separado.

Todas las marcas envían con un remitente y un dominio genéricos del grupo, sin haber evaluado si el cliente los reconoce.

Siguiente comprobación: Listar los remitentes y dominios necesarios. Confirmar límites y configuración de la edición usada; AJO estándar y B2B no comparten la misma entrega.

El remitente cambia por marca con personalización, pero el dominio de envío es común.

Siguiente comprobación: Evaluar si conviene separar subdominios por marca. Elegir el método de configuración con el equipo DNS según la edición y sus responsabilidades.

Cada marca tiene su subdominio configurado y elegimos el remitente manualmente al preparar cada envío.

Siguiente comprobación: Añadir una comprobación del remitente antes de publicar. En AJO estándar, una configuración compartida exige condiciones de perfil inequívocas.

Cada marca envía con el remitente y dominio previstos, con pruebas para personas vinculadas a varias marcas.

Siguiente comprobación: Repetir las pruebas al cambiar configuraciones, personalización o tokens. Usar las capacidades de la edición contratada.

Cada marca crea su propio perfil de la misma persona, con identificadores separados.

Siguiente comprobación: Buscar personas con perfil en más de una marca y sumar los mensajes que pueden recibir.

Los perfiles son por marca, pero comparten el email como identidad y la fusión depende del grafo.

Siguiente comprobación: Revisar las linking rules y la merge policy. Private graph usa los enlaces existentes; un email compartido puede unir identificadores de marcas distintas.

Hay un perfil por persona, pero las reglas de identidad no se han probado con casos multimarca.

Siguiente comprobación: Probar las reglas de identidad en Graph Simulation con personas de varias marcas antes de activarlas.

Un perfil por persona, con la marca como relación y reglas de identidad probadas antes de activarse.

Siguiente comprobación: Repetir la simulación del grafo antes de cambiar identidades o dar de alta una marca.

Se quiere contratar B2B para modelar las marcas de consumo como si fueran cuentas.

Siguiente comprobación: Revisar el modelo de relación por marca antes de licenciar nada.

Esperamos activar clases B2B mediante Profile, pero no tenemos Real-Time CDP B2B Edition ni B2P Edition.

Siguiente comprobación: Confirmar la edición. Sin ella, las clases B2B no participan en Real-Time Customer Profile.

El diseño espera que los data sources de AJO estándar lean relaciones entre esquemas de persona y cuenta.

Siguiente comprobación: Revisar el diseño. Los data sources de AJO estándar no admiten relaciones entre schemas.

Usamos AJO B2B para marketing a cuentas, con las licencias y dependencias de entrega verificadas.

Siguiente comprobación: Comprobar la instancia dedicada de Marketo Engage y que la evaluación batch de audiencias de cuenta encaja con los plazos del caso de uso.

No necesitamos marketing a cuentas. Gestionamos las marcas mediante relaciones en el perfil de la persona.

Siguiente comprobación: Mantener este modelo mientras cubra las necesidades. Revaluar B2B si aparecen procesos reales de marketing a cuentas.