**终止支持通知：** AWS 将于 2026 年 10 月 30 日终止对亚马逊 Pinpoint 的支持。2026 年 10 月 30 日之后，您将不再能够访问 Amazon Pinpoint 控制台或 Amazon Pinpoint 资源（端点、分段、活动、旅程和分析）。有关更多信息，请参阅 [Amazon Pinpoint 终止支持](https://docs.aws.amazon.com/console/pinpoint/migration-guide)。**注意：** APIs 与短信相关、语音、移动推送、OTP 和电话号码验证不受此更改的影响，并受 AWS 最终用户消息的支持。 本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 有关旅程的提示和最佳实践 虽然旅程很灵活且完全可自定义，但有一些基本策略和实践可以帮助您规划、设计和管理任何旅程。要成功设计和管理旅程，请考虑以下提示和最佳实践。 **Topics** + [范围和设置](#journeys-best-practices-settings) + [客户细分](#journeys-best-practices-segments) + [活动](#journeys-best-practices-activities) + [电子邮件](#journeys-best-practices-email) + [审核并测试](#journeys-best-practices-review-test) + [Analytics](#journeys-best-practices-analytics) + [生命周期管理](#journeys-best-practices-lifecycle) ## 范围和设置 由于旅程可以执行各种不同但相关的任务，因此最好为旅程创建一个明确定义的场景。此外，您应该选择支持您的场景和目标的旅程设置。通过使用旅程设置，您可以建立约束，以确定旅程可以吸引参与者的时间、数量和频率。 定义场景时，请考虑将其范围限制为客户体验的一个较小方面。虽然 Amazon Pinpoint 支持具有大量工作流的大型旅程，但如果您将旅程设计为一系列相关旅程的一部分，您将有更多机会来监控、优化和管理客户体验。 例如，您可以设计一个旅程来重点欢迎新客户并在他们作为客户的前七天内为他们提供推荐的最初步骤。然后，根据每个客户在第一个旅程中的行为，您可以将他们添加到适合其初始参与度的后续旅程中。一个后续旅程可能为第一个旅程中高度参与的客户提供后续步骤。另一个后续旅程可能会向第一个旅程中参与较少的客户推销不同的产品或服务。通过创建一系列较小范围的旅程，您可以在整个客户生命周期内不断优化和管理客户体验。 定义场景后，选择支持场景目标的旅程设置。这些设置定义旅程的任何部分可以吸引参与者的时间、数量和频率。要选择这些设置，请创建或打开旅程。然后从**操作**菜单中选择**设置**，并展开**高级设置**部分。 一些关键目标和相关设置如下： **存储并使用参与者的本地时区** 要优化参与者在具有预定开始和结束时间的旅程中的参与度，请将旅程配置为使用每个参与者的本地时区。这有助于确保旅程活动在参与者最有可能参与这些活动的时间进行。 但请注意，此设置的有用性取决于您是否在参与者的端点定义中存储了本地时区值。如果您使用此设置，而参与者的端点定义未指定时区，则 Amazon Pinpoint 不会将该参与者包含在旅程中。若要避免此问题，请使用 `Demographic.Timezone` 属性来存储参与者的时区信息。这是 Amazon Pinpoint 提供的标准属性。 **解决安静时间冲突** 如果您为活动配置的发送消息的时间与旅程的安静时间设置冲突，则 Amazon Pinpoint 不会发送该消息。安静时间结束后，就会发送新消息。如果您选择在安静时间结束后继续发送消息，则在安静时间内保留的任何消息也将发送。否则，这些被保留的消息将被丢弃。 **时区估计** 时区估计可帮助您根据 `Endpoint.Location.Country` 并依靠所选择的估计方法（`Endpoint.Address` 和/或 `Endpoint.Location.PostalCode`）来估计端点时区。当配置了*安静时间* 以及当旅程根据本地时区发送消息时，使用端点时区来避免在一天中的不适当时间发送消息。时区估计仅在没有 `Demographic.Timezone` 属性值的端点上执行。 AWS GovCloud（美国西部）不支持时区估计 如果旅程包含一个具有多个时区的端点： + 当**收件人的本地时区**启用时，旅程将根据端点的*最晚* 时区*开始* 发送消息。 + 当**收件人的本地时区**启用时，旅程将在所有消息已发送或根据端点的*最早* 时区*停止* 发送消息。 + 当**安静时间**启用时，在任何时区的安静时间内，旅程都不会向端点发送消息。 只有当旅程中的所有端点都被允许根据所有已配置的旅程发送规则接收消息时，旅程才会发送消息。 **旅程具有在多个时区的端点并具有*安静时间*** 例如，如果您将旅程的*安静时间*设置在 20:00（晚上 8:00）到 08:00（早上 8:00）之间，并且在 UTC-8 `America/Los_Angeles` 和 UTC-5 `America/New_York` 中有端点，则旅程将在 08:00 `America/Los_Angeles`（11:00 `America/New_York`）开始发送消息，并在 17:00 `America/Los_Angeles`（20:00 `America/New_York`）停止发送消息。 **限制参与者可以接收的消息数量** 为了帮助确保参与者不会从旅程或项目收到过多消息，请限制在 24 小时内可发送给参与者的消息数量。如果旅程使用活动或其他旅程也使用的客户细分，这尤其有用。您还可以创建并使用明确仅供特定旅程使用的客户细分。 **优化可发送的消息数量** 如果旅程具有大量参与者，并且发送大量消息，请考虑 Amazon Pinpoint 处理和发送所有这些消息所需的时间量。 例如，假设您的旅程活动向 1,000,000 个参与者发送消息，而您的 Amazon Pinpoint 账户的最大发送速率为每秒 200 条消息。那么，有些参与者在活动开始大约 80 分钟后才收到消息。如果旅程包括紧接电子邮件活动的等待活动，这尤其相关。如果直到等待活动结束，Amazon Pinpoint 尚未发送完所有消息，则参与者可能被移到等待活动之后的活动，然后才可能收到消息。 为了减少此风险，请考虑增加旅程每秒可发送的最大消息数量，并可以将其提高到您账户的最大发送速率。同时考虑[提升您账户的发送限额](channels-email-manage-limits.md)。 **限制参与者可以进入旅程的次数** 根据旅程的性质和设计，限制单个参与者可以进入同一旅程的次数。如果您未设置此限制，则参与者可以进入旅程，完成旅程中的几个活动，到达结束活动，然后重新启动旅程。您可能希望让每个参与者仅启动并完成旅程一次。 请注意，如果参与者已是旅程中的活跃参与者，则 Amazon Pinpoint 不允许该参与者进入旅程。例如，如果参与者启动旅程而您随后更新了参与者的端点定义，并且您的更新方式会影响到参与者是否包含在某个客户细分中（基于客户细分标准）或包含在该旅程中（基于活动条件），则 Amazon Pinpoint 不会将该参与者添加为新参与者。 **最大限度地提高参与者启动旅程的机会** 旅程进入活动是旅程中的第一个活动，它决定将新参与者添加到旅程中的频率。由于新客户或现有客户可能随时成为参与者，因此最好将进入活动配置为频繁将新成员添加到客户细分中。您还可以将客户细分配置为基于特定用户属性或事件自动添加新参与者。有关如何以这些方式配置客户细分的示例，请参阅 AWS 消息收发和目标博客上的[在 Amazon Pinpoint 中构建第一个旅程](https://aws.amazon.com/blogs/messaging-and-targeting/building-your-first-journey-in-amazon-pinpoint/)。 ## 客户细分 客户细分很关键。它们决定谁可以参与整个旅程和特定旅程活动。当您为旅程创建客户细分时，请考虑以下最佳实践： **创建专用测试客户细分** 如果您有一组负责测试旅程和消息的常规人员，请创建一个仅包含这些人员的端点的客户细分。然后，您可以将该客户细分用作一致的测试框架，特别是如果您使用 Amazon Pinpoint 提供的旅程测试功能。有关如何构建此客户细分的提示，请参阅[审查和测试旅程](journeys-review-test.md)。 **使用多个客户细分** 虽然您只能为旅程进入活动选择一个客户细分，但该客户细分可以包括多个较小的客户细分。以后，您可以在旅程中使用多变量拆分活动，以根据客户细分成员资格将参与者划分到单独的组中。这种方法可以帮助您为每个参与者提供更加量身定制的体验。它还可以帮助减少电子邮件活动的处理时间，因为这些活动将向更小、更有针对性的受众发送消息。 根据参与者明确执行或不执行的操作对参与者进行客户细分也是一个好主意。您可以通过使用拆分活动来完成此操作。例如，您可以使用是/否拆分活动：如果参与者点击消息中的链接，则沿*是* 路径发送参与者；如果参与者没有点击消息中的链接，则沿*否* 路径发送参与者。没有采取操作可以成为通过跟进活动重新吸引参与者的机会。 **不要删除客户细分和端点** 我们鼓励您保留属于活动旅程的客户细分。如果您删除活动旅程正在使用的客户细分，则该旅程可能会失败并停止运行。如果旅程继续运行，则可能会提前从旅程中删除属于该客户细分的任何参与者。此外，在这些参与者参与的最后一个活动的分析数据中，会将这些参与者报告为“已丢弃”。这会削弱分析数据的用处，因为您将无法区分独立离开旅程的参与者和您移除的参与者。 **利用自定义属性** 要更轻松地确定旅程参与者并将其添加到客户细分中，请考虑在应用程序创建或更新端点时向端点添加特定于旅程的自定义属性。然后，您可以使用此属性将用户或端点确定为应该参与旅程的人员。 ## 活动 活动是任何旅程的构建基块。因此，当您为每个活动选择类型和设置以及活动之间的关系时，请考虑以下准则： **优化进入活动** 进入活动是旅程中的第一个活动，它决定将新参与者添加到旅程中的频率。您可以根据活动来添加参与者（例如，添加下载特定音乐的用户），也可以从现有客户细分添加参与者。由于新客户或现有客户可能随时成为参与者，因此最好将进入活动配置为频繁更新（将参与者添加到）相关客户细分。通过这样做，可最大限度地提高参与者启动旅程的机会。 **为客户细分和参与者数据的更改做好准备** 活动对客户细分条件的评估基于客户细分中每个参与者（端点）的最新数据，并且此数据可能会随着时间的推移而更改。例如，参与者在启动活动时最喜欢的食物可能是比萨饼。该参与者随后可以将其偏好更改为热狗。如果发生这种情况，后续活动将根据参与者对热狗（而不是比萨饼）的偏好评估参与者。为这类更改做好准备的一种方法是使用拆分活动来预测更改并沿适当路径发送参与者。 如果端点是 `ACTIVE`，Amazon Pinpoint 将通过市场活动和旅程发送消息。如果 `ACTIVE` 端点进入旅程并在完成旅程之前变成 `INACTIVE`，Amazon Pinpoint 将继续向该端点发送消息。 **利用*否则* 路径** 多变量拆分活动可以包含多达四个路径（每个路径都有自己的条件）以及*否则* 路径。*否则*路径适用于不符合其他路径的任何条件的参与者。因此，它提供了一个极好的机会来处理您在设计旅程时可能没有考虑到的意外或异常情况。 **考虑接收事件数据的延迟** 某些事件数据（如*电子邮件打开*）基于我们从参与者的电子邮件提供商那里收到的信息。一些提供商会立即向我们发送此类信息，而另一些提供商可能不会这么快地向我们发送信息。这些延迟会影响参与者的体验。当 Amazon Pinpoint 将事件作为活动条件进行评估时，如果没有参与者的任何事件数据，它会将参与者移至*否* 路径。为了减少此风险，请在紧接电子邮件活动的另一项活动的评估计划中增加缓冲时间。 **避免连续的电子邮件活动** 建议您在两个或多个电子邮件活动之间插入等待或其他类型的活动。这有助于解释 Amazon Pinpoint 处理和发送消息所需的时间，以及参与者接收消息的任何延迟。 **使用重新进入间隔** 设置端点重新进入旅程的时间间隔。通过设置重新进入间隔，您可以隔开用户收到您的消息的时间，这将有助于提高用户参与度，降低您的消息被当作垃圾消息处理的可能性。 ## 电子邮件 除了[发送电子邮件的一般提示和最佳实践](channels-email-best-practices.md)外，请考虑在创建旅程之前执行以下操作： **创建专用的“发件人”地址** 考虑对您从旅程发送的所有消息使用专用的电子邮件地址或域。这为参与者从旅程收到的所有消息提供了一致的体验。它还允许每个参与者调整自己的电子邮件应用程序设置，以确保旅程的所有消息都能到达他们的收件箱。此外，如果您订阅了[送达率控制面板](channels-email-deliverability-dashboard.md)，使用专用地址或域可以精简流程，让您更轻松地访问特定旅程的高级分析数据。要了解如何设置用于发送消息的专用地址或域，请参阅[验证电子邮件身份](channels-email-manage-verify.md)。 **验证是否正确设置了电子邮件渠道** 在发布旅程之前，请确保您的 Amazon Pinpoint 账户具有[电子邮件的生产访问权限](channels-email-setup-production-access.md)。如果没有，则您的账户处于沙盒环境中，这意味着参与者可能不会收到来自旅程的消息。（在沙盒环境中，您只能发送有限数量的消息，并且只能向特定电子邮件地址发送消息。） 此外，请确保您账户的发送限额和发送速率可以支持您计划从旅程发送的消息数量。要查看您的账户的发送限额和速率，您可以使用 Amazon Pinpoint 控制台上的**电子邮件设置**页面。 **设计相关消息模板的集合** 在规划流程的早期阶段，最好为您希望包括在旅程中的每个电子邮件活动设计并创建消息模板。这样做可以确保所有消息设计一致。这还可以确保每个消息都特定于旅程的相应阶段并针对该阶段进行优化。例如，在欢迎新客户的旅程中，您可能具有三个电子邮件模板。有一个模板包含介绍性信息，另一个模板为点击第一个消息中的链接的用户提供中间信息，第三个模板为未点击第一个消息中的链接的用户提供修订的介绍性信息。 ## 审核并测试 Amazon Pinpoint 包括一个审查功能，用于检查旅程中的配置错误并提醒您。它还简化了查找并修复任何错误的过程。要查找存在错误的活动或设置，请点击错误描述。 要修复错误，请按照**审查您的旅程**窗格中提供的建议操作。我们鼓励您在发布旅程之前使用此功能审核并修复错误。作为最佳实践，我们还鼓励您在发布旅程之前多次完成此审核流程。 Amazon Pinpoint 还包括一个简化测试过程的测试功能。完成旅程的审核流程后，您可以使用此功能通过旅程发送一组测试参与者。 为了确保只有测试参与者才能进入旅程，您可以通过此特征来创建并使用专用测试客户细分。要加快测试速度，您可以配置此特征以减少或消除某项活动的等待时间和活动之间的等待时间。我们强烈建议您在发布旅程之前使用此功能测试旅程的所有方面，包括旅程发送的每个消息。 要了解有关审核并测试旅程的更多信息，请参阅[审查和测试旅程](journeys-review-test.md)。 ## Analytics 发布旅程后，Amazon Pinpoint 会自动开始收集并聚合适用于整个旅程和各个旅程活动的多种标准指标的分析数据。我们强烈建议您定期并频繁地查看这些指标。 此外，这些指标提供了有关要解决的问题的关键见解，例如在 Amazon Pinpoint 尝试评估或执行活动时可能发生的失败和错误。总体而言，这些指标可以帮助您确定旅程中什么运行良好或不好，从而帮助您以后设计更有效的旅程。有关可用指标以及如何查看这些指标的详细信息，请参阅[查看旅程指标](journeys-metrics.md)。 Amazon Pinpoint 可以将您的分析数据自动存储 90 天。根据旅程的预计持续时间或您组织的长期存储和报告需求，您可能希望将基础事件数据存储 90 天以上。为此，建议您将 Amazon Pinpoint 配置为将数据导出到 Amazon Kinesis Data Streams 或 Amazon Data Firehose。如果将数据导出到 Amazon Kinesis，您还可以使用其他服务和应用程序执行更深入的分析或报告。有关更多信息，请参阅 [使用 Amazon Pinpoint 流式传输事件](analytics-streaming.md)。 ## 生命周期管理 在旅程通过开发和执行的各种阶段时，请牢记以下针对旅程生命周期的每个阶段的事项。另请注意，如果出现任何问题，您可以随时停止（取消）旅程。 | 阶段 | 描述 | | --- | --- | | 草稿 | 正在开发且尚未发布旅程。
在此阶段中，您可以更改旅程的任何方面，包括旅程的客户细分、活动和设置。您还可以利用 Amazon Pinpoint 功能来审查并测试旅程。您可以根据需要多次重复审核和测试流程。 | | 活动 | 已开发、审核、测试并发布历程。根据旅程的计划，旅程可能当前正在运行或计划稍后开始运行。
在此阶段中，您无法在旅程中添加、更改或删除活动。 | | Closed | 已开发、审核、测试并发布历程。旅程已开始运行，但对新参与者关闭。
根据旅程的计划和设置，它可能也已超过其预定结束时间。或者，旅程可能已超过其预定开始时间，并且它的进入活动设置为绝不添加新的客户细分成员。
在此阶段中，您无法向旅程添加新参与者，并且现有参与者无法首次进入旅程。但是，任何当前正在等待启动活动的现有参与者都可以恢复旅程。 | | Stopped（已停止） | 开发、审核、测试并发布了旅程，然后停止了旅程。停止旅程后，您无法重新启动旅程。您需要重新创建旅程。
如果您停止旅程，Amazon Pinpoint 会继续执行当前正在进行的活动，直到这些活动完成。Amazon Pinpoint 还会继续收集和汇总这些活动的分析数据，直到活动完成。它也会对您停止旅程时完成的任何活动执行此操作。
在此阶段中，您无法在旅程中添加、更改或删除任何活动。此外，Amazon Pinpoint 将停止评估旅程，并且不执行任何尚未启动的活动。 |