旅游业的推送通知自动化：5 个工作流程蓝图

现在是周二下午，留存率审查已于下午 2:15 结束。上个季度您的预订转化率下降了 1.4 个百分点——从 3.6% 降至 2.2%。忠诚度团队认为召回邮件的发送频率太晚了。移动团队认为被放弃的预订推送与降价提醒重叠。没有人能证明是哪一个原因。在会议后的 Slack 讨论串中，大家花了两个小时，唯一达成一致的是，仪表板不够精细，无法平息争论。

旅游推送通知自动化是这场争论的中心，留存团队的没有人确定如何为其辩护。预订确认自动推送在预订完成后触发。被放弃的预订触发器会在 24 小时后重新提醒相同的行程——有时该行程的价格不再是旅行者放弃时的价格，因为票价已在夜间发生变化。两年前有人设置的客户流失警告触发器在应用程序 DAU 下降时仍然会触发，但它不知道订阅者当前正在旅行，并没有真正流失，只是在度假。三个“自动化”机制，没有一个知道彼此的存在，没有一个对旅行者在旅行生命周期中所处的位置有连贯的认识。

本文将探讨旅游推送自动化实际上应该是什么样子——工作流架构，而不是在被放弃的预订触发器上添加的预订确认广播——并提供五个旅游相关的工作流蓝图，包括时机、票价变动时刻的退出标准、地理位置触发的行程中处理，以及将每个蓝图转化为广告运营和忠诚度团队可辩护的条目的收入计算。

为什么您的旅游“自动推送通知”在票价变动时会造成收入损失

自动化这个词在旅游业中的作用与在电子商务、SaaS和出版业中的作用相同，但它并没有带来应有的价值。当大多数旅游CRM团队谈论旅游的自动推送通知时，他们指的是事件触发的广播调度：当一个已知事件发生时，会触发一个通知，没有状态、没有细分、没有触达之间的等待、没有退出条件，并且——至关重要的是——它并不知道在第二次触达触发时，底层优惠可能已不再有效。

工作流则不同。工作流是一个具有状态的多步骤旅程。它知道旅客何时放弃预订、他们看到了什么票价、当前行程报价是多少、他们的行程状态如何，以及哪些条件会取消旅程。放弃预订工作流不会在24小时后只发送一次提醒推送。它会在每次触达前检查票价是否仍然有效，在预订完成的瞬间退出工作流，并在票价发生变化时单独退出——因为当票价从399美元变为529美元时，向旅客发送“完成您的399美元预订”会破坏信任，其破坏程度是任何挽回的预订都无法弥补的。

最后一句是关键区别。事件触发器没有外部状态的记忆。工作流有。如果您的放弃预订自动化在票价变动后，仍然以旧票价不断重新触达旅客，那么您就没有自动化。您只有一个没有人告诉它去检查的触发器。

对于一个中型旅游CRM团队来说，这种区别决定了重复预订的生命周期价值（LTV）是会复利增长还是会在票价变动时刻的破坏信任的错误中被侵蚀。三个并行运行的触发器会产生三个摩擦渠道。五个协调运行的工作流会为每位旅客、每段行程阶段产生一个旅程，该旅程会根据预订状态、票价有效性和行程状态进行分支和限制。该关键词的首页搜索结果将问题框定为“5个旅游用例”，并以工具列表的形式给出答案。但这并不是您的周二留存率审查会议所要问的问题。

旅游推送通知工作流的解剖

在蓝图之前，是词汇。旅游推送通知工作流由六种节点类型构建。一旦您了解了每种节点的作用，每个蓝图都会像一张图表一样易于理解，而不是一段描述。

开始。 入口点。START节点定义了工作流如何被触发，可以通过订阅者事件（booking_initiated、booking_abandoned、fare_changed、geolocation_changed、trip_completed）或通过受众筛选器（lifecycle_stage、loyalty_tier、last_active）来触发。一个工作流只有一个START节点。

等待。 延迟。WAIT 节点会根据指定时长（行程中响应使用分钟，废弃预订跟踪使用小时，行程前发送使用天数）或使用与订阅者属性关联的 wait_until 语义（departure_date - 7 days、departure_date - 1 day、trip_completion_date + 1 year）直到特定的日历时间来暂停订阅者。等待是工作流响应已知未来事件（而不仅仅是已知过去事件）的方式。

决策。 双向分支。DECISION 节点会检查每个订阅者的条件：预订是否已完成，票价是否仍然有效（从预订系统更新的订阅者属性读取），忠诚度等级是否高于银卡，旅行者当前是否在行程中。DECISION 节点会评估事件过滤器和受众过滤器；它们不会直接消耗 HttpRequest 响应正文。将外部状态引入工作流的模式是：HttpRequest 操作触发外部系统，外部系统通过 PushEngage REST API 写回订阅者属性，然后 DECISION 读取该属性。

路径拆分。 基于百分比的分叉。SPLIT_PATH 节点根据配置的百分比将订阅者路由到不同路径：废弃预订折扣金额的 A/B 测试为 50/50，行程前提醒的三路发送时间测试为 33/33/34。一旦您有了赢家，就可以将该路径提升到 100%。

操作。 实际工作。ACTION 节点会发送推送通知、将订阅者添加到细分、更新自定义属性、向预订系统或 SMS 网关发送 HttpRequest、启动另一个工作流或停止一个工作流。PushEngage Workflows 支持十一种操作类型。对旅行最有用的包括 SendPushNotification、UpdateAttribute、HttpRequest 和 Workflow.Start（用于将行程前、行程中和行程后链接起来）。

结束 / 退出。 终点。END 标记自然结束。EXIT 标记提前终止 — 在 Decision 的 NO 路径上（当旅行者不再符合条件时）、当冷却规则触发时，或当目标达成时（预订完成、行程取消、票价无效）。

下面的每个蓝图都由这六个部分组成。

旅游的五个工作流蓝图

这些不是模板。它们是可用的蓝图。每个蓝图都列出了其触发器、运行类型、节点序列、退出条件以及用于改进的旅行留存指标。您可以将每个蓝图导入到 PushEngage Workflows 构建器 中，并在不到一小时的时间内发布第一个版本。旧版 旅行推送通知指南 涵盖了这些蓝图所实现的更广泛的用例。

蓝图 1 — 欢迎 + 首次预订培育

• 触发器 (开始)： 事件 PushEngage.Subscriber.Added 或 browse_destination_page_view
• 运行类型： 单次（每个旅行者每 90 天窗口一次欢迎旅程）
• 流程： 欢迎推送，包含最受欢迎目的地 → 等待 1 天 → 目的地偏好推送，询问哪些旅行类型很重要（海滩、滑雪、城市度假、商务） → 等待 2 天 → 决策：订阅者是否已发起预订？ → 是路径：如果放弃则进入蓝图 2，否则在预订完成 (booking_completed) 后让行前工作流接管 → 否路径：发送精心策划的三目的地推荐推送，添加到 active_browsers 分段，结束
• 退出条件： 目标 booking_completed
• 旅行指标： 第 7 天的浏览到首次预订转化率。

蓝图 2 — 被放弃的预订（含票价变动退出）（预订放弃推送通知自动化）

• 触发器（开始）： 自定义事件 booking_abandoned，包含 itinerary_id 载荷
• 运行类型： 并行多实例（每次放弃的预订都是其自己的工作流实例）
• 流程： 等待 1 小时 → 操作：对您的预订系统的票价检查 (fare-check) 端点执行 HttpRequest GET 请求，使用 itinerary_id。预订系统通过 PushEngage REST API 将结果写回订阅者属性 — fare_status = valid 或 fare_status = invalidated — 几秒钟内 → 决策：受众过滤器 fare_status = valid？ → 否路径：发送“您的票价已更改，这是新价格的类似选项”推送并退出（优雅重定向，无信任违规） → 是路径：带有原始票价的提醒推送 → 等待 24 小时 → 重复 HttpRequest 票价检查，然后根据 fare_status = valid AND 受众过滤器 booking_completed = false 进行决策 → 是路径：带有 10% 促销代码的提醒 #2 → 等待 48 小时 → 带有更强优惠的最终提醒 → 结束
• 退出条件： 目标 booking_completed 匹配触发器的 itinerary_id 或受众过滤器 fare_status = invalidated
• 旅行指标： 每个放弃的预订挽回的预订价值。这是页面上收入最可辩护的行。这篇 减少预订放弃的 6 个技巧 博文涵盖了此蓝图的手动策略版本；工作流版本增加了票价有效性退出，将战术恢复转化为维护品牌信任的恢复。

蓝图 3 — 行前培育（出发日期计算）

这是行前推送通知工作流，演示了与订阅者属性关联的 wait_until 语义。

• 触发器（开始）： 自定义事件 booking_completed（该事件将 departure_date 写为订阅者属性）
• 运行类型： 每个预订单一实例
• 流程：等待直到 出发日期 - 14 天 → 发送“您的旅程还有两周”推送，包含打包建议和天气预报 → 等待直到 出发日期 - 7 天 → 发送辅助收入推送（座位升级、房间升级、租车附加服务、机场接送） → 等待直到 出发日期 - 1 天 → 发送入住提醒推送，包含手机登机牌链接 → 等待直到 出发日期 → 发送“旅途愉快”推送，结束
• 退出标准：目标 booking_cancelled
• 旅行指标：每次预订的辅助收入。7 天前触达是辅助收入的杠杆率最高的时刻。

蓝图 4 — 行程中地理位置（地理位置推送通知自动化）

• 触发器（开始）：自定义事件 geolocation_changed（由您的移动应用程序在设备报告新的经纬度时触发）且受众过滤器 trip_in_progress = true
• 运行类型：多个并行
• 流程：决策：旅行者是否已到达目的地城市（受众过滤器将地理位置坐标与存储为订阅者属性的目的地地理围栏进行比较）？→ 是路径：操作发送本地推荐推送（与目的地相关的酒店、餐厅、本地活动），操作向天气 API 发送 HTTP 请求 → 如果需要天气警报，操作发送天气通知 → 结束 → 否路径：退出（旅行者正在途中，未到达目的地）
• 静默时间：考虑订阅者时区。Workflows.md §9.4 按订阅者时区、站点时区、UTC 的顺序解决静默时间。对于旅途中的工作流，这意味着时区将遵循目的地的本地时间，而不是品牌的母市场。非关键推送使用 skip；安全和天气警报使用 reschedule 以确保送达
• 退出标准：目标 trip_completed
• 旅行指标：旅途中参与率和旅途中辅助收入。注意：geolocation_changed 不是内置触发器类型 — 它是您的移动应用程序在设备位置更新时触发的 PushEngage.CustomEvent，而到达目的地检查是基于应用程序维护的订阅者属性的受众过滤器。地理位置推送通知文章涵盖了此蓝图扩展的细分基础。

蓝图 5 — 行程后回顾 + 相似用户再预订

• 触发器（开始）：自定义事件 trip_completed
• 运行类型：多个顺序
• 流程：等待 3 天 → 发送提及目的地名称的评论请求推送 → 等待直到 trip_completion_date + 365 天（一年后）→ 发送“准备好开始下一次旅行了吗？”推送，提供基于先前旅行类型的类似目的地优惠 → 等待 7 天 → 决策：旅行者是否已发起预订？→ 是路径：链接到蓝图 1 或 2 → 否路径：退出
• 退出标准：新 booking_initiated 事件或 unsubscribed
• 旅行指标：12个月内的重复预订率。这是运行时间最长的蓝图——大约13个月——也是对客户终身价值（LTV）影响最大的蓝图。年同比的类似受众模式是电子商务购后挽回的旅行对应模式，它适应了旅行买家实际遵循的季节性节奏。

生命周期阶段细分、A/B 测试、按目的地时区的静默时段以及退出标准均包含在工作流中

旅行推送文章中占主导地位的模式是将这四个概念列为“最佳实践”——策略帖末尾的通用要点，与其使用的营销活动无关。这是错误的框架。它们不是与工作流程并列的最佳实践。它们就是工作流程。

概念	最佳实践框架（错误）	工作流节点框架（正确）
生命周期阶段细分	“按行程阶段细分旅行者”	一个基于订阅者属性lifecycle_stage（浏览/已启动预订/旅行前/旅行中/旅行后/流失）的DECISION节点，它将旅行前旅行者路由到辅助提醒，将旅行中旅行者路由到地理位置工作流程，将旅行后旅行者路由到评论和类似受众的重新预订。
A/B 测试	“始终对您的废弃预订文案进行A/B测试”	一个SPLIT_PATH节点，具有50/50的分配比例，每个路径的订阅者负载均衡，以及一个winner_edge_id字段，一旦测试达到显著性就将获胜者提升到100%——大多数旅行A/B测试是在第二个提醒中的折扣金额上进行的。
按目的地时区的静默时间	“不要在凌晨3点推送”	一个工作流程级别的选项，具有timezone: subscriber和fallback设置，该设置要么skip发送（非关键推送），要么将其reschedule到静默时间结束后一分钟（安全、天气、登机口变更）——这对于订阅者的本地时区是目的地而非品牌主市场的旅行中工作流程至关重要。
退出条件	“一旦他们预订就停止废弃预订序列”	一个工作流程级别的规则，在每个节点之前检查旅行者是否满足booking_completed目标 ANDfare_status = invalidated属性，如果任一条件匹配则取消工作流程——第二个条件是没有任何搜索结果页面（SERP）描述的内容。

区别很重要，因为最佳实践要点很容易被认可但难以执行。工作流程节点由引擎强制执行。DECISION每次都会运行。SPLIT_PATH每次都会平衡旅行者。静默时间回退会在没有人记得检查目的地时区的情况下启动。退出规则会在营销活动负责人是否关注的情况下取消废弃预订工作流程。

对于蓝图2的废弃预订流程，这意味着在旅行者预订的那一刻——在工作流程的第1小时、第30小时或第73小时——退出规则就会触发，该工作流程将为该旅行者取消，并且不会再向昨天已经付款的人发送“完成您的预订”推送。另外，一旦票价发生变化并且预订系统更新了fare_status = invalidated，工作流程就会优雅地退出并发送“票价已更改，这里有一些类似选项”的恢复推送。没有信任违规。没有愤怒的客户服务电话。

多渠道协调：网页推送、应用推送、短信、WhatsApp、电子邮件

旅游品牌比电子商务、SaaS或发布商团队拥有更多的渠道。桌面预订流程使用网页推送。已下载品牌应用的旅客使用应用推送。短信作为数据漫游弹性渠道，用于行程中的关键提醒（登机口变更、航班延误、天气）。WhatsApp用于高接触式客户服务以及在WhatsApp是默认通讯工具的地区的国际旅客。电子邮件作为长篇的旅行前行程容器。在一个工作流中组合所有这五种方式——选择与订阅者状态匹配的渠道——是区分一个提供连贯旅程的CRM团队和一个不得不为在目的地时区凌晨3点叫醒旅客的“您的航班准时”推送道歉的团队的关键。

一个精心设计的行程中登机口变更的旅程如下所示：

• 开始：自定义事件gate_change，针对trip_in_progress = true的行程
• 决策：旅客当前是否在使用该品牌的移动应用？
  • 是：操作，发送应用推送（摩擦最小，数据漫游感知交付）
  • 否：继续
• 决策：旅客是否正在国际漫游（受众过滤器country不等于home_country）？
  • 是：操作，通过HttpRequest发送短信至Twilio或Plivo（短信通过蜂窝语音而非数据传输——在漫游数据有限时具有弹性）
  • 否：操作，发送网页推送（旅客可能连接到酒店Wi-Fi）
• 操作：HttpRequest至ESP以更新下一个电子邮件行程摘要
• 退出条件为gate_acknowledged或flight_boarded

一个旅客身份，一个工作流，四个根据状态选择的渠道。最便宜的可行渠道优先。短信——每条发送成本最高——仅在旅客国际漫游且消息至关重要时发送。Booking.com将移动消息定义为“实时客户互动”，而非广播营销；这个组合工作流是以工作流架构表达的相同理念。

使用单独的工具运行此程序意味着需要五个供应商登录，两个关于谁当前在途的细分引擎存在分歧，并且没有一个旅客一个渠道的单一收入归因。在单个工作流引擎内完成此操作意味着一个旅客身份，一套决策逻辑，以及一个显示旅程实际中断位置的漏斗报告。HttpRequest操作（Workflows.md §5.7）使得跨渠道协调成为可能——它在不要求单独的协调工具的情况下，将工作流引擎连接到短信网关、ESP和预订系统。

留存率计算：旅游票务规模下的预订转化提升和重复预订 LTV

旅行的货币化是高客单价的。预订金额从 300 美元的短途航班到 5,000 美元的度假套餐不等——这改变了与电子商务（50-200 美元的购物车）和 SaaS（每年 99-999 美元的订阅费）相比的成本计算。PushEngage Workflows 在每个节点跟踪相同的三个数字——排队中、已完成、已退出——并且相同的节点级分析模式适用。每次挽回的预订收入远超每次挽回的购物车收入，这使得工作流的损益贡献更容易被证明。

以下是一个活跃的废弃预订工作流在一家中型在线旅行社（OTA）的节点级分析示例，该旅行社每月有 5,000 次废弃预订，平均客单价为 1,200 美元（示意性数字）：

节点	排队中	已完成	已退出	备注
开始（booking_abandoned）	0	5,000	0	所有废弃的行程进入
等待 1 小时	92	4,900	8	8 次在第一次互动前已预订
操作：HttpRequest 票价检查	0	4,900	0	预订系统更新 fare_status 属性
决策：fare_status 有效	0	4,410	490	490 次行程在第一次互动前因票价无效而退出——通过“票价已更改”的推送进行优雅退出
操作：提醒 #1（原始票价）	0	4,410	0	发送第一次提醒
等待 24 小时	134	3,950	326	326 次在第一次提醒后已预订
第二次票价检查 + 决策	0	3,720	230	另外 230 次行程因票价无效而退出——优雅退出
操作：提醒 #2 + 10% 促销	0	3,720	0	第二次提醒
等待 48 小时	78	3,200	442	另外 442 次在第二次提醒后已预订
操作：最终提醒 + 更强的优惠	0	3,200	0	最终推送
结束	不适用	3,200	不适用	3,200 次未预订

在此批次中，有 776 次废弃行程在工作流中转化为预订——恢复率为 15.5%。平均预订价值为 1,200 美元，这意味着每月挽回 931,200 美元的收入，或每年 1120 万美元。票价变更退出的挽救了另外 720 位旅行者的关系，避免了在票价已经上涨时收到误导性的“完成您的 399 美元预订”推送——该工作流独立于预订转化提升，避免了 720 次客户服务电话和品牌信任损害。

旅行的成本计算方式有所不同。网页推送和应用推送在用户选择加入后，每次发送的成本为零。通过 Twilio 发送的短信在美国国内每条约花费 0.0079 美元，国际短信每条花费 0.05-0.30 美元——每月 5,000 次废弃预订批次，其中 10% 的行程使用短信，短信花费为每批次 40-150 美元。WhatsApp Business Platform 按会话收费。电子邮件的成本取决于 ESP 合同。工作流的职责是首先使用最便宜的可行渠道，仅在状态需要时才升级到短信或 WhatsApp。项目“废弃预订工作流以 1500 美元的全包渠道成本挽回了每月 931,000 美元的预订”是那种能够赢得明年预算对话的损益表。

为您的旅游品牌在 PushEngage 工作流中构建它

五个旅行蓝图中的每一个都直接映射到 PushEngage Workflows 组件。映射关系如下：

蓝图	使用的节点类型	使用的操作类型	工作流选项
欢迎 + 首次预订培育	开始、等待、决策、操作、结束	SendPushNotification, AddSegment	运行类型：单次
废弃预订，含票价变更退出	开始、等待、操作、决策、结束	SendPushNotification、HttpRequest、UpdateAttribute	运行类型：多并行；在目标 booking_completed 或受众过滤器 fare_status=invalidated 时退出
行前培育（出发日期计算）	开始、等待（wait_until）、操作、结束	发送推送通知	运行类型：每次预订一次；wait_until 绑定到 departure_date 属性
行程中地理位置	开始、决策、操作、结束	SendPushNotification、HttpRequest、UpdateAttribute	运行类型：多个并行；CustomEvent + 受众过滤器触发
行程后回顾 + 类似受众再预订	开始、等待、操作、等待（wait_until）、操作、决策、结束	发送推送通知	运行类型：多次顺序

Workflows 引擎附带 60 多个已发货模板，涵盖每个蓝图的构建块。大多数模板都采用电子商务的模式，但适应旅行也很直接：通过将触发事件切换为 booking_abandoned，添加来自蓝图 2 的 HttpRequest-and-attribute-update 票价检查模式，并使用票价无效的退出标准以及 booking_completed，购物车放弃模板逻辑就变成了已放弃预订工作流。欢迎模板直接适用于蓝图 1。地理位置邮件模板 — 已在目录中 — 是蓝图 4 行程中工作流的基础。

对于更广泛的旅行推广背景 — 特定细分市场（酒店、机票、度假租赁）和季节性策略 — 旧的 旅行网站推送通知手册 目录化了这些蓝图实现的广告系列类型。

对于即时试用路径，免费套餐为您提供 200 个订阅者，所有渠道（网页推送、应用推送、WhatsApp、实时聊天），以及第一天即可使用的完整 Workflows 引擎。这足以在下一批已放弃行程中发布蓝图 1 和 2，并在下一次 QBR 之前捕获节点级分析。对于 PushEngage 的旅行垂直定位 — 定价、集成、客户示例 — PushEngage for travel 是标准登录页面。

这改变了什么

如果您要从本文中获得一件事，那就是：旅行的推送通知自动化是工作流架构，而不是带有已放弃预订触发器附加的预订确认广播。在票价变动时顺利退出的已放弃预订旅程，在 departure_date - 7 days 时触发的行程前工作流，尊重目的地时区的行程中地理位置工作流 — 它们都具有相同的形状。一个开始，一些等待，一些决策，一些操作，一个退出。三个独立的触发器无法做到这一点。一个工作流引擎可以。重复预订的 LTV 从那里复利。

从免费套餐开始，在下一批已放弃行程中发布第一个蓝图。