Experience Data Model (XDM) es el marco de trabajo principal que estandariza los datos de experiencia del cliente proporcionando estructuras y definiciones comunes para su uso en los servicios de Adobe Experience Platform descendentes. Al cumplir con los estándares XDM, todos los datos de experiencia del cliente se pueden incorporar a una representación común que le permite obtener valiosas perspectivas de las acciones de los clientes, definir audiencias de clientes a través de segmentos y expresar atributos del cliente con fines de personalización.
Dado que XDM es extremadamente versátil y personalizable por diseño, es importante seguir las optimizaciones para el modelado de datos al diseñar sus esquemas. Este documento cubre las decisiones y consideraciones clave que debe tomar al asignar los datos de experiencia del cliente a XDM.
Antes de leer esta guía, consulte la descripción general del sistema XDM para obtener una introducción de alto nivel sobre XDM y su función en Experience Platform.
Además, esta guía se centra exclusivamente en consideraciones clave relativas al diseño de esquemas. Por lo tanto, se recomienda encarecidamente que consulte los conceptos básicos de la composición de los esquemas para obtener explicaciones detalladas de los distintos elementos del esquema mencionados en esta guía.
El método recomendado para diseñar el modelo de datos para su uso en Experience Platform se puede resumir de la siguiente manera:
Los pasos relacionados con la identificación de las fuentes de datos aplicables que se requieren para llevar a cabo los casos de uso comercial variarán de una organización a otra. Mientras que el resto de las secciones de este documento se centran en los últimos pasos para organizar y construir un ERD después de que se hayan identificado las fuentes de datos, las explicaciones de los diversos componentes del diagrama pueden servir de base para sus decisiones sobre a qué fuentes de datos debe migrarse Platform.
Una vez que haya determinado las fuentes de datos en las que desea incluir Platform, cree un ERD de alto nivel para ayudar a guiar el proceso de asignación de datos a esquemas XDM.
El ejemplo siguiente representa un ERD simplificado para una compañía que desea introducir datos en Platform. El diagrama resalta las entidades esenciales que deben clasificarse en clases XDM, incluyendo cuentas de cliente, hoteles, direcciones y varios eventos comunes de comercio electrónico.
Una vez que haya creado un ERD para identificar las entidades esenciales en las que desea participar Platform, estas entidades deben ordenarse en categorías de perfil, búsqueda y evento:
Categoría | Descripción |
---|---|
Entidades perfil | Las entidades de perfil representan atributos relacionados con una persona individual, normalmente un cliente. Las entidades comprendidas en esta categoría deben estar representadas por esquemas basados en la XDM Individual Profileclase. |
Entidades de búsqueda | Las entidades de búsqueda representan conceptos que pueden relacionarse con una persona individual, pero que no pueden utilizarse directamente para identificarla. Las entidades incluidas en esta categoría deben estar representadas por esquemas basados en clases personalizadas. |
Entidades evento | Las entidades de evento representan conceptos relacionados con acciones que un cliente puede realizar, eventos del sistema o cualquier otro concepto en el que desee rastrear los cambios con el tiempo. Las entidades comprendidas en esta categoría deben estar representadas por esquemas basados en la XDM ExperienceEventclase. |
Las secciones a continuación proporcionan una guía adicional sobre cómo clasificar las entidades en las categorías anteriores.
Si una entidad contiene atributos relacionados con un cliente individual, lo más probable es que sea una entidad perfil. Algunos ejemplos de atributos del cliente son:
Si desea analizar cómo ciertos atributos de una entidad cambian con el tiempo, lo más probable es que se trate de una entidad de evento. Por ejemplo: la adición de elementos de producto a un carro de compras se puede rastrear como eventos de adiciones al carro de compras en Platform:
ID de cliente | Tipo | ID del producto | Cantidad | Marca de tiempo |
---|---|---|---|---|
1234567 | Add | 275098 | 2 | 1 de octubre, 10:32 AM |
1234567 | Eliminar | 275098 | 1 | 1 de octubre, 10:33 AM |
1234567 | Add | 486502 | 1 | 1 de octubre, 10:41 AM |
1234567 | Add | 910482 | 5 | 3 de octubre, 2:15 PM |
Al categorizar las entidades, es importante tener en cuenta los segmentos de audiencia que desee crear para abordar los casos de uso comercial en particular.
Por ejemplo, una compañía quiere conocer a todos los miembros "Gold" o "Platinum" de su programa de lealtad que han realizado más de cinco compras en el último año. Sobre la base de esta lógica de segmentos, pueden extraerse las siguientes conclusiones sobre la forma en que deben representarse las entidades pertinentes:
Además de las consideraciones relativas a los casos de uso de segmentación, también debe revisar los casos de uso de activación para esos segmentos a fin de identificar atributos relevantes adicionales.
Por ejemplo, una compañía ha creado un segmento de audiencia basado en la regla que country = US
. A continuación, cuando se activa ese segmento con determinados destinatarios descendentes, la compañía desea filtrar todos los perfiles exportados en función del estado de origen. Por lo tanto, también se debe capturar un state
atributo en la entidad de perfil aplicable.
Según el caso de uso y la granularidad de los datos, debe decidir si ciertos valores deben agregarse previamente antes de incluirse en una entidad de perfil o evento.
Por ejemplo, una compañía desea generar un segmento en base al número de compras del carro de compras. Puede optar por incorporar estos datos en la granularidad más baja incluyendo cada evento de compra con marca de hora como su propia entidad. Sin embargo, a veces esto puede aumentar el número de eventos registrados de forma exponencial. Para reducir el número de eventos ingestados, puede elegir crear un valor acumulado numberOfPurchases
durante un período de una semana o un mes. Otras funciones acumuladas como MIN y MAX también se pueden aplicar a estas situaciones.
Actualmente, el Experience Platform no realiza la agregación automática de valores, aunque está planificado para futuras versiones. Si decide utilizar valores agregados, debe realizar los cálculos externamente antes de enviar los datos a Platform.
Las cardinalidades establecidas en su ERD también pueden proporcionar algunas pistas sobre cómo clasificar sus entidades. Si hay una relación uno a varios entre dos entidades, la entidad que representa los "muchos" será probablemente una entidad evento. Sin embargo, también hay casos en los que "varios" es un conjunto de entidades de búsqueda que se proporcionan como una matriz dentro de una entidad de perfil.
Dado que no existe un enfoque universal que se ajuste a todos los casos de uso, es importante tener en cuenta las ventajas y desventajas de cada situación al clasificar las entidades en función de la cardinalidad. Consulte la siguiente sección para obtener más información.
La siguiente tabla describe algunas relaciones de entidad comunes y las categorías que se pueden derivar de ellas:
Relación | Cardinalidad | Categorías de entidad |
---|---|---|
Clientes y cierres de compra | Uno a muchos | Un único cliente puede tener muchos cierres de compra, que son eventos que se pueden rastrear con el paso del tiempo. Por lo tanto, los clientes serían una entidad de perfil, mientras que los cierres de compra serían una entidad de evento. |
Clientes y cuentas de lealtad | Uno a uno | Un solo cliente solo puede tener una cuenta de fidelidad y viceversa. Dado que la relación es uno a uno, tanto los clientes como las cuentas de lealtad representan las entidades de perfil. |
Clientes y Suscripciones | Uno a muchos | Un solo cliente puede tener muchas suscripciones. Dado que la compañía solo se ocupa de las suscripciones actuales de un cliente, Customers es una entidad de perfil, mientras que Suscripciones es una entidad de búsqueda. |
Aunque en la sección anterior se proporcionaban algunas directrices generales para decidir cómo clasificar las entidades, es importante comprender que a menudo puede haber ventajas y desventajas para elegir una categoría de entidad en lugar de otra. El siguiente caso práctico tiene por objeto ilustrar cómo puede considerar sus opciones en estas situaciones.
Una compañía rastrea suscripciones activas para sus clientes, donde un cliente puede tener muchas suscripciones. La compañía también desea incluir suscripciones para casos de uso de segmentación, como la búsqueda de todos los usuarios con suscripciones activas.
En este escenario, la compañía tiene dos opciones potenciales para representar las suscripciones de un cliente en su modelo de datos:
El primer método sería incluir una matriz de suscripciones como atributos dentro de la entidad perfil para clientes. Los objetos de esta matriz contendrían campos para category
, status
, planName
, startDate
y endDate
.
Pros
Cons
El segundo enfoque sería utilizar esquemas de evento para representar suscripciones. Esto implica ingerir los mismos campos de suscripción que el primer método, con la adición de un ID de suscripción, un ID de cliente y una marca de hora de cuándo se produjo el evento de suscripción.
Pros
Cons
Una vez que haya clasificado las entidades en categorías de perfil, búsqueda y evento, puede convertir el modelo de datos en esquemas XDM en inicios. A efectos de demostración, el modelo de datos de ejemplo que se muestra anteriormente se ha clasificado en categorías adecuadas en el diagrama siguiente:
La categoría en la que se ha ordenado una entidad debe determinar la clase XDM en la que se basa su esquema. Reiterar:
Aunque las entidades de evento estarán representadas casi siempre por esquemas separados, las entidades de las categorías de perfil o de búsqueda pueden combinarse en un único esquema XDM, según su cardinalidad.
Por ejemplo, como la entidad Customers tiene una relación uno a uno con la entidad LoyaltyAccounts, el esquema de la entidad Customers también puede incluir un LoyaltyAccount
objeto que contenga los campos de lealtad correspondientes para cada cliente. Sin embargo, si la relación es una con muchos, la entidad que representa los "muchos" podría estar representada por un esquema separado o por una matriz de atributos de perfil, según su complejidad.
Las secciones que figuran a continuación proporcionan orientación general sobre la construcción de esquemas basados en su ERD.
Las reglas de la evolución del esquema dictan que sólo se pueden hacer cambios no destructivos en los esquemas una vez que se han implementado. En otras palabras, una vez que se agrega un campo a un esquema y se han ingestado datos en ese campo, ya no se puede quitar el campo. Por lo tanto, es esencial adoptar un enfoque de modelado iterativo cuando se crean los esquemas por primera vez, comenzando con una implementación simplificada que aumenta progresivamente la complejidad con el paso del tiempo.
Si no está seguro de si es necesario incluir un campo concreto en un esquema, lo mejor es excluirlo. Si posteriormente se determina que el campo es necesario, siempre se puede agregar en la siguiente iteración del esquema.
En Experience Platform, los campos XDM marcados como identidades se utilizan para unir información sobre clientes individuales provenientes de múltiples fuentes de datos. Aunque un esquema puede tener varios campos marcados como identidades, se debe definir una sola identidad principal para que el esquema esté habilitado para su uso en Real-time Customer Profile. Consulte la sección sobre campos de identidad en los conceptos básicos de la composición de esquemas para obtener información más detallada sobre el caso de uso de estos campos.
Al diseñar sus esquemas, cualquier clave principal de las tablas de la base de datos relacional probablemente sea un candidato para identidades principales. Otros ejemplos de campos de identidad aplicables son direcciones de correo electrónico de clientes, números de teléfono, ID de cuenta y ECID.
Experience Platform proporciona varias mezclas XDM integradas para capturar datos relacionados con las siguientes aplicaciones de Adobe:
Por ejemplo, la combinación de plantillas Adobe Analytics ExperienceEvent permite asignar campos Analyticsespecíficos a sus esquemas XDM. Dependiendo de las aplicaciones de Adobe con las que trabaje, debe estar utilizando estas mezclas de Adobe en sus esquemas.
Las mezclas de aplicaciones Adobe asignan automáticamente una identidad principal predeterminada mediante el uso del identityMap
campo, que es un objeto generado por el sistema y de sólo lectura que asigna valores de identidad estándar para un cliente individual.
Para Adobe Analytics, ECID es la identidad principal predeterminada. Si un cliente no proporciona un valor ECID, la identidad principal pasará a ser AAID de forma predeterminada.
Al utilizar mezclas de aplicaciones Adobe, no se debe marcar ningún otro campo como identidad principal. Si hay propiedades adicionales que deben marcarse como identidades, estos campos deben asignarse como identidades secundarias en su lugar.
Este documento abarcaba las directrices generales y las optimizaciones para diseñar el modelo de datos para el Experience Platform. Para resumir:
Una vez que esté listo, consulte el tutorial sobre la creación de un esquema en la interfaz de usuario para obtener instrucciones paso a paso sobre cómo crear un esquema, asignar la clase adecuada para la entidad y agregar campos para asignar los datos.