数据建模的最佳实践

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模式的过程。

以下示例为希望将数据导入Platform的公司表示简化的ERD。该图突出显示了应分类为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	添加	486502	1	10月1日，上午10点41分
1234567	添加	910482	5	10月3日，下午2:15

分段用例

在对实体进行分类时，请务必考虑您要构建的受众细分，以解决您的特定业务使用案例。

例如，公司希望了解其忠诚度项目中所有“黄金”或“白金”成员，这些成员在过去一年中进行了超过5次购买。根据这一分段逻辑，可就如何代表相关实体得出以下结论：

“黄金”和“白金”代表适用于个人客户的忠诚度状态。由于细分逻辑仅与客户的当前忠诚度状态有关，因此此数据可建模为用户档案模式的一部分。如果您希望跟踪忠诚度状态随时间的变化，还可以为忠诚度状态变化创建额外的事件模式。
购买是在特定时间发生的事件，区段逻辑与指定时间窗口内的购买事件有关。因此，应将此数据建模为事件模式。

激活用例

除了考虑细分使用案例外，您还应查看这些区段的激活使用案例，以确定其他相关属性。

例如，公司已根据country = US规则构建了受众段。然后，当将该段激活到某些下游目标时，公司希望根据家庭状态过滤所有导出的用户档案。因此，state属性也应在适用的用户档案实体中捕获。

汇总值

根据您数据的用例和粒度，您应决定在将某些值包含在用户档案或事件实体中之前，是否需要预聚合。

例如，公司希望根据购物车购买数构建区段。您可以通过将每个加盖时间戳的购买事件作为其自己的实体，选择以最低粒度合并此数据。但是，这有时会以指数方式增加记录的事件数。要减少摄取的事件数，您可以选择在一周或一个月的时间段内创建聚合值numberOfPurchases。其他聚合功能（如MIN和MAX）也可以应用于这些情况。

注意

Experience Platform当前不执行自动值聚合，但计划在将来的版本中执行。如果您选择使用聚合值，则必须在将数据发送到Platform之前在外部执行计算。

基数

在ERD中建立的基数也可以提供一些关于如何对实体进行分类的线索。如果两个实体之间存在一对多关系，则表示“多”的实体可能是事件实体。但是，也有一些情况下，“many”是一组查找实体，它们作为用户档案实体中的数组提供。

注意

由于没有通用的方法来适合所有用例，因此在根据基数对实体进行分类时，必须考虑每种情况的利弊。有关详细信息，请参阅下一节。

下表概述了一些常见的实体关系以及可以从它们派生的类别:

关系	基数	实体类别
客户和购物车结账	一对多	单个客户可能有许多购物车结帐，这些结帐是可随时间跟踪的事件。因此，客户将是用户档案实体，而购物车结帐将是事件实体。
客户和忠诚度帐户	一对一	单个客户只能有一个忠诚度帐户，反之亦然。由于关系是一对一的，因此客户和忠诚度帐户都表示用户档案实体。
客户和订阅	一对多	单个客户可能具有许多订阅。由于公司只关心客户的当前订阅，因此客户是用户档案实体，而订阅是查找实体。

不同实体类的利弊

虽然上一节提供了一些关于如何对实体分类的一般准则，但必须了解，在选择一个实体类别而不是另一个实体时，往往有利有弊。以下案例研究旨在说明您在这些情况下如何考虑您的选择。

公司可跟踪客户的活动订阅，其中一个客户可以拥有许多订阅。公司还希望包括分段用例的订阅，如查找所有具有活动订阅的用户。

在此方案中，公司有两个潜在选项，用于在其订阅模型中表示客户的客户：

使用用户档案属性
使用事件实体

方法1:使用用户档案属性

第一种方法是将一组订阅作为用户档案实体中的客户属性。此数组中的对象将包含category、status、planName、startDate和endDate的字段。

专业人员

分段对于预期的用例是可行的。
模式将仅为客户保留最新的订阅记录。

缺点

每次对阵列中的任何字段发生更改时，都必须重述整个阵列。
如果不同的数据源或业务部门将数据馈送到阵列中，则保持最新更新的阵列在所有渠道之间同步将变得非常困难。

方法2:使用事件实体

第二种方法是使用事件模式来代表订阅。这需要添加与第一种方法相同的订阅字段，并添加订阅ID、客户ID和订阅事件发生时的时间戳。

专业人员

分段规则可以更灵活(例如，查找所有在过去30天内更改其订阅的客户)。
当客户的订阅状态发生更改时，您不必再更新客户的用户档案属性中一个长且可能复杂的阵列。如果客户的订阅列表同时发生来自多个来源的更改，则此功能特别有用。

缺点

对于原始预期用例(识别客户最近订阅的状态)，分段变得更复杂。该区段现在需要额外的逻辑来标记客户的最后一个订阅事件，以便检查其状态。

根据分类实体创建模式

将实体排序为用户档案、查找和事件类别后，您可以开始将数据模型转换为XDM模式。为便于演示，前面显示的示例数据模型已在下图中按适当类别分类：

实体已排序的类别应确定您基于其模式的XDM类。重申：

用户档案实体应使用XDM Individual Profile类。
事件实体应使用XDM ExperienceEvent类。
查找实体应使用您的组织定义的自定义XDM类。

注意

虽然事件实体几乎总是由单独的模式来表示，但用户档案或查找类别中的实体可以在一个XDM模式中组合在一起，具体取决于它们的基数。

例如，由于客户实体与LoyaltyAccounts实体有一对一关系，因此客户实体的模式还可包括一个LoyaltyAccount对象，以包含每个客户的相应忠诚度字段。但是，如果关系是一对多关系，则表示“多”的实体可以由单独的模式或一组用户档案属性表示，具体取决于其复杂性。

以下各节就根据您的ERD构建模式提供一般指导。

采用迭代建模方法

模式演化规则规定在模式实施后，只能对其进行无损更改。换句话说，在您向模式添加字段且已针对该字段摄取数据后，该字段便无法再删除。因此，在您首次创建模式时，必须采用迭代建模方法，首先是简化实施，它会随着时间的推移逐渐增加复杂性。

如果您不确定是否需要在模式中包含特定字段，则最佳做法是将其排除在外。如果稍后确定该字段是必需的，则始终可以在模式的下一次迭代中添加该字段。

标识字段

在Experience Platform中，标为身份的XDM字段用于整合来自多个数据源的个别客户的信息。虽然模式可以有多个标记为身份的字段，但必须定义单个主身份，才能启用模式以在Real-time Customer Profile中使用。有关这些字段用例的更多详细信息，请参阅模式合成基础知识中标识字段部分。

在设计模式时，关系数据库表中的任何主键都可能是主标识的候选项。适用标识字段的其他示例包括客户电子邮件地址、电话号码、帐户ID和ECID。