数据建模的最佳实践

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 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. 使用用户档案属性
  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 Analytics ExperienceEvent Template Mixin允许您将Analytics特定字段映射到XDM模式。 根据您使用的Adobe应用程序,您应在模式中使用这些Adobe提供的混音。


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

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

重要

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

后续步骤

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

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

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

On this page

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now