客户历程通常跨越多个数据源、渠道和阶段，因此非常复杂。这些最佳实践为简化历程设计和执行提供了清晰的框架，从而确保营销团队能够高效运营，避免工作负担过重。
简介
每个客户历程都是个性化的，会随着每个人的需求和行为而不断演变。如果执行得当，我们的营销内容能精准触达客户所在位置，同时推动他们完成各个里程碑，从而深化参与。通过倾听客户信号，每个人都能按照自己的步调在完成整个历程，每个接触点都显得个性化且契合其所处的独特背景。
鉴于这种复杂性，相较于传统营销活动，多步历程可能会以从未有过的方式给营销工作和营销运营团队带来挑战。
此框架有助于管理这种复杂性。它涵盖了一个有效的历程策略的关键组成部分，包括：
- 数据管理的最佳实践
- 将历程细分为小型子历程
- 简化标记和命名惯例的提示
通过减少“移动部件”简化数据管理
简洁的数据是良好客户体验的助推剂。数据管理实践越简化，就越能专注于优化构成整体客户体验的历程。历程如同机器，有着类似的特点：维护的复杂性会随着移动部件的数量而增加。要进行简化，需尽可能减少移动部件的数量。
考虑两个关键部分以降低复杂性。第一，用于将数据导入 Experience Cloud 数据湖并将数据存储在其中的数据集。第二，需要启用，以便能够向实时客户轮廓提供数据的数据集。虽然利用这些功能有很多好处，但能否成功利用它们取决于是否围绕以下考虑事项进行仔细规划：
- 来自外部数据库的数据必须与相应的警报同步，以便在发生摄取失败时及时识别。
- 除了适用于进入 Experience Platform 的所有数据的数据摄取护栏之外，还需要考虑轮廓护栏。
- 必须仔细规划源系统中的身份标识数据及其完整性，以便生成健康的身份标识图。
- 数据湖利用率（包括总体存储消耗量、表关系和可寻址轮廓）必须被纳入任何摄取前评估。
从较高层面看，减少数据管理中的“移动部件”的最佳方法是仔细考虑您利用的每个数据源的用例。由此，您可以确定在 Experience Platform 中摄取和管理该数据的最简单方法，同时仍可启用用例所需的所有功能。
让我们比较一下在客户历程中摄取和利用数据的选项。
选项 1 – 通过 Journey Optimizer 中的自定义操作访问外部数据源
此方法允许您直接连接到外部数据源，而无需将数据保留在 Experience Platform 数据湖中。
要利用此方法，请考虑关于用例的以下问题：
- 在客户历程之外，您需要访问的数据是否有用？如果没用，则可能不需要在数据湖中创建数据集。
- 是否能够通过外部系统可访问的 API 端点对您的数据源进行访问？如果是，响应是否包含个性化和启用历程所需的属性？
选项 2 – 将数据摄取到数据湖中的不支持轮廓的数据集
此方法允许您根据上下文事件数据触发历程并进行个性化设置，而无需让数据源直接向实时客户轮廓提供数据。
要利用此方法，请考虑关于用例的以下问题：
- 记录是否包含可用于访问存储在 Experience Platform 轮廓存储中的轮廓的身份标识字段？这是您的历程访问轮廓并通过 Journey Optimizer 向其投放营销内容所必需的。
- 这些数据是否有助于创建可以在 Journey Optimizer 之外的渠道中利用的受众？若为否，则可能不需要为轮廓启用数据集。
- 数据是否包含多个身份标识，这些身份标识可能有助于拼接其他不同的轮廓片段，从而创建更丰富的数据集？若为否，它可能无法为更丰富的客户身份标识图提供支持。
选项 3 – 将数据摄取到数据湖中的支持轮廓的数据集
此方法允许您创建受众、身份标识图和轮廓，然后在 Journey Optimizer 中的多个历程以及任何其他 RT-CDP 目标中利用这些组件。
- 这些数据是否有助于创建可以在 Journey Optimizer 之外的渠道中利用的受众？若为是，通过使用支持轮廓的数据集，您可以在受众定义中使用此数据。
- 数据是否包含多个身份标识，这些身份标识可能有助于拼接其他不同的轮廓片段，从而创建更丰富的数据集？若为是，通过使用支持轮廓的数据集，可以将来自其他数据源的分散轮廓片段拼接在一起，从而获得更丰富、更强大的数据集。
拆解您的客户历程
在历程中，营销渠道引导客户完成对整体客户体验有着重要影响的里程碑。客户可能按照自己的步调完成这些里程碑，他们遇到到的营销接触点会有所不同，这取决于他们是否已独自完成某些里程碑。在 Journey Optimizer 中，可以使用“等待”活动控制营销接触点之间的时间，也可以通过“拆分”活动管理个性化设置的整体编排。
即便是简单的客户历程，对于负责构建和管理它们的营销和营销运营团队而言，也可能很快变得难以承受。
在本示例中，我们使用两个营销渠道引导客户完成三个里程碑。历程策略很简单：发送初始通信，如果客户在该时间段内未完成预期的里程碑，则在几天后发送提醒。
在此历程中，客户通过加入忠诚度项目来进入。然后，我们鼓励他们下载移动应用程序，接着开展营销工作，以引导他们完成第一和第二笔忠诚度交易。
所描述的历程示意图如下：
虽然此历程可能看似简单，但在示例中，客户可以选择的唯一路径数量已经超过 20 个（超过这一数量后就变得难以统计）。一个客户可能仅接收前两条移动应用程序通信，而另一个客户可能接收历程中的每条通信。第三个客户可能完成整个历程，但仅接收与忠诚度交易相关的通信。
在单个历程中可能存在的各种各样的体验会造成一定程度的复杂性，使得负责构建和管理历程的团队的工作效率下滑。随着引入更多营销渠道或接触点，这种复杂性会呈指数级增加。
为了帮助管理这种复杂性，可以使用以下技术将历程分成更小的、更易于管理的子历程。
步骤 1 – 可视化端到端历程
一旦直观地呈现完整的端到端客户历程，就可以清楚地识别历程中的高级阶段和里程碑。
阶段 1：下载移动应用程序
阶段 2：处理第一个交易
阶段 3：处理第二个交易
步骤 2 – 在历程图中添加阶段标注
使用明确标记的阶段，将每个阶段分离为单独的“子历程”。清晰地标记随这些子历程一起推进的业务目标可能也很有帮助。到了团队开始着手具体实施的最终环节时，这将进一步促进协调一致性。
步骤 3 – 通过单独的“子历程”构建更大的端到端历程
将大型客户历程分解为较小的子历程后，重点是将这些高层级图表转化为更加技术化的要求和随后可以在 Journey Optimizer 中构建的设计。
通过这种方法，开发了三个相对简单的客户历程。然后，这些较小的历程组合起来，便构成了最初所展示的更庞大、更复杂的历程。
使用此方法，可以创建复杂的客户历程，并降低引入不必要复杂性的风险。
利用标签来简化历程维护
一旦历程开始，工作就不能停止。必须监控投放和性能，并且作为持续优化的一部分，应创建改进的新版本。这通常需要跨同时运行的多个历程以及不同的业务部门或营销团队完成。
这种情况下，在某个组织的 Journey Optimizer 实例中，能够在全部实时历程中快速浏览和找到历程就显得非常重要。
实现此目标的常见方法是使用命名惯例。尽管创建这些命名惯例时通常考虑周全且初衷良好，但有时它们可能会增加而非减少客户历程管理的复杂性。
以下示例说明这种情况是如何发生的。
在为历程设置标签时，典型的命名惯例使用定义好的结构。该结构中的许多元素包含的元数据超出了正在创建的客户体验的范围。这里有一个命名惯例结构的示例，它旨在方便根据选定的元数据识别历程，其形式可能如下所示：
<营销利益相关者团队> - <营销目标> - <营销活动/历程名称> - <阶段/里程碑名称> - <上市日期>
正确应用时，采用此惯例的历程可能具有以下名称：
生命周期营销 – 教育 – 客户加入 V2 – 应用程序教育 – 2025 年第 3 季度
如果是由单一团队成员管理和标记所有历程，该惯例很可能会被成功应用。但是，随着工作在多个团队成员或多个团队之间扩展开来，准确无误地应用惯例的可能性会显着降低。
以下是一个 Journey Optimizer 实例的示意图，其中有许多历程同时运行，均采用此命名惯例：
尽管这个方法被普遍采用，但还有更好的方法。
Journey Optimizer 中的标记和标记类别可帮助您完成与命名惯例相关的许多既定目标，而不会像上述示例中那样复杂。团队可以过滤这些标记和类别，而历程名称可以更明确地聚焦于要推动的客户里程碑。
利用这些功能，按照以下步骤将您的命名惯例方法转换为更简单的方法。
步骤 1
让平台管理员为您使用的任何属性（用于组织历程）创建标记类别。那些您的团队可能会使用更复杂的命名惯例实施的附加元数据很适合用作标记类别。
步骤 2 – 在每个类别下创建一些可以在历程创建过程中应用的标记。这些标签值应代表能够描述该类别下可能存在的所有历程的元数据。
步骤 3 – 启动新历程时，请确保每个已建立的标记和标记类别均正确应用。每个历程可能会有多个已分类的标记。
步骤 4 – 使用历程名称指示由历程驱动的里程碑。现在，全面审视实时历程是一项轻松得多的任务。此外，我们还未丧失基于元数据找到历程的能力，这些元数据是先前通过命名惯例存储在历程名称中的。我们可以对这些标记和标记类别进行过滤，以便执行此操作。
结论
尽管客户历程为营销团队提供了运用技术来打造丰富而个性化的客户体验的绝佳机遇，但负责构建这些历程的团队在此过程中也可能疲于应对其复杂性。为避免出现这种结果，请注意下列需要简化的方面：
- 在您的数据管理实践中，审视每个数据源的用例，以尽可能多地移除“移动部件”。
- 将较大的客户历程分解为较小的“小块”子历程，这些历程可以被组合起来以构建出完整历程。
- 为了有助于开展日常维护与优化，请探索使用标签和标签分类，相对于复杂的命名惯例是一种很好的改进方案。