Experience Data Model (XDM)是核心框架,它通过提供用于下游Adobe Experience Platform服务的通用结构和定义来标准化客户体验数据。通过遵守XDM标准,所有客户体验数据都可以整合到一个公共表现形式中,使您能够从客户行动中获得宝贵的洞察,通过细分定义客户受众,并表达客户属性以实现个性化。
由于XDM具有极强的通用性和可自定义性,因此在设计模式时,务必遵循数据建模的最佳实践。 此文档涵盖在将客户体验数据映射到XDM时必须做出的关键决策和考虑事项。
在阅读本指南之前,请阅读XDM系统概述,了解XDM及其在Experience Platform中的作用的高级介绍。
此外,本指南专门侧重于模式设计的主要注意事项。 因此强烈建议您参考模式合成基础知识,详细说明本指南中提到的各个模式元素。
设计Experience Platform中使用的数据模型的推荐方法可概括如下:
与确定执行业务使用案例所需的适用数据源相关的步骤因组织而异。 本文档的其余部分侧重于在确定数据源后组织和构建ERD的后续步骤,但对图各组件的说明可能会指导您决定将哪个数据源迁移到Platform。
确定要引入Platform的数据源后,请创建一个高级ERD,以帮助指导将数据映射到XDM模式的过程。
以下示例代表希望将数据引入Platform的公司的简化ERD。 该图突出了应分类为XDM类的基本实体,包括客户帐户、酒店、地址和几个常见的电子商务事件。
创建ERD以标识要引入Platform的基本实体后,这些实体必须分类为用户档案、查找和事件类别:
类别 | 描述 |
---|---|
用户档案实体 | 用户档案实体表示与个人(通常是客户)相关的属性。 属于此类别的实体应由基于XDM Individual Profile类的模式表示。 |
查找实体 | 查找实体表示可与个人相关的概念,但不能直接用于识别个人。 属于此类别的实体应由基于自定义类的模式表示。 |
事件实体 | 事件实体表示与客户可以采取的操作、系统事件或您希望跟踪随时间变化的任何其他概念相关的概念。 属于此类别的实体应由基于XDM ExperienceEvent类的模式表示。 |
以下各节进一步指导您如何将实体分类到上述类别。
如果实体包含任何与单个客户相关的属性,则它很可能是用户档案实体。 客户属性的示例包括:
如果要分析实体中某些属性随时间的变化情况,最有可能是事件实体。 例如,将产品项目添加到购物车中可以作为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”是一组查找实体,它们作为数组提供在用户档案实体中。
由于没有通用的方法来适合所有用例,因此在根据基数对实体进行分类时,必须考虑每种情况的优缺点。 有关详细信息,请参阅下一节。
下表概述了一些常见的实体关系以及可从它们派生的类别:
关系 | 基数 | 实体类别 |
---|---|---|
客户和购物车结帐 | 一对多 | 单个客户可能有许多购物车结帐,这些结帐是可以随时间跟踪的事件。 因此,客户将是用户档案实体,而购物车结帐将是事件实体。 |
客户和忠诚度帐户 | 一对一 | 单个客户只能有一个忠诚度帐户,反之亦然。 由于关系是一对一的,因此客户和忠诚度帐户都代表用户档案实体。 |
客户和订阅 | 一对多 | 单个客户可能拥有许多订阅。 由于公司仅与客户的当前订阅相关,因此客户是用户档案实体,而订阅是查找实体。 |
虽然上一节提供了一些关于如何对实体分类的一般准则,但必须了解在选择一个实体类别而不是另一个实体时往往存在利弊。 以下案例研究旨在说明在这些情况下如何考虑您的选择。
公司会跟踪客户的活动订阅,其中一个客户可以拥有许多订阅。 公司还希望包括细分用例的订阅,如查找具有活动订阅的所有用户。
在此方案中,公司有两种潜在选项可用于在订阅模型中表示客户的客户:
第一种方法是将一组订阅作为用户档案实体中的客户属性。 此数组中的对象将包含category
、status
、planName
、startDate
和endDate
的字段。
专业人员
图标
第二种方法是使用事件模式来代表订阅。 这需要添加订阅ID、客户ID和发生订阅事件的时间戳,使用与第一种方法相同的订阅字段。
专业人员
图标
将实体排序为用户档案、查找和事件类别后,您可以开始将数据模型转换为XDM模式。 为便于演示,前面显示的示例数据模型已在下图中分为相应的类别:
实体已排序的类别应确定您基于其模式的XDM类。 重申:
虽然事件实体几乎始终由单独的模式来表示,但用户档案或查找类别中的实体可以在一个XDM模式中组合在一起,具体取决于其基数。
例如,由于客户实体与LoyaltyAccounts实体有一对一关系,因此客户实体的模式还可包括LoyaltyAccount
对象,以包含每个客户的相应忠诚度字段。 但是,如果关系是一对多关系,则表示“多”的实体可以由单独的模式或用户档案属性数组表示,具体取决于其复杂性。
以下各节提供有关根据您的ERD构建模式的一般指导。
模式演化规则规定,一旦模式实施,就只能对其进行无损更改。 换言之,一旦向模式添加字段且已针对该字段摄取数据,该字段便无法再删除。 因此,在您首次创建模式时,必须采用迭代建模方法,首先是简化实施,它会随着时间的推移逐步增加复杂性。
如果您不确定是否需要在模式中包含某个特定字段,则最佳做法是将其排除在外。 如果以后确定该字段是必要的,则始终可以在模式的下一次迭代中添加该字段。
在Experience Platform中,标为身份的XDM字段用于整合来自多个数据源的个别客户的信息。 虽然模式可以有多个标记为标识的字段,但必须定义单个主标识,才能启用模式以在Real-time Customer Profile中使用。 有关这些字段的用例的详细信息,请参见模式合成基础知识中标识字段一节。
在设计模式时,关系数据库表中的任何主键都可能成为主标识的候选项。 适用身份字段的其他示例包括客户电子邮件地址、电话号码、帐户ID和ECID。
Experience Platform提供多个现成的XDM混合,用于捕获与以下Adobe应用程序相关的数据:
例如,Adobe AnalyticsExperienceEvent模板Mixin允许您将Analytics特定字段映射到您的XDM模式。 根据您使用的Adobe应用程序,您应该在模式中使用这些Adobe提供的混音。
Adobe应用程序混合会通过使用identityMap
字段自动指定默认的主要标识,该字段是系统生成的只读对象,为单个客户映射标准标识值。
对于Adobe Analytics,ECID是默认主标识。 如果客户未提供ECID值,则主标识将默认为AAID。
使用Adobe应用程序混音时,不应将任何其他字段标记为主标识。 如果有其他属性需要标记为标识,则需要将这些字段指定为辅助标识。
本文档涵盖设计Experience Platform数据模型的一般指南和最佳实践。 总结:
准备就绪后,请参阅教程中的在UI中创建模式,了解有关如何创建模式、为实体分配相应类以及添加要将数据映射到的字段的分步说明。