Experience Data Model (XDM) es el marco de trabajo principal que estandariza los datos de experiencia del cliente al proporcionar estructuras y definiciones comunes para su uso en servicios de Adobe Experience Platform descendentes. Al adherirse a los estándares XDM, todos los datos de experiencia del cliente se pueden incorporar en una representación común que le permite obtener información valiosa de las acciones del cliente, definir audiencias del cliente 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 prácticas recomendadas para el modelado de datos al diseñar los 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 Información general del sistema XDM para obtener una introducción general a XDM y su función dentro de Experience Platform.
Además, esta guía se centra exclusivamente en consideraciones clave relacionadas con el diseño del esquema. Por lo tanto, se recomienda encarecidamente que consulte la conceptos básicos de composición de esquemas para obtener explicaciones detalladas de los elementos de esquema individuales mencionados en esta guía.
El método recomendado para diseñar el modelo de datos para utilizarlo en Experience Platform se puede resumir de la siguiente manera:
Los pasos relacionados con la identificación de las fuentes de datos aplicables necesarias para llevar a cabo los casos de uso empresariales variarán de una organización a otra. Mientras que el resto de las secciones de este documento se centran en los últimos pasos de la organización y construcción de una ERD después de que se hayan identificado las fuentes de datos, las explicaciones de los distintos componentes del diagrama pueden informar sus decisiones sobre a cuál de sus fuentes de datos debe migrarse Platform.
Una vez que haya determinado las fuentes de datos que desea incorporar a Platform, cree un ERD de alto nivel para guiar el proceso de asignación de los datos a esquemas XDM.
El ejemplo siguiente representa un ERD simplificado para una empresa que desea introducir datos en Platform. El diagrama destaca las entidades esenciales que deben ordenarse en clases XDM, incluidas las cuentas de clientes, hoteles, direcciones y varios eventos de comercio electrónico comunes.
Una vez creado un ERD para identificar las entidades esenciales que desea introducir en PlatformSin embargo, estas entidades deben ordenarse en las categorías de perfil, búsqueda y evento:
Categoría | Descripción |
---|---|
Entidades de perfil | Las entidades de perfil representan atributos relacionados con una persona individual, normalmente un cliente. Las entidades incluidas en esta categoría deben estar representadas por esquemas basados en la variable XDM Individual Profileclase. |
Entidades de búsqueda | Las entidades de búsqueda representan conceptos que pueden relacionarse con una persona individual, pero no se pueden utilizar directamente para identificarla. Las entidades incluidas en esta categoría deben representarse mediante esquemas basados en clases personalizadas y están vinculados a perfiles y eventos mediante relaciones de esquema. |
Entidades de evento | Las entidades de evento representan conceptos relacionados con las acciones que un cliente puede realizar, los eventos del sistema o cualquier otro concepto en el que desee realizar un seguimiento de los cambios a lo largo del tiempo. Las entidades incluidas en esta categoría deben estar representadas por esquemas basados en la variable XDM ExperienceEventclase. |
Las secciones siguientes proporcionan más instrucciones para ordenar las entidades en las categorías anteriores.
Una forma principal de ordenar entre categorías de entidades es si los datos capturados son mutables o no.
Los atributos pertenecientes a perfiles o entidades de búsqueda suelen ser mutables. Por ejemplo, las preferencias de un cliente pueden cambiar con el tiempo y los parámetros de un plan de suscripción se pueden actualizar según las tendencias del mercado.
Por el contrario, los datos de evento suelen ser inmutables. Dado que los eventos se adjuntan a una marca de tiempo específica, la "captura del sistema" que proporciona un evento no cambia. Por ejemplo, un evento puede capturar las preferencias de un cliente cuando cierra la compra de un carro de compras y no cambia aunque las preferencias del cliente terminen cambiando más adelante. Los datos de evento no se pueden cambiar una vez registrados.
En resumen, los perfiles y las entidades de búsqueda contienen atributos mutables y representan la información más actual sobre los temas que capturan, mientras que los eventos son registros inmutables del sistema en un momento específico.
Si una entidad contiene atributos relacionados con un cliente individual, lo más probable es que sea una entidad de perfil. Algunos ejemplos de atributos del cliente son:
Si desea analizar cómo cambian ciertos atributos dentro de una entidad con el paso del tiempo, lo más probable es que sea una entidad de evento. Por ejemplo, agregar elementos de producto a un carro de compras se puede rastrear como eventos de complemento al carro de compras en Platform:
Customer ID | Tipo | ID del producto | Cantidad | Marca de tiempo |
---|---|---|---|---|
1234567 | Add | 275098 | 2 | 1 de octubre, 10:32 |
1234567 | Eliminar | 275098 | 1 | 1 de octubre, 10:33 |
1234567 | Add | 486502 | 1 | 1 de octubre, 10:41 |
1234567 | Add | 910482 | 5 | 3 de octubre, 14:15 |
Al categorizar las entidades, es importante tener en cuenta las audiencias que puede interesarle crear para abordar los casos de uso empresariales específicos.
Por ejemplo, una empresa quiere conocer todos los miembros "Gold" o "Platinum" de su programa de fidelidad que han realizado más de cinco compras en el último año. En función de esta lógica de segmentación, se pueden extraer las siguientes conclusiones sobre cómo deben representarse las entidades relevantes:
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 esas audiencias a fin de identificar atributos relevantes adicionales.
Por ejemplo, una empresa ha creado una audiencia basada en la regla de que country = US
. A continuación, al activar esa audiencia en ciertos objetivos descendentes, la empresa desea filtrar todos los perfiles exportados en función del estado de inicio. Por lo tanto, una state
El atributo también debe capturarse en la entidad de perfil aplicable.
En función del caso de uso y la granularidad de los datos, debe decidir si es necesario acumular previamente ciertos valores antes de incluirlos en un perfil o entidad de evento.
Por ejemplo: una empresa desea crear una audiencia basada en el número de compras al carro de compras. Puede incorporar estos datos con la granularidad más baja incluyendo cada evento de compra con marca de tiempo como su propia entidad. Sin embargo, a veces esto puede aumentar exponencialmente el número de eventos registrados. Para reducir el número de eventos introducidos, puede elegir crear un valor acumulado numberOfPurchases
durante un periodo de una semana o un mes. Otras funciones agregadas como MIN y MAX también se pueden aplicar a estas situaciones.
Experience Platform no realiza actualmente la agregación automática de valores, aunque esto 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 categorizar sus entidades. Si existe una relación "uno a varios" entre dos entidades, la entidad que representa a "varios" probablemente sea una entidad de 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 los pros y los contras de cada situación al categorizar las entidades en función de la cardinalidad. Consulte la sección siguiente para obtener más información.
En la tabla siguiente se describen algunas relaciones de entidad comunes y las categorías que pueden derivarse de ellas:
Relación | Cardinalidad | Categorías de entidad |
---|---|---|
Clientes y cierres de compra del carro | Uno a varios | Un solo cliente puede tener muchas cierres de compra del carro de compras, que son eventos que se pueden rastrear a lo largo del tiempo. Por lo tanto, los clientes serían una entidad de perfil, mientras que los cierres de compra del carro de compras serían una entidad de evento. |
Clientes y cuentas de fidelización | Uno a uno | Un solo cliente solo puede tener una cuenta de fidelización, y viceversa. Dado que la relación es uno a uno, tanto los clientes como las cuentas de fidelización representan entidades de perfil. |
Clientes y suscripciones | Uno a varios | Un solo cliente puede tener muchas suscripciones. Dado que a la compañía solo le interesan las suscripciones actuales de un cliente, Clientes 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 categorizar las entidades, es importante tener en cuenta que a menudo puede haber ventajas e inconvenientes a la hora de elegir una categoría de entidad antes que otra. El siguiente caso práctico pretende ilustrar cómo podría considerar sus opciones en estas situaciones.
Una compañía realiza un seguimiento de las suscripciones activas de sus clientes, donde un cliente puede tener muchas suscripciones. La empresa también quiere incluir suscripciones para casos de uso de segmentación, como encontrar todos los usuarios con suscripciones activas.
En esta situación, 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 de perfil para clientes. Los objetos de esta matriz contendrían campos para category
, status
, planName
, startDate
, y endDate
.
Pros
Contras
El segundo método sería utilizar esquemas de eventos para representar las suscripciones. Esto implica la ingesta de 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 tiempo de cuándo se produjo el evento de suscripción.
Pros
Contras
Una vez que haya ordenado las entidades en categorías de perfil, búsqueda y evento, puede empezar a convertir el modelo de datos en esquemas XDM. A efectos de demostración, el modelo de datos de ejemplo mostrado anteriormente se ha ordenado en las 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. Para reiterar:
Aunque las entidades de evento casi siempre se representarán mediante esquemas independientes, las entidades del perfil o las categorías de búsqueda pueden combinarse en un único esquema XDM, según su cardinalidad.
Por ejemplo, dado que la entidad Customers tiene una relación uno a uno con la entidad LoyaltyAccounts, el esquema para la entidad Customers también podría incluir una LoyaltyAccount
para contener los campos de fidelidad adecuados para cada cliente. Sin embargo, si la relación es de uno a varios, la entidad que representa a "varios" puede representarse mediante un esquema independiente o una matriz de atributos de perfil, según su complejidad.
Las secciones a continuación proporcionan una guía general sobre la construcción de esquemas basados en su ERD.
El reglas de evolución de esquema dicte que solo se pueden realizar cambios no destructivos en los esquemas una vez que se hayan implementado. En otras palabras, una vez que se agrega un campo a un esquema y se han introducido datos en ese campo, el campo ya no se puede eliminar. Por lo tanto, es esencial adoptar un enfoque de modelado iterativo cuando cree sus esquemas por primera vez, empezando con una implementación simplificada que aumente progresivamente la complejidad con el tiempo.
Si no está seguro de si es necesario incluir un campo en particular en un esquema, la práctica recomendada es dejarlo fuera. Si posteriormente se determina que el campo es necesario, siempre se puede añadir 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 procedentes de varias fuentes de datos. Aunque un esquema puede tener varios campos marcados como identidades, se debe definir una sola identidad principal para que el esquema se habilite 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 los esquemas, cualquier clave principal de las tablas de bases de datos relacionales será probablemente candidata para identidades principales. Otros ejemplos de campos de identidad aplicables son las direcciones de correo electrónico de los clientes, los números de teléfono, los ID de cuenta y ECID.
Experience Platform proporciona varios grupos de campos de esquema XDM predeterminados para capturar datos relacionados con las siguientes aplicaciones de Adobe:
Por ejemplo, la variable Plantilla de Adobe Analytics ExperienceEvent grupo de campos le permite asignar AnalyticsCampos específicos de para los esquemas XDM. Según las aplicaciones de Adobe con las que trabaje, debe utilizar estos grupos de campos proporcionados por el Adobe en los esquemas.
Los grupos de campos de aplicación de Adobe asignan automáticamente una identidad principal predeterminada mediante el uso del identityMap
field, que es un objeto de solo lectura generado por el sistema 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 se establece de forma predeterminada en AAID.
Al utilizar grupos de campos de aplicación de Adobe, no se deben marcar otros campos como la identidad principal. Si hay propiedades adicionales que deben marcarse como identidades, estos campos deben asignarse como identidades secundarias.
Este documento abarcaba las directrices generales y las prácticas recomendadas para diseñar el modelo de datos para Experience Platform. Para resumir:
Una vez que esté listo, consulte el tutorial sobre creación de un esquema en la IU para obtener instrucciones paso a paso sobre cómo crear un esquema, asigne la clase adecuada para la entidad y agregue campos para asignar los datos a.