构建用于 Customer Journey Analytics 的架构 upgrade-schema-architect
-
推荐的升级步骤（建议大多数组织使用）
确保理想实施 Customer Journey Analytics 的一系列步骤。
-
Customer Journey Analytics 升级指南（根据您组织的具体需求定制的步骤）
现有新的升级指南可用，用于动态生成适合您的组织和独特情况的升级步骤。
要从 Customer Journey Analytics 访问升级指南，请选择 工作区 选项卡，然后在左侧面板中选择升级到 Customer Journey Analytics。按照屏幕上的说明操作。
Adobe建议在实施Customer Journey Analytics数据收集时为Adobe Experience Platform创建自定义Experience Data Model (XDM)架构。 创建此架构通常在涉及任何实施更改或代码之前完成。 通过自定义架构，您可以设计简洁的、特定于组织的数据合同，而无需继承Adobe Analytics的约束或管理数千个未使用的字段。 请参阅选择您的Customer Journey Analytics架构，了解有关您的组织可用的架构类型的更多信息。
架构旨在完善您想要长期构建数据的方式。 对架构的更改成本高昂，因为它们会影响数据收集、验证和下游服务。 您可以在业务要求允许的情况下随着时间的推移添加到架构中；但是，一旦数据开始流入架构字段，就无法删除架构字段。
比较架构与数据视图
Customer Journey Analytics的数据管道包含单独的区域，可用于数据收集和数据解释。 从Adobe Analytics升级时，一个常见的错误步骤是尝试通过prop和eVar在XDM中的行为重新创建prop和eVar。 请改用Web SDK来收集数据，并使用数据视图来确定如何在报表中解释该数据。
比较架构与Adobe Analytics数据收集
Customer Journey Analytics使用的Experience Data Model比大多数其他Analytics解决方案(包括Adobe Analytics)具有更大的灵活性。 建立一个稳固的架构是贵组织避免执行其他Analytics产品中存在的限制的机会。
eVar1-eVar250， prop1-prop75)进行设计search.term、content.category、user.membershipTier）并一致地重复使用它们使用通用属性建立模式
当您标准化出现在许多事件中的一组可重用属性时，就有可能实现跨渠道的统一架构。 一些示例包括：
- 体验上下文：站点/应用程序名称、环境、区域设置、渠道、品牌
- 历程上下文：营销活动标识符，引用上下文，试验标识符
- 用户状态：登录状态、成员层、帐户类型
- 交互详细信息：交互名称/类型、UI区域、元素标签、错误类别
关键是要标准化字段代表的含义，而不管渠道如何。 避免跨渠道以不同的方式建模相同的概念，除非它们真正表示不同的概念。 例如，可能明智的做法是避免为Web营销活动ID和移动营销活动ID设置单独的架构字段。 单独的架构字段使得建立广告支出数据的跨渠道回报率更加困难。 如果报表中需要区分，您可以按渠道进行细分或连接多个字段以提供该区分。 同一架构字段可用于任意数量的维度或量度。
在保持单个架构策略的同时支持多个渠道的实用方法是使用 核心+扩展 模式：
- 核心：广泛适用于各个渠道和团队的字段
- 扩展：特定于渠道或域的字段组，这些字段组仅在需要时适用（Web交互、商务、移动生命周期、服务器端详细信息）
此模式支持单一组织架构策略，不会强制每个团队填充不适用于其渠道的字段。
首选适合的标准字段组
Adobe建议在符合您需求的地方使用标准化的字段组，并使用自定义字段进行扩展，以了解特定于组织的概念。
标准字段组通常可帮助您：
- 使用已知字段语义减少歧义
- 更轻松地跨团队校准
- 支持跨Adobe Experience Platform应用程序的互操作性
自定义字段适用于以下情况：
- 您的组织具有无法完全映射到标准字段的概念
- 您需要其他属性以满足报告、治理或激活要求
- 您希望表示特定于业务的分类（例如，内部内容类别）
确定“量度含义”的存留位置
在Adobe Analytics中，许多团队将events变量视为量度的去向。 在Customer Journey Analytics中，您可以通过多种方式为指标建模，具体取决于您需要计数的内容以及您希望如何解释这些内容。
在构建架构时，要坚持事实。 例如，error.type = "validation"，user.isLoggedIn = true，checkout.step = "shipping"。 将数据视图中的量度定义为这些事实的计数和过滤计数。 例如：
-
checkout.step（枚举/字符串）可以为：- “结帐：到达送货步骤”（此处为
checkout.step == "shipping"计数） - “结帐：已到达付款步骤”
- “结帐：到达送货步骤”（此处为
-
error.type（枚举/字符串）可以为：- “验证错误”
- “授权错误”
-
user.isLoggedIn（布尔值）可以为：- “经过身份验证的会话”
- "经过身份验证的转化"
在过渡期间保持与Adobe Analytics的等同性，而不受架构包袱
某些组织在升级到Customer Journey Analytics时需要继续Adobe Analytics报表。 您可以使用以下方法维护对等性，而无需将特定于Analytics的工件引入长期架构设计：
- 使用Adobe Analytics可识别和自动映射的XDM字段路径：当您通过Edge Network将可识别的XDM字段发送到Adobe Analytics时，这些字段会自动映射，无需额外配置。
- 对特定于组织的概念使用自定义XDM字段：任何未自动映射到Analytics变量的XDM字段在Adobe Analytics中作为上下文数据变量转发。
- 使用Adobe Analytics处理规则将这些上下文数据变量映射到prop/eVars： 处理规则最终使您可以将任何自定义XDM字段映射到任何eVar或prop。 此概念支持Adobe Analytics中的奇偶校验报表，同时保持架构干净并以Customer Journey Analytics为中心。
确定利益相关者并确定所有权
如果同意并维护字段含义，则架构设计成功。 虽然组织结构不同，但通常由以下角色参与：
- Analytics管理员/分析员：定义报告问题，验证字段表示有意义的概念，并审查数据视图中的分析语义。
- 开发人员/实施所有者：确保可以使用Web SDK可靠地收集字段，并与数据层/应用程序检测一致。
- 数据架构师/工程师：确保架构一致性、跨域重用以及与下游服务的兼容性。
- 隐私/治理利益相关者：审查数据最小化、同意期望和数据使用约束。
为架构更改定义一个清除所有者。 具有严格变更控制的稳定模式可以防止下游中断并减少返工。 考虑使用跟踪治理工作流或工具使请求民主化并管理一段时间的更改控制。
隐私和治理注意事项
架构设计应根据贵组织的隐私政策反映隐私和治理期望。 在架构架构时，请考虑以下几点：
- 仅收集支持定义的用例所需的内容。
- 确保在收集策略中反映同意和数据使用要求。 有关详细信息，请参阅使用Web SDK处理客户同意数据。
- 考虑如何在Adobe Experience Platform治理工具中标记和控制敏感字段。 有关详细信息，请参阅Adobe Customer Journey Analytics和数据管理。
后续步骤
一旦您建立并同意架构架构，就可以开始在Adobe Experience Platform中创建它。 有关详细信息，请参阅创建要与Customer Journey Analytics一起使用的自定义架构。