Real-time Customer Profile proporciona perfiles individuales que le permiten ofrecer experiencias personalizadas entre canales basadas en perspectivas de comportamiento y atributos del cliente. Para lograr este objetivo, Profile y el motor de segmentación dentro de Adobe Experience Platform utilizan un modelo de datos híbridos altamente desnormalizado que oferta un nuevo enfoque para desarrollar perfiles de clientes. El uso de este modelo de datos híbridos hace extremadamente importante que los datos que se recopilan se modelen correctamente. Aunque el almacén de datos Profile que mantiene los datos de perfil no es un almacén relacional, Profile permite la integración con entidades de dimensión pequeñas para crear segmentos de forma simplificada e intuitiva. Esta integración se conoce como segmentación multientidad.
Adobe Experience Platform proporciona una serie de protecciones que le ayudan a evitar la creación de modelos de datos que Real-time Customer Profile no son compatibles. Este documento describe las prácticas recomendadas y las restricciones al utilizar entidades de dimensión, específicamente en la segmentación por lotes.
Los guardas y límites que se describen en este documento se están mejorando constantemente. Regrese regularmente para ver las actualizaciones.
Se recomienda leer la siguiente documentación de servicios de Experience Platform antes de intentar crear modelos de datos para utilizarlos en Real-time Customer Profile. Trabajar con modelos de datos y las barreras descritas en este documento requiere comprender los diversos servicios de Experience Platform que intervienen en la gestión de Real-time Customer Profile las entidades:
El modelo Profile de datos de almacenamiento consta de dos tipos de entidades principales:
Entidad principal: Una entidad principal, o entidad perfil, combina los datos para formar una "única fuente de verdad" para un individuo. Estos datos unificados se representan usando lo que se conoce como "vista de unión". Una vista de unión agrega los campos de todos los esquemas que implementan la misma clase en un único esquema de unión. El esquema de unión para Real-time Customer Profile es un modelo de datos híbridos desnormalizado que actúa como contenedor para todos los eventos de comportamiento y atributos de perfil.
Los atributos independientes del tiempo, también conocidos como "datos de registro", se modelan usando XDM Individual Profile, mientras que los datos de series temporales, también conocidos como "datos de evento", se modelan usando XDM ExperienceEvent. A medida que los datos de registros y series temporales se ingieren en Adobe Experience Platform, se activa Real-time Customer Profile el inicio de la ingesta de datos que se han habilitado para su uso. Cuanto más interacciones y detalles se ingieran, más robustos se volverán los perfiles individuales.
Entidad Dimension: Su organización también puede definir clases XDM para describir otras cosas que no son personas, como tiendas, productos o propiedades. Estos esquemas noXDM Individual Profile se conocen como "entidades de dimensión" y no contienen datos de series temporales. Las entidades Dimension proporcionan datos de búsqueda que ayudan y simplifican las definiciones de segmentos de varias entidades y deben ser lo suficientemente pequeñas como para que el motor de segmentación pueda cargar todo el conjunto de datos en la memoria para un procesamiento óptimo (búsqueda rápida de puntos).
Al definir el modelo de datos, se recomienda permanecer dentro de los márgenes de seguridad proporcionados para garantizar un rendimiento adecuado y evitar errores en el sistema. Las barandillas previstas en este documento incluyen dos tipos de límite:
Límite suave: Un límite suave proporciona un máximo recomendado para un rendimiento óptimo del sistema. Es posible ir más allá de un límite suave sin romper el sistema ni recibir mensajes de error, aunque ir más allá de un límite suave provocará una degradación del rendimiento. Se recomienda mantenerse dentro del límite suave para evitar disminuciones en el rendimiento general.
Límite duro: Un límite máximo absoluto para el sistema. Si se supera un límite máximo, se producirán errores y roturas, lo que impedirá que el sistema funcione según lo previsto.
Al crear un modelo de datos para utilizarlo con Real-time Customer Profile, se recomienda seguir las siguientes instrucciones.
Guardrade | Límite | Tipo de límite | Descripción |
---|---|---|---|
Número de conjuntos de datos recomendados para contribuir al esquema de Profile unión | 20 | Leve | Se recomienda un máximo de 20 conjuntos de datos Profilehabilitados. Para habilitar otro conjunto de datos para Profile, primero se debe eliminar o deshabilitar un conjunto de datos existente. |
Número de relaciones de varias entidades recomendadas | 5 | Leve | Se recomienda un máximo de 5 relaciones de varias entidades definidas entre entidades principales y entidades de dimensión. No se deben realizar asignaciones de relación adicionales hasta que se elimine o desactive una relación existente. |
Profundidad máxima de JSON para el campo de ID utilizado en la relación de varias entidades | 4 | Leve | La profundidad máxima recomendada de JSON para un campo de ID utilizado en relaciones de varias entidades es 4. Esto significa que en un esquema muy anidado, los campos anidados con más de 4 niveles de profundidad no deben utilizarse como campo de ID en una relación. |
Cardinalidad de matriz en un fragmento de perfil | <=500 | Leve | La cardinalidad óptima de la matriz en un fragmento de perfil (datos independientes del tiempo) es <=500. |
Cardinalidad de matriz en ExperienceEvent | <=10 | Leve | La cardinalidad óptima de la matriz en un evento ExperienceEvent (datos de series temporales) es <=10. |
Guardrade | Límite | Tipo de límite | Descripción |
---|---|---|---|
No se permiten datos de series temporales para entidades que no sonXDM Individual Profile entidades | 0 | Grave | No se permiten datos de series temporales para entidades que no pertenecen a Perfil ServiceXDM Individual Profile . Si un conjunto de datos de series temporales está asociado con un no-XDM Individual Profile ID, el conjunto de datos no debe habilitarse para Profile. |
No hay relaciones anidadas | 0 | Leve | No debe crear una relación entre dos no esquemasXDM Individual Profile . No se recomienda la capacidad de crear relaciones para ningún esquema que no forme parte del esquema de Profile unión. |
Profundidad JSON máxima para el campo de ID principal | 4 | Leve | La profundidad máxima recomendada de JSON para el campo de ID principal es 4. Esto significa que en un esquema muy anidado, no debe seleccionar un campo como ID principal si está anidado con más de 4 niveles de profundidad. Un campo que se encuentra en el cuarto nivel anidado puede utilizarse como ID principal. |
Las siguientes barreras hacen referencia al tamaño de los datos y se recomiendan para garantizar que los datos se puedan ingerir, almacenar y consultar según lo previsto.
El tamaño de los datos se medirá como datos sin comprimir en JSON en el momento de la ingestión.
Guardrade | Límite | Tipo de límite | Descripción |
---|---|---|---|
Tamaño máximo por fragmento de perfil | 10KB | Leve | El tamaño máximo recomendado de un fragmento de perfil es de 10 KB. La ingesta de fragmentos de perfil más grandes afectará al rendimiento del sistema. Por ejemplo, si se carga un conjunto de datos CRM pesado en el que algunos fragmentos de perfil tienen un tamaño de 50 kB, se degradará el rendimiento del sistema. |
Tamaño máximo absoluto por fragmento de perfil | 1MB | Grave | El tamaño máximo absoluto de un fragmento de perfil es de 1 MB. La ingestión fallará al intentar cargar un fragmento de perfil de más de 1 MB. |
Guardrade | Límite | Tipo de límite | Descripción |
---|---|---|---|
Tamaño total máximo para todas las entidades dimensionales | 5 GB | Leve | El tamaño total máximo recomendado para todas las entidades dimensionales es de 5 GB. La ingesta de entidades de dimensiones grandes provocará una degradación del rendimiento del sistema. Por ejemplo, no se recomienda intentar cargar un catálogo de productos de 10 GB como una entidad de dimensión. |
Conjuntos de datos por esquema de entidad dimensional | 5 | Leve | Se recomienda un máximo de 5 conjuntos de datos asociados con cada esquema de entidad dimensional. Por ejemplo: si crea un esquema para "productos" y agrega cinco conjuntos de datos de contribución, no debe crear un sexto conjunto de datos vinculado al esquema de productos. |