周一早上，一家 GMV 为 2000 万美元的 WooCommerce 家居用品店，留存经理正在查看 Google Analytics 中上周的漏斗数据。产品详情页浏览量：180,000。加购量：18,000。购买量：1,800。Klaviyo 仪表板显示上周挽回了 3,200 美元的购物车放弃金额。
同一仪表板上的浏览放弃（browse-abandonment）数据为零，因为 Klaviyo 无法触达浏览放弃者。没有为他们捕获电子邮件。他们访问了产品详情页，未加入购物车，然后离开。本周有 162,000 名访客对电子邮件来说是隐形的。
这就是 WooCommerce 浏览放弃推送通知旨在覆盖的受众。网页推送的 opt-in 在首次合格访问时触发，而不是在购物车阶段捕获电子邮件时触发。仅仅是这个时间点的差异，就意味着那些从未输入过电子邮件地址的浏览放弃者仍然是可触达的。
一个带有正确退出逻辑的 3 消息工作流可以将其中 8-14% 的用户转化为加购，这对于每周 162,000 名访客的网站来说，是在下次损益表审查时留存团队可以辩护的一项收入。本文的其余部分将详细介绍该工作流、WooCommerce 技术栈所需的精确事件跟踪，以及在三种列表规模下的留存数据分析。
浏览放弃不同于购物车放弃，也不同于会话放弃
简要说明定义，因为搜索引擎结果页（SERP）会混淆这三者。浏览放弃是指在 30 分钟内查看了产品详情页但未加入购物车。购物车放弃是指已加入购物车但未完成结账。会话放弃是指一次访问从未到达过产品详情页。每种都有不同的触发器、不同的受众规模和不同的工作流。
规模差异是关键。在一个典型的中型 WooCommerce 商店中，每有一个购物车放弃者，就有五到八个浏览放弃者。电子邮件可以很好地服务于购物车放弃漏斗，因为客户在尝试结账时捕获了他们的地址。但电子邮件完全无法服务于浏览放弃漏斗，因为没有捕获到电子邮件。这就是为什么产品页面放弃挽回一直是大多数留存工具中被忽视且不经济的部分。推送解决了地址可达性问题，因为 opt-in 事件是浏览器原生的对话框，在首次合格访问时触发。
| 漏斗阶段 | 触发事件 | GMV 为 2000 万美元的商店的典型每周流量 | 继承工作流 |
|---|---|---|---|
| 会话放弃 | page_view（任意页面） | 非常高，嘈杂 | 不推荐任何操作 |
| 浏览放弃 | 30 分钟内，在产品详情页 page_view 但无 add_to_cart | 144,000 | 本文中的浏览工作流 |
| 购物车放弃 | 60 分钟内 add_to_cart 但无 purchase | 18,000 | 购物车放弃工作流 |
浏览工作流在浏览放弃者添加到购物车的那一刻会进入购物车工作流。这种交接很重要，但在大多数浏览内容中却被忽略了。这两个工作流共享一个事件分类法，并且每当第三次互动发生时，购物车工作流就会继承来自浏览工作流的部分限定的订阅者。
为什么推送是浏览放弃唯一实用的渠道
电子邮件需要一个电子邮件地址。WooCommerce 网站上的浏览放弃者还没有。PushEngage 选择加入对话框在第二次页面浏览或可配置的参与信号后触发，一旦接受，订阅者就可以在他们的设备生命周期内被触达，而无需提供您的地址。这是使浏览恢复自动化在经济上可行的操作假设。WooCommerce 推送通知以其他渠道无法企及的成本触达匿名访问者。
其他选项的经济效益在浏览放弃量下无法通过损益表审查。Meta 和 Google Ads 上的付费再营销按每千次展示收费，并为每次您重新触达的浏览放弃者消耗获客成本预算，无论他们是否转化。短信需要电话号码，这比浏览阶段的电子邮件更不可能。
电子邮件需要电子邮件。推送，在一次选择加入后，每次发送成本接近零。对于一个拥有 200,000 名订阅者的 WooCommerce 列表，浏览放弃发送的边际成本实际上是推送服务提供商为交付基础设施收取的几分之一美分，而不是按消息计费的费用。
留存/获客成本的计算由此而来。对于恢复的相同收入，推送上的浏览恢复自动化成本仅为付费再营销替代方案的一小部分。这就是该项目的论据，它存在于 WooCommerce 堆栈上，因为 WooCommerce 商店倾向于拥有即开箱即用的、为 page_view 跟踪精心设计的商品详情页面。
3 消息浏览放弃工作流
这是完整的工作流。触发器：一个 PushEngage 自定义事件 page_view，筛选条件为商品详情页面（其中 is_product = true），并且订阅者在三十分钟内没有触发 add_to_cart。运行类型：多个并行，因此一个会话中浏览五个不同产品的订阅者可以有五个并发的工作流实例，每个实例都指向正确的产品。退出条件：目标 add_to_cart（购物车工作流继承）或 purchase（无需进一步消息传递）。
蓝图 — 3 消息浏览放弃工作流
- 开始：自定义事件
page_view，筛选条件is_product = true，并且在 30 分钟内来自同一订阅者的add_to_cart为否 - 等待： 30 分钟
- 决策 1：订阅者当前是否在网站上活跃（
session_activity标志在过去 5 分钟内设置）？- 是路径：退出（不要中断活动会话；工作流将在新触发器上重新评估）
- 否路径：继续
- ACTION (消息 1): 发送网络推送，提醒用户查看过的特定产品。标题：“还在想 {{event.data.product_title}} 吗？” 正文：“它就在你离开的地方。点击即可取回。” URL：产品页面 URL。图片：
{{event.data.product_image}}。 - 等待： 4 小时
- 决策 2： 用户是否将产品添加到购物车？
- 是路径：退出（购物车放弃工作流继承）
- 否路径：继续
- ACTION (消息 2): 发送包含相关产品的网络推送。标题：“您可能也喜欢我们 {{event.data.category}} 系列中的这些。” 正文：“三款与 {{event.data.product_title}} 相似的精选产品。” URL：WooCommerce 分类存档页面。图片：第一个相关产品图片。
- 等待： 48 小时
- ACTION (消息 3): 发送包含折扣发现框架的网络推送。标题：“看中了这个。” 正文：“我们为您保留了它，享受 9 折优惠。代码：BROWSE10。” URL：预先应用了折扣代码的产品页面 URL。
- 结束
这就是整个浏览放弃工作流。三个消息，两个带有决策的等待，一个静默退出分支，两个基于目标的退出。消息 1 和消息 3 中的产品浏览通知分别推送原始浏览产品；消息 2 转向相关产品，因为在浏览后的 4 小时内，提醒疲劳是真实的，发现是促成转化的杠杆。接下来的两个 H2 将深入探讨“仍在浏览”退出和相关产品杠杆，因为这两者都是 SERP 上最大的未被充分利用的细节。
关于运行类型的说明。并行运行最适合浏览放弃，因为单个用户可以在四十分钟的会话中浏览放弃五个产品，每个产品都有自己的工作流实例和产品上下文。PushEngage 工作流引擎会跟踪每个实例的 entry_flag 时间戳，因此这五个实例不会发生冲突。如果您将此工作流设置为单次运行，则五个产品中只有一个会得到恢复触达，而其他四个将静默处理。
“仍在浏览”退出分支
这是关键词所有页面一结果中最常被忽略的细节。大多数浏览放弃文章告诉您在三十分钟时发送消息，仅此而已。该建议会给活跃的购物者带来噪音，并侵蚀渠道。在第三十一分钟仍在网站上的用户不需要关于他们当前正在查看的产品的通知。他们需要被允许完成会话。
三十分钟等待处的决策节点解决了这个问题。它读取用户配置文件上的 session_activity 心跳属性。如果属性时间戳在过去五分钟内，工作流将静默退出。用户不会因为在网站上而被处罚。下次他们离开时，下一个产品详情页面的浏览将重新触发，并以最新的上下文启动一个新的工作流实例。这是在浏览放弃工作流中添加的最重要的一点，但大多数团队在发布时都没有包含它。
实现很简单。PushEngage JavaScript SDK 可以在页面在前台时每五分钟触发一次心跳自定义事件，该事件通过 Workflows 引擎的 UpdateAttribute 操作写入订购者属性。DECISION 节点的受众过滤器随后读取 subscriber.attributes.session_active_at 并与 now() - 5min 进行比较。受众过滤器记录在 PushEngage Workflows 的 decision-logic 参考文档中。
对于仍在浏览的退出场景，留存案例很简单。匿名浏览放弃者如果仍在网站上，则表明用户有活跃意图，此时推送通知不是合适的工具。让他们完成会话可以保留频道的送达率分数，保持较低的退订率，并将工作流的发送集中在实际能通过推送产生效果的细分受众上。浏览恢复自动化能否成功，取决于这种纪律。
关联产品杠杆（消息 2）
消息 2 不会推送订购者已查看过的相同产品。它会推送精选的相关产品列表，因为在原始浏览四小时后，提醒疲劳已经出现，客户要么已经回来，要么不会再回来购买特定商品。此时的重点是发现，而不是提醒。
WooCommerce 让这一切变得简单。该平台将 wc_get_related_products 作为内置函数提供，该函数与产品分类相关联。该函数返回与所查看产品相关联的追加销售、交叉销售和类别相似产品。PushEngage WooCommerce 集成插件可以将这些作为事件数据变量传递到工作流中，因此消息 2 的通知可以渲染相关产品的标题、图片和 URL，而无需单独的 API 调用。典型的消息 2 文案：“您可能也喜欢我们 {{event.data.category}} 系列中的这些产品。”
这是 WooCommerce 的特定优势。在没有内置相关产品分类的平台上运行的商店，必须在工作流触发时计算相关性，这意味着需要自定义推荐服务。WooCommerce 商店可以从平台免费获得此功能。拥有广泛 SKU 目录的中型 WooCommerce 商店从消息 2 中获得的最大收益，是因为相关产品表面足够宽，可以找到订购者真正想要的第二件产品。目录狭窄的商店在此处获得的收益较少，可能会将消息 2 和 3 合并为 24 小时的一次折扣发现触达。
这种模式很重要，因为仅提醒的浏览放弃转化率上限很低，这是 SERP 的默认行为。添加发现触达可使工作流的已恢复购物车比率提高 30-50%，前提是商店已填充相关产品分类，而大多数 WooCommerce 安装都已填充，无论营销人员是否知道。
WooCommerce 技术栈上的浏览放弃数据
三个事件输入为工作流提供动力。以下是每个事件的来源以及从零开始安装的顺序。
事件 1, page_view 附带 product_id。 从 PushEngage JavaScript SDK 在每个产品详情页触发。最小负载为 { event_name: 'page_view', product_id: '...' }；推荐负载还包括 product_title、product_image 和 category，以便工作流在消息 1、2 和 3 中渲染它们，而无需进行第二次 API 调用。请先安装此项，因为浏览工作流触发器依赖于它。
事件 2, add_to_cart。 从 WooCommerce-PushEngage 集成插件触发，该插件挂钩 woocommerce_add_to_cart WordPress 操作。请第二个安装此项，因为工作流的 DECISION 2（以及工作流的退出条件）会读取此事件。如果您延迟安装集成插件，浏览工作流仍会运行；它只是无法顺利继承到购物车工作流中。
事件 3, session_activity 心跳。 PushEngage SDK 在页面在前台时每五分钟触发一次的自定义事件。更新订阅者属性 session_active_at。请第三个安装此项。没有它，浏览工作流也会优雅地降级：30 分钟的等待时间仍然适用，并且消息 1 仍然会触发，但仍在浏览的退出分支无法触发，并且活跃的购物者有时会在会话中收到通知。这是可选的优化步骤。
大多数安装了 PushEngage 插件的 WooCommerce 商店在入职期间可以免费获得事件 1 和 2。session_activity 心跳是可选的第三个事件，可将工作流从“良好”提升为“SERP 上最佳”。推迟工程工作的商店可以在第一周发布带有事件 1 和 2 的工作流，并在第三周添加心跳。
每个工作流的分析：阅读漏斗
PushEngage 工作流会在每个节点跟踪排队、已完成和已退出的用户。对于一个拥有 200,000 名订阅者的 WooCommerce 商店，每周约有 30,000 次产品详情页浏览量（说明性数字），浏览放弃的漏斗如下所示：
| 节点 | 排队中 | 已完成 | 已退出 | 备注 |
|---|---|---|---|---|
| 开始（page_view 过滤器） | 0 | 28,000 | 0 | 本周进入工作流的订阅者 |
| 等待 30 分钟 | 850 | 27,150 | 0 | 正常队列深度 |
| 决策 1（仍在浏览？） | 0 | 21,800 | 5,350 | 5,350 个活跃会话已静默退出 |
| 操作 消息 1 | 0 | 21,800 | 0 | 已发送提醒 |
| 等待 4 小时 | 280 | 18,520 | 3,000 | 3,000 名订阅者已添加到购物车（购物车工作流继承） |
| 决策 2（已添加到购物车？） | 0 | 18,520 | 0 | 所有剩余的仅仍在浏览 |
| 操作 消息 2 | 0 | 18,520 | 0 | 已发送相关产品 |
| 等待 48 小时 | 600 | 16,300 | 2,220 | 在接下来的两天内添加了 2,220 件到购物车 |
| 操作 消息 3 | 0 | 16,300 | 0 | 已发送折扣发现 |
| 结束 | 不适用 | 16,300 | 不适用 | 未添加到购物车 |
在此漏斗中，有 5,220 名订阅者（3,000 + 2,220）在浏览工作流中将商品加入购物车，在进入浏览工作流的 28,000 人中，浏览到购物车的转化率为 18.6%。在这些加入购物车的用户中，购物车放弃工作流会进一步挽回一部分用户完成购买。高退出节点是两个等待节点，这是预期的模式：决策时间发生在等待窗口内，而不是操作窗口内。在 DECISION 1 节点处的“仍在浏览”退出节点又贡献了 5,350 个静默退出的活跃会话；如果没有这个分支，这些订阅者将在会话中收到消息 1，从而削弱该渠道的效果。
挽回的收入计算会随着列表大小而扩展。在 50,000 名订阅者的列表中，相同的工��流产生的数字大约是这些数字的四分之一；在 1,000,000 名订阅者的列表中，它产生的数字大约是五倍。每条消息的发送成本在此过程中基本保持为零，这是该渠道的结构性优势。
| 列表大小 | 每周产品详情浏览量 | 每周进入工作流的浏览放弃者 | 每周挽回的加购量 (18.6%) | 估算的挽回收入（按 85 美元平均客单价 × 15% 成交率计算） |
|---|---|---|---|---|
| 50,000 | 7,500 | 7,000 | 1,300 | $16,600 |
| 200,000 | 30,000 | 28,000 | 5,220 | $66,500 |
| 1,000,000 | 150,000 | 140,000 | 26,000 | $331,500 |
这些是指导性数据；您商店的实际提升效果取决于平均客单价、品类组合以及挽回的加购商品的成交率。关键在于，该计算会随着列表大小而复利增长，而每条消息的发送成本则不会。
在 PushEngage 工作流中构建
浏览放弃工作流直接映射到 PushEngage Workflows 组件。以下是映射关系：
| 工作流组件 | 使用的节点类型 | 使用的操作类型 | 工作流选项 |
|---|---|---|---|
| 3 消息浏览放弃工作流 | 开始、等待、决策、操作、退出、结束 | 发送推送通知 | 运行类型：多并行；在达到 add_to_cart 或 purchase 目标时退出 |
Workflows 引擎附带 60 多个预制模板，涵盖包括浏览和购物车放弃在内的电子商务流程。浏览放弃模板是正确的起点；克隆它，替换您的 WooCommerce 品类和产品变量，即可在一小时内通过 PushEngage Workflows 构建器上线该工作流。
这改变了什么
为了更广泛地了解此工作流如何融入完整的 WooCommerce 留存计划，电子商务推送通知中心涵盖了此工作流实现的广告系列类型，而现有的 浏览放弃广告系列帖子则提供了关于更广泛主题的策略调查。当浏览工作流上线后，姊妹篇 WooCommerce 购物车放弃工作流是自然的下一步；它在消息 1 或消息 2 促成加购的那一刻继承了订阅者。 PushEngage 购物车放弃恢复序列涵盖了那里的剧本细节。对于与电子邮件并行运行推送的多渠道团队来说，多渠道推送和电子邮件帖子解决了编排问题。
如果这篇文章有一个数字值得你记住，那就是 162,000。这是单个 GMV 达 2000 万美元的 WooCommerce 商店每周的浏览放弃受众数量，其中几乎没有人拥有你可以联系到的电子邮件地址。电子邮件和短信无法触达这部分受众。付费再营销可以，但其客户获取成本 (CAC) 会随着留存率的提高而累积。WooCommerce 浏览放弃推送通知以近乎零的每发送成本触达相同的受众，其工作流程可在下午完成，并且有一个仍在浏览的退出分支，可以保持渠道的可送达性。
留存的数学计算使得这一项具有可辩护性。对于一个拥有 20 万订阅者的列表，采用上述工作流程，在典型的中端市场平均订单价值 (AOV) 下，预期的每周挽回收入约为 66,500 美元。这个数字会随着列表大小线性扩展，而每发送成本保持在近乎零的水平。首先是浏览放弃工作流程，然后是继承它的购物车放弃工作流程，最后是围绕这两个工作流程组合的其余 WooCommerce 留存堆栈。
免费套餐在第一天就为你提供 200 个订阅者、所有渠道以及完整的工作流程引擎。这足以在请求预算之前，对 page_view 事件进行检测，部署工作流程，并观察一周的漏斗。 从免费套餐开始，在本周五之前完成此工作流程的消息 1 的发送。
