数据建模的最佳实践

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的基本实体后,这些实体必须分类为用户档案、查找和事件类别:

类别 描述
用户档案实体 用户档案实体表示与个人(通常是客户)相关的属性。 属于此类别的实体应由基于​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 3 10月1日,上午10点41分
1234567 添加 910482 5 10月3日,下午2:15

细分用例

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

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

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

激活使用案例

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

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

聚集值

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

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

注意

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

基数

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

注意

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

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

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

不同实体类的利弊

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

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

在此方案中,公司有两种潜在选项可用于在订阅模型中表示客户的客户:

  1. 使用用户档案属性
  2. 使用事件实体

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

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


专业人员

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

图标

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

方法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

Adobe应用程序混合

Experience Platform提供多个现成的XDM混合,用于捕获与以下Adobe应用程序相关的数据:

  • Adobe Analytics
  • Adobe Audience Manager
  • Adobe Campaign
  • Adobe Target

例如,Adobe AnalyticsExperienceEvent模板Mixin允许您将Analytics特定字段映射到您的XDM模式。 根据您使用的Adobe应用程序,您应该在模式中使用这些Adobe提供的混音。


Adobe应用程序混合会通过使用identityMap字段自动指定默认的主要标识,该字段是系统生成的只读对象,为单个客户映射标准标识值。

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

重要

使用Adobe应用程序混音时,不应将任何其他字段标记为主标识。 如果有其他属性需要标记为标识,则需要将这些字段指定为辅助标识。

后续步骤

本文档涵盖设计Experience Platform数据模型的一般指南和最佳实践。 总结:

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

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

在此页面上