触发式推送营销活动：情境化工作流指南

现在是季度第二周，您的留存仪表板显示有六个“自动化”触发器正在运行，全部为绿色。购物车放弃触发器会持续向已付款的订阅者发送消息。召回营销与针对同一流失客户的价格下降提醒重叠。欢迎系列邮件独立于首次购买提示发送通知。退货订单的订阅者昨天收到了购后评论请求。

六个触发式推送营销活动中的每一个都像一个管道，指向同一个订阅者列表，并且都假装其他五个不存在。复购率在十二个月前就停止增长了，团队中的没有人能够将收入归因于每个触发器，因为触发器之间不共享状态。

这就是大多数中型市场留存营销栈的运营现实。问题不在于策略。策略是没问题的。问题在于架构。2024年的触发式通知是基于单个事件触发的单个消息。到了2026年，这种原始方式已不足够。营销旅程必须记住订阅者做了什么，基于此进行分支，并在他们转化时退出。

本文提出了架构方面的论证。它定义了广播式、触发式和情境化推送通知之间的界限，阐述了事件触发器和受众触发器之间的区别，列出了将单个触发器转化为情境化工作流的六种节点类型，并提供了三种迁移模式，将六个独立的触发器整合为三个具有共享退出条件和每个工作流分析的情境化营销旅程。

情境化、触发式、广播式：三种原始方式，而非一种

每种推送通知计划都基于三种原始方式。大多数团队将其合并为一个称为“营销活动”的类别，而架构问题就由此开始。

广播式。 相同的通知会按计划发送给所有匹配的受众。中午的闪购。发布日的新品系列提醒。广播式适用于有时间限制的公告，其中每个接收者都获得相同的载荷。但它不适用于任何依赖订阅者状态的内容。

已触发。单个通知在单个事件触发时触发。订阅者放弃购物车，则触发购物车放弃通知。订阅者查看产品页面，则触发浏览通知。订阅者购买，则触发购买后通知。触发器没有记忆。它不知道五分钟前发生了什么，也不知道下周二的计划。每个触发器都是一个管道，对其他所有触发器一无所知。

情境化。工作流将触发器作为入口点，然后根据订阅者状态进行调整。相同的购物车放弃事件会启动一个多步骤旅程：等待一小时，发送第一个提醒，等待 24 小时，进行一次检查购物车是否仍打开的决策，发送带有折扣的第二个提醒，等待 48 小时，发送第三个提醒，以及一个退出规则，在订阅者购买的瞬间取消工作流。活动是工作流，而不是触发器。情境化推送通知是在架构跟上之后触发式消息传递的行为方式。

这三个基本要素可以清晰地映射到三个工作负载。审核您当前堆栈时，请使用此表。

功能	广播	已触发	情境化
每个订阅者的状态	否	否	是
基于行为的分支	否	否	是
退出条件	否	否	是
在一个活动中进行多渠道路由	否	否	是
内置 A/B 测试（发送时间、文案、渠道）	否	否	是
正确的工作负载	闪购、新品发布公告	一次性交易性消息（低量）	生命周期旅程（欢迎、购物车、挽回、续订）

大多数生命周期计划都需要情境化。大多数团队发送触发式消息。这个差距就是本文要讨论的内容。发送情境化旅程的营销自动化工作流看起来不像一长串触发器；它们看起来像由共享词汇组成的一小组多步骤旅程。您真正想要的消息推送工作流是三个情境化旅程，而不是九个触发器。

事件触发器和受众触发器的行为差异很大

在节点解剖学之前，有一个关于这个主题几乎所有文章都弄错了的分类点。“触发器”在消息推送工作流中不是一个单一的基本要素。它是两个基本要素，从外部看起来相似，但内部行为截然不同。

事件触发器在真实事件发生时针对每个订阅者触发。 PushEngage Workflows 支持的事件包括 PushEngage.Subscriber.Added、PushEngage.Subscriber.AddSegment、PushEngage.Subscriber.RemoveSegment、PushEngage.Subscriber.UpdateField、PushEngage.Subscriber.UpdateAttribute、PushEngage.Goal.Tracked 和 PushEngage.CustomEvent。当事件触发时，系统会评估活动工作流，检查事件过滤器条件，检查退出规则，并为该订阅者排队匹配的工作流。触发到排队的延迟是几秒钟。事件触发器是任何响应式活动的正确基本要素：购物车放弃、浏览放弃、购买后续、分段加入欢迎。事件触发式推送活动是电子商务、SaaS 入门和任何具有实时信号的程序中的主要用例。

受众触发器在预定时间触发筛选器。 该筛选器会选择符合特定条件的订户，例如 last_active > 30 days、loyalty_tier = gold 或 city = New York AND segments includes "vip"。调度程序轮询器以 1000 个为一组获取匹配的订户集，将执行间隔设置为 15 秒到 2 分钟，并为每个订户创建一个工作流实例。受众触发器是重新互动、生日营销、地理推广以及任何通过属性而非事件定义的计划的正确原始触发器。

这些差异在操作上很重要，而不仅仅是概念上的：

方面	事件触发器	受众触发器
启动	基于订户事件的实时触发	通过轮询器计划
速度	几秒钟内	批量处理，延迟 1-2 分钟
订户选择	每次事件一个订户	仅在工作流开始时批量选择
开始后新订户	在事件发生后自动包含	工作流开始后不自动包含
工作流开始后筛选器更改	不适用	编辑筛选器不会添加新订户
事件数据可用	是（用于变量替换）	否

第三行是关键。基于受众的工作流一次性选择其订户集，在工作流开始时进行。工作流开始后变得不活跃的订户不会被自动添加。编辑正在运行的工作流的受众筛选器不会吸引新候选人。一个将“针对 30 天以上不活跃订户的召回”工作流运行九十天的留存团队，将在整个九十天内看到相同的固定队列，尽管每天都有新订户跨越 30 天的阈值。

架构上的解决方案是按月或按周定期重复运行受众工作流，以便每次重复都能捕获自上次运行以来达到阈值的新候选人。这在文档中只是一句操作说明，但在将受众触发器视为事件触发器的团队中，却会反复出现“为什么这个订户没有收到营销活动？”的支持工单。

将触发器转化为情境化营销活动的六种节点

触发器触发后，工作流本身由六种节点类型组成。词汇量很小，可以在五分钟内学会，但又足够丰富，可以组合留存团队想要发送的任何情境营销活动。

开始。 入口点。START 节点定义触发器（基于事件或基于受众）和筛选器条件。一个工作流只有一个 START。入口点决定了上一节中的触发器分类法，并设置了下游节点可以读取的事件数据上下文。

等待。 延迟。WAIT 节点会根据指定的时间（分钟、小时、天）或直到特定的日历时间来暂停订阅者。等待是工作流如何遵守订阅者状态和订阅者时区的关键。工作流可以等待一小时发送购物车放弃提醒，等待三天发送欢迎系列中的功能亮点，或等待到订阅者本地时区的周二上午 10 点发送业务时间消息。等待还可以让您在不触发前 60 秒内所有消息的情况下，构建一个多步骤的滴灌流程。

决策。 双向分支。DECISION 节点会检查事件过滤器或受众过滤器，并将订阅者路由到 YES 路径或 NO 路径。订阅者是否已购买？他们是否仍在购物车放弃细分市场中？他们的忠诚度等级是否已更改？决策节点是行为推送通知停止一视同仁并开始适应每个订阅者实际行为的方式。支持的运算符包括等于、不等于、包含、不包含、大于、小于和存在，这足以表达保留团队所需的任何决策逻辑。

路径拆分。 基于百分比的 A/B 测试分叉。SPLIT_PATH 节点根据配置的百分比将订阅者路由到两个或多个路径：50/50 用于双向测试，33/33/34 用于三向发送时间测试，90/10 用于保留组。系统使用负载平衡算法将每个新订阅者路由到利用率最低的路径，即使在小样本量下也能保持准确的分布。一旦测试达到显著性，设置 winner_edge_id，工作流会将 100% 的流量提升到获胜的变体，而无需重建工作流。

操作。 实际工作。ACTION 节点的功能不仅仅是发送推送通知。PushEngage 工作流支持十一种操作类型：SendPushNotification、AddSegment、RemoveSegment、UpdateField、UpdateAttribute、Update（合并）、HttpRequest、CustomEvent.Send、SendTriggerCampaignEvent、Workflow.Start 和 Workflow.Stop。在保留计划中最常见的四种是 SendPushNotification、AddSegment（标记订阅者为已转化、已入驻或有流失风险）、UpdateAttribute（增加忠诚度计数器或设置上次购买日期）和 HttpRequest（将状态同步到 CRM、为高价值潜在客户触发 Slack 警报或调用下游服务）。

结束 / 退出。 终端。END 和 EXIT 节点标记工作流完成并更新分析。END 是自然结束。EXIT 通常放置在决策的 NO 路径上，当订户不符合条件时，或放置在设计为对照组的分支路径上。系统还支持工作流级别的退出标准：audience_filter 或 trigger_event，可在每个节点运行之前取消活动工作流。无论订户当前位于哪个节点，退出规则都会触发。这就是停止向已购买的订户发送购物车放弃工作流提醒的原因。

本文中的每个情境营销活动都由这六个部分组成。一旦共享了词汇，下面的迁移模式就能快速阅读。

三种迁移模式：六个独立触发器变成三个情境化工作流

大多数中型市场的留存堆栈运行着四到八个独立的触发器。模式是一致的：欢迎通知、首次购买提示、购物车放弃、浏览放弃、购后评论请求、挽回、重新激活、流失的 VIP。这些都是独立的触发器，有自己的文案、自己的负责人和自己的分析。它们彼此之间一无所知。同样的情境工作流可以用三分之一的表面积来获得相同的收入。

模式 1 — 入驻整合

将欢迎系列和首次购买提示合并到一个工作流中，并根据购买状态进行决策。

• 开始： 事件 PushEngage.Subscriber.Added
• 运行类型： 单次（完成后 90 天冷却期）
• 流程： 等待 1 天 → 操作发送欢迎通知 → 等待 3 天 → 决策：订户是否已购买？ → YES 路径：操作发送感谢信 + 操作将 AddSegment 添加到 customers + 结束 → NO 路径：操作发送首次购买 10% 折扣 → 等待 4 天 → 决策：订户是否已购买？ → YES 路径：操作发送感谢信 + 结束 → NO 路径：操作发送最终提示 + 结束
• 退出标准： 工作流级别无；决策分支处理已转化的订户
• 替换： 欢迎触发器 + 首次购买触发器（2 个触发器 → 1 个工作流）

共享状态是关键。第三次通知仅针对第四天仍未转化的订户发送。旧架构中的首次购买触发器会针对所有新订户发送，包括那些在首次会话中购买的订户。该工作流将停止打扰他们。

模式 2 — 购物车到评论链

将购物车放弃恢复和购后评论请求合并到一个工作流中，并进行工作流链式传递。

• 开始： 自定义事件 cart_abandoned
• 运行类型： 多次并行（每次放弃的购物车都是一个独立实例）
• 流程： 等待 1 小时 → 操作提醒 #1 → 等待 24 小时 → 决策：购物车是否仍被放弃？ → YES 路径：操作提醒 #2（含 10% 折扣） → 等待 48 小时 → 决策：购物车是否仍被放弃？ → YES 路径：操作最终提醒（含 20% 折扣） → 结束
• 退出条件（工作流级别）： Goal.Tracked = purchase 匹配触发事件中的 cart_id。订阅者购买的瞬间，工作流即取消。
• 交接：因购买而退出时，系统会触发 PushEngage.Workflow.Start，目标为评论请求工作流。评论工作流仅针对实际购买的订阅者启动。因未购买而退出的路径将完全跳过交接。
• 替换：购物车触发器 + 购后评论触发器 + 评论请求发送给从未购买的订阅者的支持工单（3个问题 → 1个工作流）

通过 Workflow.Start 进行链接是生命周期推进的架构性解决方案。购物车工作流在购买时退出的机制启动评论工作流，而不是两个触发器独立触发并重叠针对同一订阅者。评论仅针对已转化的订阅者触发。购物车在转化后永不触发。引擎强制执行交接。

模式 3 — 再互动整合

将挽回、激活和流失VIP活动合并为一个工作流，包含一个受众触发器和三个决策分支。

• 开始：受众筛选器 last_active > 30 days
• 运行类型：单次（每90天窗口期内，每个订阅者进行一次重新互动尝试）
• 流程：决策：忠诚度等级？→ 金牌分支：操作发送“我们想念您，VIP”并提供20%的优惠 → 银牌分支：操作发送“我们想念您”并提供10%的优惠 → 无等级分支：操作发送标准的“我们想念您”并提供免运费优惠 → 等待5天 → 决策（按分支）：订阅者是否互动或访问过网站？→ 是路径：操作 AddSegment 到 re-engaged + 结束 → 否路径：操作发送“最后机会”并提供更深的优惠 + 结束
• 退出条件（工作流级别）：受众筛选器 last_active < 7 days。订阅者自行变得活跃，工作流的任务已完成。
• 替换：挽回触发器 + 激活触发器 + 流失VIP触发器（3个触发器 → 1个工作流）
• 操作说明：根据上一节中的受众触发器陷阱，此工作流不会自动包含在工作流开始后跨越30天阈值的订阅者。每月复制一次工作流，以便每个副本都能捕获新的候选者。单个长期运行的受众工作流不是这里的正确工具。

完成这三次迁移后，留存团队将负责三个情境化旅程，而不是六个（或八个）独立的触发器。推送消息的总量大致保持不变。由于共享的退出条件和决策分支会在订阅者状态不再匹配时停止工作流，因此过度发送的消息消失了。分析结果从“六个我无法协调的仪表板”变为“三个我可以辩护的漏斗”。这就是事件触发的推送活动成熟后的样子。

情境化工作流能做到独立触发器无法做到的事情

一个上下文工作流内部存在四种能力，并且不能跨独立的触发器进行组合。每一种都是收入或节省的真实来源。

跨工作流退出条件。独立的触发器在事件发生时触发，仅此而已。在工作流内部，无论订阅者位于哪个节点，退出规则都会触发。购物车放弃工作流在购买时退出。挽回工作流在重新激活时退出。续订工作流在提前续订时退出。未被告知停止的触发器是定义了退出规则的工作流。

一个工作流内的多渠道路由。使用独立的单渠道工具，“发送网页推送，回退到电子邮件，升级到 WhatsApp”需要三个供应商登录、两个细分引擎和至少一个 Zapier 流程。在一个工作流引擎内部，这是三个操作节点，中间有两个决策节点，共享一个订阅者身份和一组退出条件。有关更深入的介绍，请参阅多渠道推送和电子邮件编排帖子。

带有 reschedule 回退的静默时间。如果静默时间配置了 reschedule 作为回退，那么将在订阅者本地时区凌晨 3 点发送的推送通知将被推迟到上午 8:01。另一种选择 skip 会静默丢弃通知，并且不更新跳过操作的通知分析。对于大多数留存团队来说，reschedule 是正确的默认设置，因为丢弃的分析意味着收入归因的丢失。留存团队实际想要发送的上下文推送通知在尊重订阅者时区的同时，不会从漏斗中消失。

工作流链接。Workflow.Start 和 Workflow.Stop 操作使生命周期进展成为一个真正的架构。欢迎工作流结束，然后开始互动工作流。购物车工作流在购买时退出，然后开始评论工作流。与一堆所有独立触发的触发器文件夹相比，这是一个状态机：一个工作流图，每个工作流都有自己的进入条件、退出条件以及到下一阶段的交接。触发器之间互不了解。工作流则了解。

每个工作流的分析：如何解读漏斗

在下一次损益表审查中无法辩护的工作流将被取消。PushEngage 工作流在每个节点跟踪三个数字（queued_users、completed_users、exited_users），以及工作流级别的总进入用户数、当前活跃用户数、已完成用户数和已退出用户数。留存经理的工作是阅读此漏斗并告知财务部门每个项目产生了多少收入。

上面模式 2 中的购物车到评论链的节点级分析如下所示。这是说明性数字，来自一个拥有 6% 月度购物车放弃率的 200,000 用户列表。

节点	排队中	已完成	已退出	备注
开始（购物车已放弃）	0	12,400	320	320 名订阅者在工作流开始时匹配退出条件（在购物车事件和工作流扫描之间已购买）
等待 1 小时	180	11,900	320	正常队列深度
操作：提醒 #1	0	11,900	0	已发送
等待 24 小时	240	9,800	1,860	1,860 位订阅者在第一次提醒后购买（目标 purchase 退出）
决策：购物车仍被放弃	0	9,800	0	分支已评估
操作：第二次提醒（10%）	0	9,800	0	已发送
等待 48 小时	90	6,300	3,410	3,410 位订阅者在第二次提醒后购买
操作：最后提醒（20%）	0	6,300	0	已发送
结束	不适用	6,300	不适用	6,300 位订阅者未购买；审核工作流未为他们链接
Workflow.Start → 审核工作流	不适用	5,270	不适用	已触发 5,270 位购买的订阅者（1,860 + 3,410）

这 5,270 次链接交接是此架构显示的新指标。购物车工作流恢复了 42.5% 的购物车率（12,400 人进入，5,270 人转化），只有这 5,270 位订阅者会收到评论请求工作流。旧架构会将评论请求发送给所有曾经购买过的订阅者，包括从未放弃购物车的订阅者、退货的订阅者以及已经提交过评论的订阅者。架构修复很简单。但节省的过度发送消息的成本很高。

有两种值得了解的瓶颈模式。高退出节点（如上面的两个 WAIT 节点）是工作流在执行其任务：订阅者在等待窗口期间购买，退出条件触发，下一个提醒永远不会发送。反向模式，即操作节点的高退出率与等待节点低退出率相结合，意味着时机不当，等待时间应缩短。高队列节点表示静默时段停滞、长时间等待或下游轮询器延迟；在假设工作流损坏之前，请检查时序配置。

有关这些模式更深入的电子商务特定处理，请参阅配套文章 面向电子商务的五种推送通知工作流，其中介绍了购物车、浏览、购后、欢迎和挽回作为独立旅程。 电子商务推送通知中心涵盖了更广泛的广告系列类型，购物车放弃恢复序列介绍了按平台调整的节奏，而 自动推送通知概述则展示了旧的自动化类型列表以及此工作流架构。

相同的分析模式适用于各个垂直领域。SaaS 有续订漏斗和试用到付费转化。发布商有文章参与漏斗和存档重新进入。旅游业有预订漏斗和价格下降警报流程。SaaS 团队用于推动试用到付费的个性化推送通知，在结构上与电子商务团队用于推动购物车到购买的通知相同：一个基于实时事件的 START，三个或四个带有决策分支的步骤，转化时的退出条件，可选地转到下一个工作流。垂直领域改变了触发器名称和优惠文案。架构保持不变。

在 PushEngage 工作流中构建

上面三种迁移模式中的每一种都直接映射到 PushEngage Workflows 组件。

模式	使用的节点类型	使用的操作类型	工作流选项	建议模板起点
入驻整合	开始、等待、决策、操作、结束	SendPushNotification, AddSegment	运行类型：单次	“欢迎系列及首次购买分支”
购物车到评论链接	开始、等待、决策、操作、结束	SendPushNotification, Workflow.Start	运行类型：多并行；退出条件 Goal.Tracked = purchase	“购物车放弃升级”
重新参与整合	开始（受众）、决策、操作、等待、结束	SendPushNotification, AddSegment	运行类型：单次；受众触发；每月重复	“基于分层的优惠重新互动”

Workflows引擎附带60多个预置模板，涵盖上述每种迁移模式。每个模板都是一个起点。这些模式可在Shopify、Shopify Plus、WooCommerce、BigCommerce和Magento上通过PushEngage Workflows构建器在五分钟内安装完成，或通过JavaScript SDK和事件API在任何SaaS、发布商或旅游堆栈上安装完成。

免费套餐为您提供200个订阅者、所有渠道（网页推送、应用推送、WhatsApp和实时聊天）以及第一天即可使用的完整Workflows引擎。这足以迁移您当前触发器堆栈中的三种模式之一，并在申请预算前证明架构的有效性。从免费套餐开始，并在不到一小时内完成第一个情境工作流。

如果您要从本文中记住一件事，那就是：触发式推送广告系列不再是通知。它是工作流。六个独立的触发器不加区分地运行，就是六个指向同一订阅者列表的管道，每个管道都对其他管道一无所知。

三个情境工作流，具有共享状态、决策分支、退出标准和链式交接，就是每个订阅者的一个旅程，有分支和边界。能够产生可辩护的每个工作流漏斗和可复利增长的重复购买率的营销自动化工作流，不是更长的触发器列表；而是更小、更精锐的情境旅程集。架构就是广告系列。触发器就是入口。