> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.onesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 旅程示例
> 入门、重新参与、购物车放弃、A/B 测试、循环发送和事件驱动工作流的分步旅程配置。
以下每个示例都包含推荐的旅程设置和分步配置。从更简单的模式（入门、重新参与）开始，逐步进阶到更复杂的工作流（循环发送、事件驱动进度、操作按钮分支）。
***
## 入门旅程
使用此模式向新订阅者发送欢迎或引导序列。通常也称为欢迎活动、欢迎系列或新用户活动。目标是引导用户完成关键操作（完成个人资料、首次购买或发现核心功能），而不是在他们注册时立即发送消息。
| 旅程设置 | 描述 |
| ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **进入规则** | **基于事件（推荐）：** 使用[自定义事件](./custom-events)触发器（例如 `signup_completed`），使序列在有意义的时刻开始：用户完成注册时。
**基于细分的备选方案：** "用户匹配细分标准"，使用"已订阅用户"[细分](./segmentation)，仅限未来新增。如果您尚未设置注册事件，请使用此方式。 |
| **退出规则** | 他们完成了整个旅程，或用户完成关键操作时（例如，他们退出"尚未完成引导"的细分）。 |
| **重新进入规则** | 否 |
| **内容** | 用户第一周内的简短序列：第 0 天发送欢迎邮件，如果他们未采取行动则在第 2 天发送推送提醒，第 7 天发送跟进邮件作为最后触达。 |
**旅程步骤**
用户刚刚注册，可能仍在您的应用中。电子邮件是正确的首次触达：它是预期的、非侵入性的，并且可以包含比推送通知更多的详情。当他们离开后再使用推送。
给用户时间自行探索，然后再跟进。
根据用户是否完成了您的引导目标添加是/否分支。通过[标签](./add-user-data-tags)（例如 `onboarding_complete = true`）或细分成员资格来跟踪。
* **是分支：** 退出旅程。用户不需要提醒。
* **否分支：** 发送带有具体可操作提示的推送通知。例如："完成您的个人资料设置"或"进行您的第一个\[操作]"。
在发送最终消息前，给推送足够的时间。
* **是分支：** 退出旅程。
* **否分支：** 作为最后触达发送跟进邮件。避免进一步发送消息。一周后仍未参与的用户更适合[重新参与活动](#re-engagement-campaign)。
***
## 重新参与活动
使用此模式赢回最近未打开您的应用或访问您网站的用户。该旅程发送一系列越来越有吸引力的消息，并在用户回归时立即退出。
| 旅程设置 | 描述 |
| ---------- | ----------------------------------------------------- |
| **进入规则** | **用户的上次会话大于 7 天；** 已订阅用户。如果目标是让更多免费用户回归，可考虑排除付费客户等细分。 |
| **退出规则** | **他们完成了整个旅程或满足特定条件** — 当用户在您的应用或网站中变为活跃时退出。 |
| **重新进入规则** | **是，在特定时间后：7 天。** 用户每次再次不活跃时都会重新进入。 |
| **内容** | 提醒用户在一段时间未打开应用时回到您的应用，并用奖励或折扣吸引他们。 |
**旅程步骤**
从推送开始——这是重新吸引流失用户最直观的渠道。使用清晰、以行动为导向的消息，例如"我们想念您！这是最新动态"。
在升级之前给用户时间响应推送。
添加是/否分支，检查用户是否已回归（例如，最近 2 天内有会话）。
* **是分支：** 退出旅程。用户已重新参与。
* **否分支：** 发送一封带有更强激励措施的电子邮件（例如，折扣、新内容或功能亮点）。
给电子邮件时间将用户带回。
* **活跃：** 退出旅程。
* **仍不活跃：** 可选择发送最终短信或退出。避免进一步发送消息——多次触达后仍未响应的用户不太可能因更多消息而转化。
***
## 购物车放弃
使用自定义事件或标签跟踪购物车活动并发送购物车放弃消息。
***
## 促销活动
使用此模式进行限时促销、销售活动或产品发布。该旅程通过预热、活动期间提醒和临近结束时的紧迫感消息来推动转化。
| 旅程设置 | 描述 |
| ---------- | ------------------------------------------- |
| **进入规则** | **用户符合细分条件。** 已订阅用户或与促销活动相关的细分。 |
| **退出规则** | **他们完成了整个旅程或满足特定条件。** 选择定义目标的细分（例如，已购买的用户）。 |
| **重新进入规则** | **否**——对于一次性活动，只发送一次。 |
| **内容** | 为活动做准备，在活动开始时提醒他们，在接近结束时提供折扣或奖励。 |
**旅程步骤**
发送电子邮件或推送，宣布即将到来的促销活动。包括日期、预期内容以及值得关注的理由。
添加一个设置为促销活动开始时间的等待步骤。
发送包含促销详情、折扣码或行动号召的推送通知或电子邮件。
给用户时间对初始消息采取行动。
发送带有紧迫感的最终推送或电子邮件——"明天促销结束"或"8折优惠最后机会"。已转化的用户将通过退出规则退出。
***
## 在用户离开应用程序后如果操作未完成则发送消息
**初始设置**
1. 使用[数据标签](./add-user-data-tags)标记用户需要执行的操作。在操作完成时删除标签。
2. 为此标签设置[细分](./segmentation)。
| 旅程设置 | 选项 | 描述 |
| ---------- | --------------- | ------------------------ |
| **进入规则** | 用户的上次会话大于指定时间量。 | 用户在应用或网站上最后活跃的时间阈值。 |
| **受众** | 包含您要用标签定位的细分。 | 这些是有资格接收消息的用户。 |
| **退出规则** | 当用户不再符合受众条件时退出。 | 当用户离开细分时，他们将不再有资格接收旅程消息。 |
| **重新进入规则** | 是，在特定时间后。 | 您希望等待用户再次有资格接收消息的时间量。 |
**旅程步骤**
为消息步骤选择模板。您可以根据您希望用户执行的操作使用推送、电子邮件、SMS 或应用内消息。
根据消息是否应作为提醒重复，这可以是短或长的时间间隔。在此示例中，等待设置为 104 周（2 年）。
## 旅程内的 A/B 测试
使用**分割分支**节点，您可以在旅程中设置 50/50 分割。创建两个不同的消息模板，当用户流经时，一半会收到"模板 A"，另一半收到"模板 B"。
从每个模板导出消息数据，以比较各变体之间的[分析](./analytics-overview)。
***
## 按顺序显示应用内消息且每天一次
此示例按顺序显示 3 个或更多应用内消息，每天显示一个。如果用户不打开应用，下次打开应用时仍会看到消息。
**初始设置**
创建名为 `iam_journey` 的细分，过滤条件：用户标签 `iam_journey` 为 `1`
1. 您可以将 `iam_journey` 更改为您选择的任何名称。
2. 此标签将设置在完成旅程并接收所有消息的每个用户上。
更多详情请参阅[使用拖拽设计应用内消息](./design-your-in-app-message)。
| 旅程设置 | 选项 | 描述 |
| ---------- | --------- | --------------------------------------- |
| **进入规则** | 用户符合细分条件 | 这些是有资格接收消息的用户。 |
| **受众** | 包含细分和排除细分 | 包含"已订阅用户"细分。排除步骤 1 中的"`iam_journey`"细分。 |
| **退出规则** | 他们完成了整个旅程 | 不需要额外条件。 |
| **重新进入规则** | 是，在特定时间后 | 2 分钟 |
**旅程步骤**
根据您要显示的消息数量重复此顺序。此示例使用 3 个应用内消息（IAM 1、IAM 2、IAM 3）。
1. **添加应用内消息步骤。**
1. 命名消息，例如：`IAM 1`。
2. 在消息底部，将**投递计划**设置为 **1 天**。
2. **在应用内消息步骤之前添加是/否分支操作。**
1. 设置分支条件：上一个消息行为："`IAM 1` 已查看"。
2. **跟随否分支**
1. 将 `IAM 1` 拖到否分支。
2. 添加 1 天的等待步骤。
3. **跟随是分支**
1. 在是分支内，为所有消息重复步骤 1 和 2，将 `IAM 1` 替换为下一个应用内消息（`IAM 2`、`IAM 3`）。
2. 在最终是分支，添加**标记用户**操作。
1. 使用初始设置→步骤 1 细分中使用的相同键为用户打标签。
1. 例如 `iam_journey : 1`。
## 限制进入旅程
确保用户只能在控制每个阶段体验的同时有限次数进入旅程。
| 旅程设置 | 描述 |
| ---------- | ---------------------------------------------------- |
| **进入规则** | 用户符合细分条件（例如，已订阅用户或任何相关的目标细分）。 |
| **受众** | 包含您的目标细分。排除带有标签 `journey_count = 2` 的用户，以将进入次数限制为两次。 |
| **退出规则** | 他们完成了整个旅程。 |
| **重新进入规则** | 是，在一定时间后：15 天。 |
| **内容** | 在初次进入时提供首次体验，在重新进入时提供量身定制的第二次体验。防止第二次之后的任何进一步进入。 |
**初始设置**
使用名为 `journey_count` 的用户标签来跟踪进入次数。标签在您在旅程中设置时自动创建。有关详细信息，请参阅[标签操作](./journeys-actions#tag-user)。
在旅程受众中：
* 包含您的目标细分（例如，"已订阅用户"）。
* 排除用户标签 `journey_count` 为 `2` 的用户。
将重新进入规则设置为"是，在一定时间后：15 天。"
这允许在第一次和第二次运行之间恰好重新进入一次。
**旅程步骤**
条件：用户标签 `journey_count` 等于 `1`。
* **是分支** = 回访用户（第二次进入）。
* **否分支** = 首次用户（尚无标签）。
* 添加标记用户操作：将 `journey_count` 设置为 `1`。
* 发送您的首次消息和操作。
* 根据需要继续到结束或其他逻辑。
* 添加标记用户操作：将 `journey_count` 设置为 `2`。
* 发送您的回访用户消息和操作。
* 根据需要继续到结束或其他逻辑。
因为受众排除了 `journey_count = 2` 的用户，任何尝试的第三次进入都将自动被阻止。
## 特定日期的循环旅程
发送与特定星期几对齐的循环消息，例如每周促销或活动提醒。
| 旅程设置 | 描述 |
| ---------- | ----------------------- |
| **进入规则** | 用户符合细分条件（例如，已订阅用户）。 |
| **受众** | 包含您的目标细分。 |
| **退出规则** | 他们完成了整个旅程。 |
| **重新进入规则** | 是，在一定时间后：7 天。 |
| **内容** | 在特定日期发送的每周消息（例如，每个星期五）。 |
**初始设置**
包含您的目标细分，以便符合条件的用户可以在一周的任何时间进入旅程。
将重新进入规则设置为"是，在一定时间后：7 天"以启用每周循环。
* 重新进入计时器在用户**退出** Journey 时开始，而不是进入时。
* 7 天的重新进入确保用户及时重新进入以赶上下周的时间窗口。
* 重新进入持续时间必须**长于时间窗口持续时间**以避免重复发送。
有关详细信息，请参阅[将时间窗口用于定期发送](./journeys-actions#using-time-windows-for-recurring-sends)。
**旅程步骤**
配置时间窗口以筛选您的目标星期几（例如，星期五）。
进入旅程的用户将等待到下一个匹配的日期。
将消息节点放在时间窗口之后，以便在到达该日期时发送。
让用户在消息发送后退出。由于重新进入时间为 7 天，他们将每周重新加入并重复。
定期更新消息内容，以避免每周重复相同的文案。
## 渐进式旅程（事件驱动）
根据用户进度提升参与度，通过[自定义事件](./custom-events)和[等待直到](./journeys-actions#wait-until)条件进行监控。
| 旅程设置 | 描述 |
| ---------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **进入规则** | **自定义事件** = `Progression_Level`，带有过滤器 `progression_level = 0`。 |
| **受众** | 可选的细分过滤器。您可以为所有用户运行此程序或限制为子集；不需要标签。 |
| **退出规则** | - 他们完成了整个旅程。
- 或当达到最大进度级别时（`progression_level = 3`）。
- 可选：当**等待直到**节点过期时退出。
- 可选：从**等待直到**节点分支以标记未完成事件的用户，将他们引导到重新参与旅程。 |
| **重新进入规则** | 否 |
| **内容** | 基于阶段的消息，随着用户完成里程碑而升级（本例中为电子邮件）。 |
**旅程步骤**
所有符合条件的用户根据进入规则进入。
触发器：**自定义事件** `Progression_Level` 带有 `progression_level = 0`。
开始：**立即**。
* 等待直到自定义事件 `Progression_Level` 发生，带有 `progression_level = 1`。
* 发送：**级别 1 完成！** 消息。
* （可选）在等待节点上应用过期 → 如果未达到里程碑则退出用户。
* （可选）分支：如果过期，标记用户并将他们发送到重新参与旅程。
* 等待直到自定义事件 `Progression_Level` 发生，带有 `progression_level = 2`。
* 发送：**级别 2 完成，你做得很好！** 消息。
* （可选）应用过期或分支/标记到重新参与。
* 等待直到自定义事件 `Progression_Level` 发生，带有 `progression_level = 3`。
* 发送：**你已经达到级别 3！** 消息。
* （可选）应用过期或分支/标记到重新参与。
一旦用户完成级别 3，或当等待直到节点过期时结束旅程。
可选地，使用分支/标记路径将停滞的用户路由到重新参与轨道。
时间表：**立即开始**，**永不停止**。
此方法确保仅在真正的参与信号发生时才发生进度。添加过期和分支/标记逻辑可让您优雅地处理停滞的用户——要么让他们退出，要么将其重新路由到重新参与旅程。
***
## 根据点击的操作按钮分支旅程
根据用户点击的推送通知操作按钮，将用户引导到不同的旅程路径。此模式使用[操作按钮](./action-buttons)、[自定义事件](./custom-events)和[等待直到](./journeys-actions#wait-until)步骤，根据用户的具体按钮点击（而不仅仅是是否点击）来分支用户。
此示例需要网站或应用程序代码来捕获按钮点击并发送自定义事件。无法完全通过 OneSignal 仪表板完成。
| 旅程设置 | 描述 |
| ---------- | -------------------------------- |
| **进入规则** | 用户符合细分条件（例如，已订阅用户或特定活动的细分）。 |
| **退出规则** | 他们完成了整个旅程。 |
| **重新进入规则** | 否 |
| **内容** | 发送带有多个操作按钮的推送，然后根据用户点击的按钮分支后续消息。 |
内置的[是/否分支](./journeys-actions#yesno-branch)消息行为条件检测用户是否**点击**或**收到**消息——但不检测他们点击了\_哪个\_按钮。要按特定按钮分支，您需要从点击事件中捕获操作 ID，并将其作为旅程可以分支的自定义事件属性发送。
在旅程中创建推送消息时（或在[模板](./templates)中），打开**高级选项 > 操作按钮**并为每个按钮分配唯一的**操作 ID**。
**示例**：带有两个 CTA 的促销推送：
* 按钮 1："立即购物" → 操作 ID：`shop_now`
* 按钮 2："了解更多" → 操作 ID：`learn_more`
有关完整设置详情，请参阅[操作按钮](./action-buttons)。
在您的网站上或应用程序中，监听通知点击事件并发送包含操作 ID 作为属性的自定义事件。
Web SDK 示例需要版本 `160500` 或更高版本。用户应已[登录](./web-sdk-reference#login)才能追踪自定义事件。
```javascript Web SDK theme={null}
OneSignalDeferred.push(function(OneSignal) {
OneSignal.Notifications.addEventListener("click", function(event) {
var actionId = event.result.actionId;
if (actionId) {
OneSignal.User.trackEvent("cta_clicked", { button: actionId });
}
});
});
```
```kotlin Android SDK theme={null}
OneSignal.Notifications.addClickListener { event ->
val actionId = event.result.actionId
if (actionId != null) {
OneSignal.User.trackEvent("cta_clicked", mapOf("button" to actionId))
}
}
```
```swift iOS SDK theme={null}
let listener = { (event: OSNotificationClickEvent) in
if let actionId = event.result.actionId {
OneSignal.User.trackEvent("cta_clicked", properties: ["button": actionId])
}
}
OneSignal.Notifications.addClickListener(listener)
```
有关事件要求和限制，请参阅[自定义事件](./custom-events)。
在旅程的推送消息步骤之后：
1. 添加一个**等待直到**步骤。
2. 为每个按钮添加条件：自定义事件 `cta_clicked`，其中属性 `button` 等于操作 ID（例如，`shop_now`）。
3. 为每个您要分支的操作 ID 添加其他条件（例如，`learn_more`）。
4. 设置**过期时间**（例如，3 天），以便未点击任何按钮的用户继续走备用路径。
用户遵循他们**满足的第一个条件**的分支。如果在过期前没有满足任何条件，他们将遵循过期分支。
在等待直到步骤之后的每个分支上，添加适当的后续消息或操作：
* **"立即购物"分支**：发送产品推荐或折扣码。
* **"了解更多"分支**：发送教育内容或功能概述。
* **过期分支**：发送重新参与消息或退出旅程。
您还可以链接多个等待直到步骤，以便对后续交互也进行分支——旅程中的等待直到步骤数量没有限制。
***
## 常见问题
### 我可以安排每天发送消息吗？
是的。添加一个[时间窗口](./journeys-actions#time-window)节点作为第一步，并将其配置为一周中的每一天，设置您希望消息发送的时间（例如，用户时区的上午 10 点到下午 6 点）。然后将**重新进入规则**设置为短于一天但**长于时间窗口持续时间**的时间——例如，8 小时窗口设置 12 小时。这确保用户足够早地重新进入以赶上第二天的时间窗口，而不会有在同一窗口内重复发送的风险。
### 我可以在旅程中对不同消息进行 A/B 测试吗？
是的。添加一个[分割分支](./journeys-actions#random-split)节点，将用户均匀分配（例如，50/50）。在每个分支上放置不同的消息模板，然后在旅程运行后比较两个模板之间的分析数据。
### 如何限制用户进入旅程的次数？
使用标签（例如，`journey_count`）来跟踪进入次数。每次用户进入时递增标签，并添加受众排除规则，一旦标签达到您希望的限制就阻止用户。请参阅上面的[限制进入旅程](#limited-entry-journey)示例。
### 为什么我的循环旅程在错误的日期发送？
[时间窗口](./journeys-actions#time-window)节点在有时区数据时按用户本地时区进行筛选。如果用户没有时区数据，则根据您应用的默认时区发送消息。验证您的时间窗口设置和用户时区数据是否正确。
### 如何停止正在运行的旅程？
在旅程设置中将旅程状态设置为**暂停**或**停止**。暂停的旅程保留用户在当前步骤；停止的旅程立即退出所有用户。有关详细信息，请参阅 [Journey 设置](./journeys-settings)。
***
## 相关页面
旅程介绍及其工作方式。
添加等待步骤、分支逻辑、时间窗口和分割路径。
配置进入规则、退出规则、重新进入和计划。
在 Journey 中配置推送、电子邮件、SMS 和应用内消息步骤。
构建购物车放弃旅程的完整演练。
触发旅程并传递事件属性进行个性化。
通过投递指标、用户活动和转化洞察跟踪旅程表现。
* [最大化用户参与度：推送通知和电子邮件的协同作用](https://onesignal.com/blog/use-push-notifications-and-email-together/)
* [通过旅程持续创造价值](https://onesignal.com/blog/consistently-drive-value-with-journeys/)
* [通过电子邮件提高跨渠道旅程的参与度](https://onesignal.com/blog/increase-engagement-with-email-for-cross-channel-journeys/)
* [通过应用内消息和短信改善旅程的留存率](https://onesignal.com/blog/improve-retention-with-in-app-and-sms-for-journeys/)