从 Adobe Analytics 迁移到 Customer Journey Analytics (CJA) 需要在数据收集、平台设置和集成方面进行仔细准备。本指南概述了在 Adobe Experience Platform 中确保顺利过渡并充分发挥 CJA 潜力的关键步骤。
从 Adobe Analytics (AA) 迁移到 Customer Journey Analytics (CJA) 是一项复杂但有价值的转型，它使企业能够在 Adobe Experience Platform (AEP) 中利用更高级的分析功能。迁移前流程主要取决于您的数据收集方式、当前 Adobe Analytics 设置和现有集成。
本指南探讨了三个关键考虑事项，帮助确保迁移规划流程（我们称之为 CJA 准备阶段）顺利开展。
1.了解数据收集要求
数据质量的重要性
“输入决定输出。”确保高质量的数据收集至关重要，因为它会构成分析的基础。在迁移之前，必须对您的跟踪实施进行彻底审查，以确保准确性和一致性。
Web SDK 与 AppMeasurement
迁移的最关键环节之一是评估当前的数据收集设置：
- 如果您的平台（Adobe Tags 属性）已在 Web SDK 上运行，则迁移将更加简单。
- 如果您的平台仍使用 AppMeasurement，则需要额外的时间来进行调整，因为 Web SDK 引入了几个新概念，例如体验数据模型 (XDM) 架构、身份标识和数据集。虽然 AppMeasurement 在技术上可以与 AEP 结合使用，但随着时间的推移，它会增加复杂性。我们强烈建议仅使用 Web SDK。
审查数据层和标记管理系统
迁移带来了重新审视和优化数据收集方法的机会：
- 跨不同平台统一和标准化数据层。选择正确的数据层设置。您可能需要将数据层从传统的客户体验数字数据层 (CEDDL) 更新为事件驱动型 (EDDL) 或混合型方案。
- 确保 Adobe Tags (Launch) 或任何其他标记管理系统已得到优化，可以满足 AEP/CJA 的要求。
- 查看解决方案设计参考 (SDR) 并调整数据收集策略以满足 CJA 要求。
方法
幸运的是，我们已将所有平台迁移到 Web SDK，并且我们熟悉 AEP 概念。此外，我们的数据层和标记管理设置在所有平台上实现了标准化（我们使用 CEDDL 和 EDDL 相结合的混合数据层方案）。尽管如此，我们仍对启动属性和 SDR 进行了全面审核。我们确保始终如一地以高数据质量标准跟踪关键属性，如页面和事件数据。在 SDR 中，我们批判性地评估了每个属性 – 质疑其必要性并评估如何使用 CJA 的新功能（组件配置可能性，如派生字段）对其进行改进。
2.评估您的 Adobe Analytics 设置
您当前的 Adobe Analytics 环境对于迁移的复杂程度有着重要影响。关键考虑事项包括：
数据迁移策略
将数据从 Adobe Analytics 迁移到 CJA 时，必须确定应迁移哪些数据以及适当的时段（回填长度）。利用这个机会来优化您的分析设置和跟踪计划，确保只包含相关数据，而不是转移所有内容。
默认情况下，Adobe 允许将 13 个月的历史数据导入至 Customer Journey Analytics。但是，根据您的业务需求，可能需要设置较长的数据保留期。例如：
- 如果您的业务有季节性高峰期（例如，9 月至 11 月），并且以三个月为周期进行分析，则可能需要 15 个月的历史数据。这一考虑事项不仅对分析工作有着重要影响，对于许可要求也很重要。
- 更长的数据保留期有助于更好地进行年度同期比较和趋势分析，但这也会增加数据量、存储成本和处理复杂性。仔细评估您要通过 CJA 涵盖的用例。
平衡数据保留需求和存储考虑事项对于优化 CJA 设置至关重要。
选择数据迁移方法
决定如何将您的数据转移到 CJA 是另一个关键步骤。主要的方法有两种：
- Adobe Analytics 源连接器：用于与 CJA 集成的更简单、自动化程度更高的方法。
- 数据馈送：更灵活但更复杂的方法，允许对数据转移进行更深入的自定义。
选择正确的方法取决于您的具体数据需求和基础架构。有关数据迁移方面的经验教训，请参阅本文。
组件迁移
这项转移工作不是要将组件从 AA 逐个对应迁移到 CJA，而是代表着一个重新开始的机会。随着时间的推移，Adobe Analytics 实施通常会积累冗余、过时或文档记录不完善的组件。
方法
我们没有选择使用组件迁移工具，而是构建了一套精简的新设置。为了确保平稳过渡，一项利益相关者分析确定了哪些仪表板是必不可少的。这样将总数减少了 50% 以上，并消除了重复或闲置的报告和组件。我们审查并优化了区段、量度和其他组件，以防止遗留元素被带入新设置。
对于数据迁移，我们选择使用数据馈送，而不是存在限制的 Adobe 源连接器（在我们新的 CJA 设置中，我们不需要任何 eVar 和 prop）。我们并没有将旧系的复杂设置照搬到新系统中，而是将迁移视为清理和优化的机会，最终建立起一个更高效的分析环境，这也增强了自助分析能力。
3.自定义集成和数据转换
这通常是迁移中最具挑战性的部分。许多组织都将 Adobe Analytics 与第三方系统集成，例如：
- 数据仓库（通过 API、FTP 或自定义管道）
- 邮件系统、营销自动化工具和推荐系统
- CRM 和个性化引擎
由于 CJA 在 AEP 中运行（并且对于导出有一些限制），因此必须使用可用的选项重新配置这些集成，包括：
- AEP 数据摄取 API
- Adobe 构建的连接器和自定义连接器
- 用于转换和路由数据的数据准备管道
数据转换挑战
数据转换是迁移过程中的一项主要挑战。虽然标准连接器提供了一定程度的转换能力，但在使用基于 API 的方法（例如查询服务）将面向对象的 AEP 数据转换为关系型结构（例如表、视图或数据湖）时，需要对此类数据进行谨慎处理。正确构建和优化这些流程对于确保不同平台上的数据可用性至关重要。
方法
我们的数据导入和导出设置相对简单，不过我们确实将一些数据转移到了内部数据湖中。为此，我们依赖通过 FTP 和数据仓库 API 进行的每日数据仓库导出。由于 CJA 当前可用于此类导出的选项有限（例如，支持 10 个维度和 10 个量度的完整表导出），因此我们选择以数据集为单位从 AEP 导出数据。
根据我们的需要，将查询服务 API 与 AEPP结合使用被证明是最有效的方法。这允许我们从内部数据湖访问数据集，并根据需要保留这些数据集。但是，由于数据是源自于 AEP 而不是 CJA，因此它缺少持久属性，例如最后点击归因或基于访问的量度。为了弥合这一差距，我们使用 SQL 和 Python 重新创建这些元素。幸运的是，Adobe 为访问标识提供了预定义函数，而标准 SQL 窗口函数使得在 CJA 中重新构建所有可用内容成为可能。
提前规划数据管道至关重要，因为修改这些流程需要内部 IT 资源。所涉及的导入/导出操作越多，复杂性就越高，从而增加了维护工作量和资源需求。尽量精简流程有助于在确保数据一致性的同时最大限度地减少开销。
最终想法
从 Adobe Analytics 迁移到 Customer Journey Analytics 并不是一个简单的提升和转移过程，它需要周到的规划、数据优化和战略决策。通过审查数据收集、优化组件并仔细管理集成，企业可以充分发挥 CJA 的潜力，同时避免不必要的复杂性。
成功的迁移为在 AEP 中构建更强大、更灵活且经得起未来考验的分析环境奠定了基础。