数据建模的最佳实践
Experience Data Model (XDM)是通过提供在下游Adobe Experience Platform服务中使用的通用结构和定义来标准化客户体验数据的核心框架。 通过遵守XDM标准，所有客户体验数据都可以纳入到通用表示法中，从而使您可以从客户操作中获得有价值的见解，通过区段定义客户受众，以及表达客户属性以进行个性化。
由于XDM极其通用并且可通过设计进行自定义，因此，在设计架构时遵循数据建模的最佳实践非常重要。 本文档介绍了在将客户体验数据映射到XDM时必须做出的关键决策和考虑事项。
快速入门
在阅读本指南之前，请查阅 XDM系统概述 简要介绍XDM及其在Experience Platform中的作用。
此外，本指南专门侧重于与架构设计相关的重要注意事项。 因此，强烈建议您参阅 模式组合基础 详细解释本指南中提到的各个架构元素。
最佳实践摘要
设计用于Experience Platform的数据模型的推荐方法可概括如下：
- 了解数据的业务用例。
- 确定应引入的主要数据源 Platform 以解决这些用例。
- 确定可能还感兴趣的任何辅助数据源。 例如，如果贵组织中目前只有一个业务部门有兴趣将其数据移植到 Platform，类似的业务部门将来可能也有兴趣移植相似的数据。 考虑这些辅助源有助于在整个组织中标准化数据模型。
- 为已识别的数据源创建高级实体关系图(ERD)。
- 将高级ERD转换为 Platform — 中心ERD（包括用户档案、体验事件和查找实体）。
与确定执行业务用例所需的适用数据源相关的步骤因组织而异。 虽然本文档的其余部分侧重于确定数据源后组织和构建ERD的后续步骤，但图表各部分的解释可能会指导您决定应该将数据源迁移到哪个 Platform.
创建高级ERD
确定您要引入的数据源后 Platform，创建一个高级ERD以帮助指导将数据映射到XDM架构的过程。
以下示例为希望将数据引入其中的公司提供了一个简化的ERD Platform. 该图表突出显示应分类为XDM类的基本实体，包括客户帐户、酒店、地址和几个常见电子商务事件。
按配置文件、查找和事件类别对实体进行排序
创建ERD以标识要导入的基本实体后 Platform，这些实体必须按配置文件、查找和事件类别排序：
| 类别 | 描述 |
|---|---|
| 配置文件实体 | 配置文件实体表示与个人（通常是客户）相关的属性。 属于此类别的实体应采用基于 XDM Individual Profile类. |
| 查找实体 | 查找实体表示可能与个人相关的概念，但不能直接用于标识个人。 属于此类别的实体应由基于以下条件的架构表示： 自定义类，并通过链接到用户档案和事件 架构关系. |
| 事件实体 | 事件实体表示与客户可以采取的操作、系统事件或您可能希望随时间跟踪更改的任何其他概念相关的概念。 属于此类别的实体应采用基于 XDM ExperienceEvent类. |
实体排序的注意事项
以下部分提供了有关如何将实体分类到上述类别中的进一步指导。
可变和不可变数据
实体类别之间的主要排序方式是捕获的数据是否可变。
属于配置文件或查找实体的属性通常可变。 例如，客户的偏好可能会随着时间的推移而改变，订阅计划的参数可以根据市场趋势进行更新。
相反，事件数据通常不可变。 由于事件附加到特定时间戳，因此事件提供的“系统快照”不会更改。 例如，事件可在客户结账购物车时捕获其偏好设置，即使客户的偏好设置稍后最终发生更改，事件也不会更改。 事件数据在记录后无法更改。
总而言之，用户档案和查找实体包含可变属性，表示它们捕获的主题的最新信息，而事件是在特定时间系统的不可变记录。
客户属性
如果实体包含与单个客户相关的任何属性，则很可能是用户档案实体。 客户属性的示例包括：
- 个人详细信息，例如姓名、出生日期、性别和帐户ID。
- 位置信息，例如地址和GPS信息。
- 联系信息，如电话号码和电子邮件地址。
随时间跟踪数据
如果要分析实体中的某些属性如何随时间变化，则很可能是事件实体。 例如，可以将将产品项目添加到购物车作为中的添加到购物车事件进行跟踪 Platform：
| 客户 ID | 类型 | 产品 ID | 数量 | 时间戳 |
|---|---|---|---|---|
| 1234567 | Add | 275098 | 2 | 10月1日，上午10点32分 |
| 1234567 | 删除 | 275098 | 1 | 10月1日，上午10点33分 |
| 1234567 | Add | 486502 | 1 | 10月1日，上午10点41分 |
| 1234567 | Add | 910482 | 5 | 10月3日，下午2:15 |
分段用例
在对实体进行分类时，请务必考虑您可能希望构建的受众区段，以解决特定的业务用例。
例如，一家公司希望了解其忠诚度计划的所有“黄金”或“白金”会员，这些会员去年购买了5次以上。 根据此区段逻辑，可就相关实体应如何呈列得出以下结论：
- “金级”和“白金级”表示适用于单个客户的忠诚度状态。 由于区段逻辑仅与客户当前的忠诚度状态有关，因此此数据可以建模为配置文件架构的一部分。 如果您希望跟踪忠诚度状态随时间的变化，还可以为忠诚度状态更改创建其他事件架构。
- 购买是在特定时间发生的事件，区段逻辑与指定时间范围内的购买事件有关。 因此，此数据应建模为事件架构。
激活用例
除了有关分段用例的考虑事项外，您还应查看这些区段的激活用例，以确定其他相关的属性。
例如，一家公司已基于以下规则构建了受众区段： country = US. 然后，在将该区段激活到某些下游目标时，公司想要根据主页状态筛选所有导出的用户档案。 因此，a state 属性还应在适用的配置文件实体中捕获。
聚合值
根据用例和数据粒度，您应决定是否需要在包含到用户档案或事件实体中之前预先聚合某些值。
例如，一家公司希望根据购物车购买次数构建区段。 您可以选择以最低的粒度合并此数据，方法是将每个带有时间戳的购买事件包含为其自己的实体。 但是，这有时可能会使记录的事件数呈指数增长。 要减少摄取的事件数，您可以选择创建聚合值 numberOfPurchases 一个星期或一个月的时间。 其他聚合函数(如MIN和MAX)也可以应用于这些情况。
Experience Platform当前不执行自动值聚合，尽管计划在将来的版本中执行此操作。 如果选择使用聚合值，则必须先从外部执行计算，然后再将数据发送到 Platform.
基数
在ERD中建立的基数还可以提供有关如何对实体进行分类的一些线索。 如果两个实体之间存在一对多关系，则表示“多个”的实体可能是一个事件实体。 但是，在某些情况下，“许多”是作为配置文件实体中的数组提供的一组查找实体。
由于没有适合所有用例的通用方法，因此根据基数对实体进行分类时，必须考虑每种情况的利弊。 请参阅 下一节 了解更多信息。
下表概述了一些常见的实体关系以及可从这些关系派生出的类别：
| 关系 | 基数 | 实体类别 |
|---|---|---|
| 客户和购物车结账 | 一对多 | 单个客户可能拥有许多购物车结账，这些事件可以随时间进行跟踪。 因此，客户将成为用户档案实体，而购物车结账将成为事件实体。 |
| 客户和忠诚度帐户 | 一对一 | 单个客户只能有一个忠诚度帐户，反之亦然。 由于关系是一对一的，因此客户和忠诚度帐户都表示用户档案实体。 |
| 客户和订阅 | 一对多 | 单个客户可能拥有许多订阅。 由于公司仅关注客户的当前订阅，因此“客户”是一个用户档案实体，“订阅”是一个查找实体。 |
不同实体类的优缺点
虽然上一节提供了一些确定如何对实体进行分类的一般准则，但务必要了解，选择一个实体类别通常有利有弊，而不选择另一个实体类别。 以下案例研究旨在说明如何在这些情况下考虑选项。
公司跟踪其客户的活跃订阅，其中一位客户可以拥有多个订阅。 该公司还希望将订阅纳入细分用例，例如查找具有活动订阅的所有用户。
在此方案中，公司有两个潜在选项，用于在客户的数据模型中表示客户的订阅：
方法1：使用用户档案属性
第一种方法是将一系列订阅作为属性包含在适用于客户的配置文件实体中。 此数组中的对象将包含 category， status， planName， startDate、和 endDate.
优点
- 分段适用于预期用例。
- 架构将仅保留客户的最新订阅记录。
缺点
- 每次对数组中的任何字段发生更改时，都必须重述整个数组。
- 如果不同的数据源或业务单位将数据馈送到阵列，那么要在所有通道上保持最新的更新阵列同步将变得非常困难。
方法2：使用事件实体
第二种方法是使用事件架构来表示订阅。 这需要摄取与第一种方法相同的订阅字段，以及订阅ID、客户ID和订阅事件发生的时间戳。
优点
- 分段规则可以更灵活（例如，查找过去30天内更改了订阅的所有客户）。
- 当客户的订阅状态发生变化时，您不必再更新客户配置文件属性中可能很复杂的长数组。 如果对客户的订阅列表同时进行的更改来自多个来源，则此功能特别有用。
缺点
- 对于原始预期用例（确定客户最近订阅的状态），分段变得更加复杂。 区段现在需要额外的逻辑来标记客户的上一个订阅事件，以检查其状态。
- 事件自动过期并从配置文件存储区中清除的风险较高。 请参阅指南，网址为 体验事件过期时间 了解更多信息。
根据已分类的实体创建架构
将实体分类为配置文件、查找和事件类别后，即可开始将数据模型转换为XDM架构。 出于演示目的，前面显示的示例数据模型已在下图中被分类为相应的类别：
实体排序所依据的类别应决定其架构所基于的XDM类。 重申：
- 配置文件实体应使用 XDM Individual Profile 类。
- 事件实体应使用 XDM ExperienceEvent 类。
- 查找实体应使用您的组织定义的自定义XDM类。 然后，配置文件和事件实体可以通过架构关系引用这些查找实体。
虽然事件实体几乎始终由单独的架构表示，但配置文件或查找类别中的实体可以根据其基数组合到单个XDM架构中。
例如，由于Customers实体与LoyaltyAccounts实体存在一对一的关系，因此Customers实体的架构还可以包括 LoyaltyAccount 对象中包含每个客户的相应忠诚度字段。 但是，如果关系是一对多，则代表“多”的实体可能由单独的架构或配置文件属性数组表示，具体取决于其复杂性。
以下部分提供了有关根据ERD构建架构的一般指导。
采用迭代建模方法
此 模式演化规则 规定实施架构后，只能对架构进行非破坏性更改。 换言之，一旦将字段添加到架构且已根据该字段摄取数据，则无法再移除该字段。 因此，在首次创建架构时务必采用迭代建模方法，从随着时间推移逐渐增加复杂性的简化实施开始。
如果您不确定是否需要将特定字段包含在架构中，最佳实践是将其排除在外。 如果以后确定该字段是必需的，则始终可以将该字段添加到架构的下一个迭代中。
标识字段
在Experience Platform中，标记为身份的XDM字段用于拼接来自多个数据源的单个客户的信息。 尽管架构可以有多个标记为身份的字段，但必须定义一个主身份，架构才能在中启用 Real-Time Customer Profile. 请参阅以下部分： 标识字段 在架构组合的基础知识中，了解有关这些字段用例的更多详细信息。
在设计架构时，关系数据库表中的任何主键都可能是主标识的候选者。 适用的标识字段的其他示例包括客户电子邮件地址、电话号码、帐户ID和 ECID.
Adobe的应用程序架构字段组
Experience Platform提供了多个现成的XDM架构字段组，用于捕获与以下Adobe应用程序相关的数据：
- Adobe Analytics
- Adobe Audience Manager
- Adobe Campaign
- Adobe Target
例如， Adobe Analytics ExperienceEvent模板 字段组 允许您映射 AnalyticsXDM架构的特定字段。 根据您使用的Adobe应用程序，您应在架构中使用这些Adobe提供的字段组。
Adobe应用程序字段组通过使用 identityMap 字段，这是一个系统生成的只读对象，可映射单个客户的标准标识值。
对于Adobe Analytics，ECID是默认的主标识。 如果客户未提供ECID值，则主标识将默认使用AAID。
使用Adobe应用程序字段组时，不应将任何其他字段标记为主标识。 如果需要将其他属性标记为身份，则需要将这些字段指定为辅助身份。
后续步骤
本文档介绍了为Experience Platform设计数据模型的一般准则和最佳实践。 总结一下：
- 在构建架构之前，可使用自上而下的方法，将数据表排序为用户档案、查找和事件类别。
- 在设计用于不同目的的架构时，通常有多种方法和选项。
- 您的数据模型应支持您的业务用例，例如分段或客户历程分析。
- 使您的架构尽可能简单，仅在绝对必要时添加新字段。
准备就绪后，请参阅上的教程 在UI中创建架构 有关如何创建架构的分步说明，请为实体分配适当的类，并添加要将数据映射到其中的字段。
Business.Adobe.com 资源
