Prácticas recomendadas para el modelado de datos
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 y utilizar para 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.
Introducción
Antes de leer esta guía, revise la Información general del sistema XDM para obtener una introducción general a XDM y su función dentro de Experience Platform.
Como esta guía se centra exclusivamente en consideraciones clave relacionadas con el diseño de esquemas, se recomienda encarecidamente que lea la conceptos básicos de composición de esquemas para obtener explicaciones detalladas de los elementos de esquema individuales mencionados en esta guía.
Resumen de prácticas recomendadas summary
El método recomendado para diseñar el modelo de datos para utilizarlo en Experience Platform se puede resumir de la siguiente manera:
- Comprenda los casos de uso empresariales de sus datos.
- Identifique las fuentes de datos principales que deben introducirse en Platform para tratar estos casos de uso.
- Identifique cualquier fuente de datos secundaria que también pueda ser de interés. Por ejemplo, si actualmente solo una unidad comercial de su organización está interesada en transferir sus datos a Platform, una unidad comercial similar también podría estar interesada en portar datos similares en el futuro. Tener en cuenta estas fuentes secundarias ayuda a estandarizar el modelo de datos en toda la organización.
- Cree un diagrama de relación de entidades de alto nivel (ERD) para las fuentes de datos que se han identificado.
- Convertir el ERD de alto nivel en un PlatformERD centrado en (incluidos perfiles, eventos de experiencia y entidades de búsqueda).
Los pasos relacionados con la identificación de las fuentes de datos aplicables necesarias para llevar a cabo los casos de uso empresarial varían 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.
Crear un ERD de alto nivel create-an-erd
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.
Ordenar entidades en categorías de perfil, búsqueda y evento sort-entities
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:
Consideraciones para la ordenación de entidades considerations
Las secciones siguientes proporcionan más instrucciones para ordenar las entidades en las categorías anteriores.
Datos mutables e inmutables mutable-and-immutable-data
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.
Atributos del cliente customer-attributes
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:
- Datos personales como nombre, fecha de nacimiento, sexo e ID de cuenta.
- Información de ubicación, como direcciones e información de GPS.
- Información de contacto, como números de teléfono y direcciones de correo electrónico.
Seguimiento de datos con el tiempo track-data
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:
Casos de uso de segmentación segmentation-use-cases
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:
- "Gold" y "Platinum" representan estados de lealtad aplicables a un cliente individual. Dado que la lógica de segmentación solo afecta al estado de lealtad actual de los clientes, estos datos se pueden modelar como parte de un esquema de perfil. Si desea rastrear los cambios en el estado de lealtad a lo largo del tiempo, también puede crear un esquema de evento adicional para los cambios de estado de lealtad.
- Las compras son eventos que se producen en un momento determinado y la lógica de segmentación se refiere a los eventos de compra dentro de un intervalo de tiempo especificado. Por lo tanto, estos datos deben modelarse como un esquema de evento.
Casos de uso de activación activation-use-cases
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 de dichas audiencias para 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.
Valores agregados aggregated-values
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 más de una semana o un mes. Otras funciones agregadas como MIN y MAX también se pueden aplicar a estas situaciones.
Cardinalidad cardinality
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, es probable que la entidad que representa a "varios" 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.
En la tabla siguiente se describen algunas relaciones de entidad comunes y las categorías que pueden derivarse de ellas:
Ventajas e inconvenientes de las diferentes clases de entidad pros-and-cons
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:
Enfoque 1: Uso de atributos de perfil profile-approach
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
- La segmentación es factible para el caso de uso previsto.
- El esquema solo conserva los registros de suscripción más recientes para un cliente.
Contras
- Se debe restaurar toda la matriz cada vez que se produzcan cambios en cualquier campo de la matriz.
- Si hay diferentes fuentes de datos o unidades comerciales que introducen datos en la matriz, es difícil mantener la matriz actualizada sincronizada en todos los canales.
Enfoque 2: Uso de entidades de evento event-approach
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
- Las reglas de segmentación pueden ser más flexibles (como encontrar todos los clientes o aquellos que cambiaron sus suscripciones en los últimos 30 días).
- Cuando cambia el estado de suscripción de un cliente, ya no tiene que actualizar una matriz larga y potencialmente compleja dentro de los atributos de perfil del cliente. Esto resulta especialmente útil si se producen cambios simultáneos en la lista de suscripción del cliente desde varias fuentes.
Contras
- La segmentación se vuelve más compleja para el caso de uso previsto original (identificando el estado de las suscripciones más recientes de los clientes). La audiencia ahora necesita una lógica adicional para marcar el último evento de suscripción para que un cliente compruebe su estado.
- Los eventos tienen un mayor riesgo de caducar automáticamente y de purgarse del almacén de perfiles. Consulte la guía de Caducidad de Experience Event para obtener más información.
Cree esquemas basados en las entidades clasificadas schemas-for-categorized-entities
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:
- Las entidades de perfil deben utilizar la variable XDM Individual Profile clase.
- Las entidades de eventos deben utilizar la variable XDM ExperienceEvent clase.
- Las entidades de búsqueda deben utilizar clases XDM personalizadas definidas por su organización. Las entidades de perfil y evento pueden hacer referencia a estas entidades de búsqueda mediante relaciones de esquema.
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.
Adoptar un enfoque de modelado iterativo iterative-modeling
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.
Campos de identidad identity-fields
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 habilitar el uso del esquema 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 es 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.
grupos de campos de esquema de aplicación de Adobe adobe-application-schema-field-groups
Experience Platform proporciona varios grupos de campos de esquema XDM predeterminados para capturar datos relacionados con las siguientes aplicaciones de Adobe:
- Adobe Analytics
- Adobe Audience Manager
- Adobe Campaign
- Adobe Target
Por ejemplo, puede utilizar la variable Plantilla de Adobe Analytics ExperienceEvent grupo de campos para 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 toma el valor predeterminado AAID.
Campos de validación de datos data-validation-fields
Cuando se introducen datos en el lago de datos, la validación de datos solo se impone en el caso de campos restringidos. Para validar un campo determinado durante una ingesta por lotes, debe marcar el campo como restringido en el esquema XDM. Para evitar que se ingieran datos incorrectos en Platform, se recomienda definir los criterios de validación de nivel de campo al crear los esquemas.
Para definir restricciones en un campo concreto, seleccione el campo en el Editor de esquemas para abrir Propiedades del campo barra lateral. Consulte la documentación sobre propiedades de campo específicas del tipo para obtener descripciones exactas de los campos disponibles.
Sugerencias para mantener la integridad de los datos data-integrity-tips
A continuación se muestra una colección de sugerencias para mantener la integridad de los datos al crear un esquema.
- Considerar identidades principales: Para productos de Adobe como SDK web, SDK móvil, Adobe Analytics y Adobe Journey Optimizer, la variable
identityMapEste campo suele servir como identidad principal. Evite designar campos adicionales como identidades principales para ese esquema. - Evite utilizar
_idcomo identidad: Evite utilizar el_iden los esquemas de Experience Event como una identidad. Está pensado para la exclusividad de los registros, no para su uso como identidad. - Definir restricciones de longitud: Se recomienda establecer longitudes mínimas y máximas en los campos marcados como identidades. Se muestra un déclencheur de advertencia si intenta asignar un área de nombres personalizada a un campo de identidad sin cumplir las restricciones de longitud mínima y máxima. Estas limitaciones ayudan a mantener la coherencia y la calidad de los datos.
- Aplicar patrones para valores coherentes: Si los valores de identidad siguen un patrón específico, debe utilizar la variable Patrón para aplicar esta restricción. Esta configuración puede incluir reglas como solo dígitos, mayúsculas o minúsculas, o combinaciones de caracteres específicas. Utilice expresiones regulares para hacer coincidir patrones en las cadenas.
- Limitar eVars en esquemas de Analytics: normalmente, un esquema de Analytics solo debe tener un eVar designado como identidad. Si tiene intención de utilizar más de un eVar como identidad, debe comprobar si la estructura de datos se puede optimizar.
- Garantizar la exclusividad de un campo seleccionado: el campo elegido debe ser único en comparación con la identidad principal del esquema. Si no es así, no la marque como identidad. Por ejemplo, si varios clientes pueden proporcionar la misma dirección de correo electrónico, ese área de nombres no es una identidad adecuada. Este principio también se aplica a otras áreas de nombres de identidad, como los números de teléfono.
- Restricciones: advertencias de déclencheur para campos de área de nombres personalizados: establezca restricciones para almacenar en déclencheur una advertencia cuando un campo de esquema esté marcado con un área de nombres personalizada sin especificar las longitudes mínima y máxima. La advertencia sirve como precaución importante para mantener la integridad de los datos. Consulte la propiedades de campo específicas del tipo para obtener información sobre cómo establecer restricciones en un campo concreto.
Pasos siguientes
Este documento abarcaba las directrices generales y las prácticas recomendadas para diseñar el modelo de datos para Experience Platform. Para resumir:
- Utilice un enfoque descendente ordenando las tablas de datos en categorías de perfil, búsqueda y evento antes de construir los esquemas.
- A menudo hay varios enfoques y opciones a la hora de diseñar esquemas para diferentes propósitos.
- El modelo de datos debe admitir casos de uso empresarial, como la segmentación o el análisis del recorrido del cliente.
- Simplifique los esquemas lo más posible y solo añada nuevos campos cuando sea absolutamente necesario.
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.