数据建模最佳实践

Experience Data Model (XDM)是一个核心框架，通过提供用于下游Adobe Experience Platform服务的通用结构和定义来标准化客户体验数据。通过遵循XDM标准，可以将所有客户体验数据整合到通用的演示文稿中，以便您从客户操作中获得有价值的分析，通过区段定义客户受众，以及为个性化目的表达客户属性。

由于XDM具有极强的通用性和可通过设计进行自定义，因此在设计架构时务必遵循数据建模的最佳实践。 本文档介绍了在将客户体验数据映射到XDM时必须做出的关键决策和注意事项。

入门指南

在阅读本指南之前，请查阅XDM系统概述 ，以了解XDM及其在Experience Platform中的角色的高级介绍。

此外，本指南专门重点介绍有关模式设计的关键注意事项。 因此，强烈建议您参阅架构组合基础知识 ，以详细解释本指南中提到的各个架构元素。

最佳实践摘要

设计数据模型以供在Experience Platform中使用的推荐方法可概括如下：

1. 了解数据的业务用例。
2. 确定应引入Platform以解决这些用例的主数据源。
3. 确定可能也感兴趣的任何辅助数据源。 例如，如果贵组织当前只有一个业务部门有兴趣将其数据迁移到Platform，则类似业务部门将来也可能有兴趣迁移类似数据。 考虑这些辅助来源有助于标准化整个组织的数据模型。
4. 为已识别的数据源创建高级实体关系图(ERD)。
5. 将高级ERD转换为以Platform为中心的ERD（包括用户档案、体验事件和查询实体）。

与确定执行业务用例所需的适用数据源相关的步骤因组织而异。 虽然本文档的其余部分侧重于在确定数据源后组织和构建ERD的后续步骤，但对该图表各个组成部分的说明可能会使您决定哪些数据源应迁移到Platform。

创建高级ERD

确定要引入Platform的数据源后，请创建一个高级ERD以帮助指导将数据映射到XDM架构的过程。

以下示例是希望将数据导入Platform的公司的简化ERD。 此图突出显示了应归类为XDM类的基本实体，包括客户帐户、酒店、地址和几个常见的电子商务事件。

将实体按配置文件、查找和事件类别进行排序

创建ERD以标识要纳入Platform的基本实体后，这些实体必须按配置文件、查找和事件类别进行分类：

有关实体排序的注意事项

以下各节就如何将实体按上述类别进行排序提供了进一步指导。

客户属性

如果实体包含任何与单个客户相关的属性，则很可能是用户档案实体。 客户属性的示例包括：

• 个人详细信息，如姓名、出生日期、性别和帐户ID。
• 位置信息，如地址和GPS信息。
• 联系信息，如电话号码和电子邮件地址。

随时间跟踪数据

如果要分析实体中某些属性随时间的变化情况，事件实体很可能是。 例如，将产品项目添加到购物车可作为Platform中的添加到购物车事件进行跟踪：

分段用例

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

例如，某公司希望了解其忠诚度计划中所有“黄金”或“白金”会员，这些会员在过去一年中购买了超过五次产品。 根据这一分段逻辑，可以就如何表示相关实体得出以下结论：

• “金牌”和“白金”表示适用于个人客户的忠诚度状态。 由于区段逻辑仅与客户的当前忠诚度状态有关，因此此数据可以建模为用户档案架构的一部分。 如果您希望跟踪忠诚度状态随时间的变化，则还可以为忠诚度状态更改创建其他事件架构。
• 购买是指在特定时间发生的事件，区段逻辑与指定时间范围内的购买事件有关。 因此，应将此数据建模为事件模式。

激活用例

除了与分段用例相关的注意事项外，您还应检查这些区段的激活用例，以确定其他相关属性。

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

汇总值

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

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

基数

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

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

不同实体类的利弊

虽然上一节提供了一些决定如何对实体进行分类的一般准则，但务必要了解在选择一个实体类别而不是另一个实体类别时通常会有利弊。 以下案例研究旨在说明在这些情况下如何考虑您的选项。

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

在这种情况下，公司有两个潜在的选项来代表客户在其数据模型中的订阅：

1. 使用配置文件属性
2. 使用事件实体

方法1:使用配置文件属性

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

优点

• 对预期用例进行分段是可行的。
• 该架构将仅保留客户的最新订阅记录。

缺点

• 每当阵列中的任何字段发生更改时，必须重述整个阵列。
• 如果不同的数据源或业务部门将数据馈送到阵列中，那么保持最新更新的阵列在所有渠道之间同步将变得极具挑战性。

方法2:使用事件实体

第二种方法是使用事件模式来表示订阅。 这要求获取与第一种方法相同的订阅字段，以及订阅ID、客户ID和发生订阅事件时的时间戳。

优点

• 分段规则可以更加灵活（例如，查找过去30天内更改了订阅的所有客户）。
• 当客户的订阅状态发生更改时，您不再需要更新客户配置文件属性中一个可能非常复杂的长数组。 如果客户的订阅列表同时发生来自多个来源的更改，则此功能特别有用。

缺点

• 对于原始预期用例，分段变得更加复杂（确定客户最近订阅的状态）。 该区段现在需要其他逻辑来标记客户的最后一个订阅事件，以检查其状态。

根据分类的实体创建架构

将实体排序到用户档案、查询和事件类别后，您便可以开始将数据模型转换为XDM架构。 出于演示目的，前面显示的示例数据模型在下图中已分类为相应的类别：

实体在下排序的类别应确定其架构所基于的XDM类。 重申：

• 配置文件实体应使用XDM Individual Profile类。
• 事件实体应使用XDM ExperienceEvent类。
• 查找实体应使用由贵组织定义的自定义XDM类。

以下各节提供了有关基于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模板字段组允许您将特定于Analytics的字段映射到XDM架构。 根据您正在使用的Adobe应用程序，您应该在架构中使用这些Adobe提供的字段组。

Adobe应用程序字段组通过使用identityMap字段自动分配默认的主标识，该字段是系统生成的只读对象，用于映射单个客户的标准标识值。

对于Adobe Analytics,ECID是默认的主标识。 如果客户未提供ECID值，则主标识将默认使用AAID。

后续步骤

本文档介绍了设计数据模型以进行Experience Platform的一般准则和最佳实践。 总结如下：

• 在构建架构之前，请使用自上而下的方法，将数据表按用户档案、查找和事件类别进行排序。
• 在设计用于不同目的的架构时，通常有多种方法和选项。
• 您的数据模型应支持您的业务用例，如分段或客户历程分析。
• 使您的架构尽可能简单，并且仅在绝对必要时添加新字段。

准备就绪后，请参阅在UI中创建架构的教程，以了解有关如何创建架构、为实体分配相应类以及添加字段以将数据映射到的分步说明。