数据建模的最佳实践
Experience Data Model (XDM)是通过提供在下游Adobe Experience Platform服务中使用的通用结构和定义来标准化客户体验数据的核心框架。 通过遵守XDM标准，所有客户体验数据都可以合并到一个通用表示中，并用于从客户操作中获得有价值的见解、定义客户受众以及表达客户属性以进行个性化。
由于XDM极其通用并且可通过设计进行自定义，因此，在设计架构时遵循数据建模的最佳实践至关重要。 本文档介绍了在将客户体验数据映射到XDM时必须做出的关键决策和注意事项。
快速入门
阅读本指南之前，请查阅 XDM系统概述 详细介绍XDM及其在Experience Platform中的角色。
由于本指南仅侧重于架构设计方面的关键注意事项，因此强烈建议您阅读 模式组合基础 有关本指南中提到的各个架构元素的详细说明。
最佳实践摘要 summary
设计用于Experience Platform的数据模型的推荐方法可概括如下：
- 了解数据的业务用例。
- 确定应引入的主要数据源 Platform 以解决这些用例。
- 确定可能还感兴趣的任何辅助数据源。 例如，如果贵组织中目前只有一个业务部门有兴趣将其数据迁移到 Platform，类似的业务部门将来可能也有兴趣移植类似的数据。 考虑这些次要源有助于在整个组织中标准化数据模型。
- 为已识别的数据源创建高级实体关系图(ERD)。
- 将高级ERD转换为 Platform以为中心ERD（包括用户档案、体验事件和查找实体）。
与确定实施业务用例所需的适用数据源相关的步骤因组织而异。 虽然本文档中的其余部分侧重于确定数据源后组织和构建ERD的后几个步骤，但图表各组件的解释可能会指导您决定应该将数据源迁移到哪个 Platform.
创建高级ERD create-an-erd
确定您要引入的数据源后 Platform，创建一个高级ERD以帮助指导将数据映射到XDM架构的过程。
以下示例为希望将数据引入其中的公司提供了一个简化的ERD Platform. 该图表突出显示应分类为XDM类的基本实体，包括客户帐户、酒店、地址和几个常见的电子商务事件。
按配置文件、查找和事件类别对实体进行排序 sort-entities
创建ERD以标识要导入的基本实体后 Platform，这些实体必须按配置文件、查找和事件类别排序：
实体排序的注意事项 considerations
以下各节提供了有关如何将实体分类为上述类别的进一步指导。
可变和不可变数据 mutable-and-immutable-data
实体类别之间的主要排序方式是捕获的数据是否可变。
属于配置文件或查找实体的属性通常可变。 例如，客户的偏好可能会随着时间的推移而改变，订阅计划的参数可以根据市场趋势进行更新。
相反，事件数据通常不可变。 由于事件附加到特定的时间戳，因此事件提供的“系统快照”不会更改。 例如，事件可在客户结账购物车时捕获其偏好设置，即使客户的偏好设置以后最终发生更改，事件也不会更改。 事件数据在记录后无法更改。
总而言之，配置文件和查找实体包含可变属性，并代表它们捕获的主题的最新信息，而事件在特定时间是系统的不可变记录。
客户属性 customer-attributes
如果实体包含与单个客户相关的任何属性，则它很可能为用户档案实体。 客户属性的示例包括：
- 个人详细信息，例如姓名、出生日期、性别和帐户ID。
- 位置信息，如地址和GPS信息。
- 联系信息，如电话号码和电子邮件地址。
随时间跟踪数据 track-data
如果要分析实体中的某些属性如何随时间变化，则很可能是事件实体。 例如，将产品项目添加到购物车可以在中作为添加到购物车事件进行跟踪 Platform：
分段用例 segmentation-use-cases
在对实体进行分类时，请务必考虑您可能希望构建的受众以解决特定业务用例。
例如，一家公司希望了解其忠诚度计划中的所有“黄金”或“白金”会员，这些会员去年购买了5次以上。 基于此分段逻辑，可以得出以下关于应如何表示相关实体的结论：
- “金级”和“白金级”表示适用于单个客户的忠诚度状态。 由于分段逻辑仅与客户当前的忠诚度状态有关，因此该数据可以建模为用户档案模式的一部分。 如果您希望跟踪忠诚度状态随时间的变化，还可以为忠诚度状态更改创建其他事件架构。
- 购买是在特定时间发生的事件，分段逻辑涉及指定时间窗口中的购买事件。 因此，此数据应建模为事件架构。
激活用例 activation-use-cases
除了有关分段用例的注意事项外，您还应查看这些受众的激活用例，以确定其他相关的属性。
例如，一家公司已基于以下规则构建受众： country = US. 然后，在将该受众激活到某些下游目标时，公司想要根据主页状态筛选所有导出的用户档案。 因此，a state 属性还应在适用的配置文件实体中捕获。
聚合值 aggregated-values
根据用例和数据粒度，您应当决定是否需要在包含到用户档案或事件实体中之前预先聚合某些值。
例如，公司希望根据购物车购买次数构建受众。 您可以选择以最低的粒度合并此数据，方法是将每个带有时间戳的购买事件包含为自己的实体。 但是，这有时可能会使记录的事件数呈指数增长。 要减少摄取的事件数，您可以选择创建聚合值 numberOfPurchases 跨越一周或一个月很长的周期。 其他聚合函数(如MIN和MAX)也可以应用于这些情况。
基数 cardinality
在ERD中建立的基数还可以提供有关如何对实体进行分类的一些线索。 如果两个实体之间存在一对多关系，则表示“多个”的实体很可能是一个事件实体。 但是，在某些情况下，“许多”是一组查找实体，这些实体在配置文件实体中作为数组提供。
下表概述了一些常见的实体关系以及可从这些关系派生的类别：
不同实体类的优缺点 pros-and-cons
虽然上一节提供了一些确定实体分类的一般准则，但务必要了解，选择一个实体类别通常有利有弊。 以下案例研究旨在说明在这些情况下如何考虑您的选项。
公司跟踪其客户的活跃订阅，一个客户可以有多个订阅。 该公司还希望将订阅纳入分段用例，例如查找具有活动订阅的所有用户。
在此方案中，公司有两个潜在选项，用于在客户的数据模型中表示客户的订阅：
方法1：使用用户档案属性 profile-approach
第一种方法是将一系列订阅作为属性包含在适用于客户的配置文件实体中。 此数组中的对象将包含 category， status， planName， startDate、和 endDate.
优点
- 分段适用于预期用例。
- 架构仅保留客户的最新订阅记录。
缺点
- 每次对数组中的任何字段发生更改时，必须重述整个数组。
- 如果不同的数据源或业务单位将数据馈送到阵列，则要在所有通道上保持最新更新的阵列同步将变得非常困难。
方法2：使用事件实体 event-approach
第二种方法是使用事件架构来表示订阅。 此方法需要摄取与第一种方法相同的订阅字段，以及订阅ID、客户ID和订阅事件发生时间的时间戳。
优点
- 分段规则可以更灵活（例如，查找过去30天内更改了订阅的所有客户）。
- 当客户的订阅状态发生变化时，您不必再更新客户配置文件属性中冗长、可能复杂的阵列。 如果同时从多个来源对客户的订阅列表进行更改，此功能会特别有用。
缺点
- 对于原始预期用例（确定客户最近订阅的状态），分段会变得更加复杂。 受众现在需要其他逻辑来标记客户的上一个订阅事件，以检查其状态。
- 事件自动过期并从配置文件存储区中清除的风险更高。 请参阅指南，网址为 体验事件过期时间 以了解更多信息。
根据已分类的实体创建架构 schemas-for-categorized-entities
将实体分类为配置文件、查找和事件类别后，即可开始将数据模型转换为XDM架构。 出于演示目的，前面显示的示例数据模型已在下图中被分类为相应的类别：
实体已在其下排序的类别应该确定您确定其架构所基于的XDM类。 再次重申：
- 配置文件实体应使用 XDM Individual Profile 类。
- 事件实体应使用 XDM ExperienceEvent 类。
- 查找实体应使用由您的组织定义的自定义XDM类。 然后，配置文件和事件实体可以通过架构关系引用这些查找实体。
LoyaltyAccount 对象中包含每个客户的相应忠诚度字段。 但是，如果关系是一对多，则代表“多”的实体可能由单独的架构或配置文件属性数组表示，具体取决于其复杂性。以下部分提供了有关根据ERD构建架构的一般指导。
采用迭代建模方法 iterative-modeling
此 模式演化规则 规定实施架构后，只能对架构进行非破坏性更改。 换言之，一旦您将字段添加到架构并且已根据该字段摄取数据，则无法再移除该字段。 因此，在首次创建架构时，务必要采用迭代建模方法，从随着时间推移逐渐增加复杂性的简化实施开始。
如果您不确定某个特定字段是否必须包含在架构中，最佳实践是将其排除在外。 如果之后确定该字段是必需的，则始终可以将该字段添加到架构的下一个迭代中。
标识字段 identity-fields
在Experience Platform中，标记为身份的XDM字段用于拼合来自多个数据源的各个客户的信息。 尽管架构可以有多个标记为身份的字段，但必须定义一个主身份，架构才能在中使用 Real-Time Customer Profile. 请参阅以下部分 标识字段 在架构组合的基础知识中，了解有关这些字段用例的更多详细信息。
在设计架构时，关系数据库表中的任何主键都可能是主标识的候选。 适用标识字段的其他示例包括客户电子邮件地址、电话号码、帐户ID和 ECID.
Adobe的应用程序架构字段组 adobe-application-schema-field-groups
Experience Platform提供了多个现成的XDM架构字段组，用于捕获与以下Adobe应用程序相关的数据：
- Adobe Analytics
- Adobe Audience Manager
- Adobe Campaign
- Adobe Target
例如，您可以使用 Adobe Analytics ExperienceEvent模板 字段组 要映射 Analytics特定于XDM架构的字段。 根据您使用的Adobe应用程序，应在架构中使用这些Adobe提供的字段组。
Adobe应用程序字段组通过使用 identityMap 字段，这是一个系统生成的只读对象，可映射单个客户的标准标识值。
对于Adobe Analytics，ECID是默认的主标识。 如果客户未提供ECID值，则主要标识将默认为AAID。
数据验证字段 data-validation-fields
将数据摄取到数据湖中时，仅对约束字段强制执行数据验证。 要在批量摄取期间验证特定字段，您必须在XDM架构中将字段标记为受约束。 为防止将错误数据摄取到Platform，建议在创建架构时定义字段级验证标准。
要对特定字段设置约束，请从架构编辑器中选择该字段以打开 字段属性 侧栏。 请参阅相关文档 特定类型的字段属性 以获取可用字段的精确描述。
维护数据完整性的提示 data-integrity-tips
以下是在创建架构时维护数据完整性的建议集合。
- 考虑主要身份：对于Web SDK、Mobile SDK、Adobe Analytics和Adobe Journey Optimizer等Adobe产品，
identityMap字段通常用作主标识。 避免将其他字段指定为该架构的主标识。 - 避免使用
_id作为标识：避免使用_id体验事件架构中作为标识的字段。 它用于记录唯一性，而不是用作身份。 - 设置长度约束：最佳实践是在标记为标识的字段上设置最小和最大长度。 如果您尝试将自定义命名空间分配给身份字段，但不满足最小和最大长度约束，则会触发警告。 这些限制有助于保持一致性和数据质量。
- 为一致的值应用模式：如果您的标识值遵循特定模式，则应使用 图案 设置为强制此约束。 此设置可以包括仅数字、大写或小写或特定字符组合等规则。 使用正则表达式匹配字符串中的模式。
- 在Analytics架构中限制eVar：通常，Analytics架构应仅将一个指定为身份的eVar。 如果要使用多个eVar作为标识，则应仔细检查数据结构是否可以优化。
- 确保所选字段的唯一性：与架构中的主标识相比，您选择的字段应该是唯一的。 如果不是，请不要将其标记为标识。 例如，如果多个客户可以提供相同的电子邮件地址，则该命名空间不是合适的身份。 此原则也适用于其他身份命名空间，如电话号码。
- 约束会触发自定义命名空间字段的警告：设置约束，以便在使用自定义命名空间标记架构字段时触发警告，而不指定最小和最大长度。 警告是维护数据完整性的重要警告。 请参阅 特定类型的字段属性 有关如何对特定字段设置约束条件的文档。
后续步骤
本文档介绍了为Experience Platform设计数据模型的一般准则和最佳实践。 总结一下：
- 在构建架构之前，使用自上而下的方法，将数据表排序为用户档案、查找和事件类别。
- 在为不同目的设计架构时，通常有多种方法和选项。
- 您的数据模型应支持您的业务用例，例如分段或客户历程分析。
- 使您的架构尽可能简单，并仅在绝对必要时添加新字段。
准备就绪后，请参阅上的教程 在UI中创建架构 有关如何创建架构的分步说明，请为实体分配适当的类，并添加要将数据映射到其中的字段。