现在是周二上午9点，您正在查看一家GMV为3500万美元的商店的WooCommerce仪表板。上周Klaviyo挽回了4800美元的废弃购物车。未挽回的部分是46000美元。这个差距不是Klaviyo的问题。电子邮件的发送频率没问题。差距之所以存在，是因为电子邮件根本无法触达约三分之一的购物车放弃者：根本没有打开，预览窗格从未打开，收件箱里塞满了上周的订单确认。
WooCommerce购物车放弃推送通知通过与电子邮件序列并行运行，在不同的时间，以不同的格式，在不同的界面上，来缩小这个差距。
本文是WooCommerce留存经理实际需要的流程规范：确切的3条消息推送流程，确切的事件名称，确切的等待窗口，以利润美元为基础的折扣阶梯，在购物车转化那一刻停止流程的退出规则，以及您可以提交给财务部门的每笔购物车归因计算。
直接将其导入PushEngage，并在不到一小时内运行。挽回的购物车是已发现的收入，而不是付费收入，这就是整个留存/CAC论点的精髓。
为什么“推送优于邮件”的说法是错误的
大多数关于购物车放弃的文章都设置了一个虚假的二元对立。推送与邮件。短信与推送。WhatsApp 与前三者。那些能挽回 25-40% 被放弃购物车价值的中端 WooCommerce 商店并非只选择一种。它们是分层使用的。邮件触达那些每天查看两次邮件的用户。推送触达那些完全不查看邮件但会留意通知的桌面和移动用户。短信触达高价值购物车，因为消息必须在接下来的三十秒内送达。留存经理的工作是构建分层组合，而不是争论哪种单一渠道能获胜。
对于今天只运行邮件序列的 WooCommerce 商店来说，问题不在于“我是否应该切换到推送”。而在于“推送能在邮件已有的功能之上增加什么”。答案很简单。推送比打开邮件更快（首次触达的 60 分钟内会比典型邮件打开时间早一小时）。推送更难被忽略（没有预览窗格）。无论哪个渠道获得了转化功劳，推送都会在购买事件时结束。这些是附加属性，而不是替代品。
本文的其余部分都基于这个思路。下面的 3 条推送工作流假设您已经在 Klaviyo、Omnisend 或您使用的任何 ESP 中运行了 3-4 条邮件恢复序列。它与该序列协同工作，而不是取代它。
为什么 WooCommerce 对推送友好（以及它不友好的地方）
WooCommerce 触发了三个原生事件，使得整个过程变得易于处理。add_to_cart 在每次添加产品时触发。woocommerce_cart_updated 在购物车状态更改时触发。woocommerce_payment_complete 在付款完成后触发。
PushEngage WooCommerce 集成插件将这些映射到 PushEngage 的自定义事件 cart_abandoned（当购物车闲置超过放弃阈值时触发）和一个目标 purchase（付款完成后触发）。cart_abandoned 事件负载携带 cart_id、cart_value、cart_url（恢复链接）和产品列表。该负载成为工作流通知使用的变量源。
PushEngage 集成还处理购物车恢复。当用户点击推送通知时，他们会直接进入购物车，商品已填充好，而不是进入一个空的产品页面。这并非小细节：一个已恢复的购物车通过一键结账的转化率，大约是需要用户重新添加商品的已恢复购物车的 3 倍。
购物车恢复是 PushEngage 集成开箱即用的 WooCommerce 推送通知功能之一；在没有集成的平台上，留存团队必须手动构建恢复链接。
有一个特定于 WooCommerce 的陷阱需要指出来。使用平台外结账（Stripe Checkout、PayPal 托管结账、Mollie 托管、Klarna 托管）的商店在客户重定向回感谢页面之前，不会触发 woocommerce_payment_complete。如果该重定向从未发生（客户在付款后关闭 Stripe 托管页面上的浏览器标签页），工作流将无法知道购物车已转化。解决方法是在感谢重定向上设置一个目标跟踪像素，该像素会触发带有 cart_id 的 PushEngage purchase 目标。没有这个像素，工作流会不断向已付款的订阅者发送提醒，而这正是每个留存团队都想避免的失败模式。在启用工作流之前配置此像素。
两个额外的上下文说明。首先，本文档其余部分的工作流词汇（START、WAIT、DECISION、ACTION、END）在 PushEngage Workflows builder 中定义，并在父级电子商务文章中进行了详细介绍。其次，此 WooCommerce 购物车放弃工作流是本系列五种特定于 WooCommerce 的推送工作流之一；其他工作流（浏览放弃、降价、有货、购后）链接自结尾部分。
3 条消息的购物车放弃工作流程，端到端
这是核心。完整的购物车放弃工作流规范。
触发器和运行类型
- 触发器 (START)： PushEngage CustomEvent，
event_name = cart_abandoned，由 WooCommerce 集成在购物车闲置超过放弃阈值（通常是 60 分钟无活动）后触发。 - 运行类型：多个并行。一个订阅者在周二放弃购物车 A，在周五放弃购物车 B，将获得两个并发的工作流实例，每个购物车一个，每个都有自己的 cart_id。这一点至关重要：单一或多个顺序运行类型会阻止购物车 B 在购物车 A 的工作流完成时得到恢复，而再次放弃的返回客户将一无所获。
- 退出条件：目标
purchase匹配触发事件中的 cart_id。一旦 WooCommercepurchase目标为该购物车触发，工作流将为该订阅者取消，无论他们当前在旅程中的哪个位置。 - 静默时间：订阅者时区的晚上 10 点到早上 8 点，备用
reschedule。reschedule设置会将通知保留到当地时间早上 8:01，而不是直接发送，这符合大多数留存团队的偏好，因为被丢弃的通知也会从分析中消失。
流程
等待 1 小时 → 消息 1（无折扣）→ 等待 24 小时 → 决策：购物车是否仍然被放弃？→ 是路径：消息 2（9 折）→ 等待 48 小时 → 决策：购物车是否仍然被放弃？→ 是路径：消息 3（8 折 + 紧急性）→ 结束。
两个决策节点上的否路径都路由到退出（购物车在等待期间已转化，工作流任务已完成）。
通知文案
消息 1（放弃后 1 小时，无折扣）：
- 标题：
您遗留了东西 - 正文：
您的 {{event.data.product_name || cart}} 还在。想完成结账吗？ - URL:
{{event.data.cart_url}}
消息 2（放弃后 25 小时，9 折优惠）：
- 标题：
还在考虑吗？这里有九折优惠 - 正文：
您的 {{event.data.product_name || cart}} 仅需点击一下即可购买。结账时使用 SAVE10。 - URL:
{{event.data.cart_url}}?coupon=SAVE10
消息 3（放弃后 73 小时，8 折优惠，紧迫感）：
- 标题：
最后机会：您的购物车可享八折优惠 - 正文：
我们为您保留的 {{event.data.product_name || cart}} 还剩一天。SAVE20 代码将于今晚到期。 - URL:
{{event.data.cart_url}}?coupon=SAVE20
每个标题不超过 50 个字符，每个正文不超过 130 个字符，这样在 Chrome 桌面版、iOS Safari 16.4+ 和 Android Chrome 上显示时就不会被截断。|| 语法在产品名称变量缺失时提供备用方案。
为什么是 1 小时、25 小时和 73 小时
这三个等待时间并非随意设定。每个时间窗口都捕捉了不同的挽回心理。
1 小时。第一次触达在用户会话记忆消退之前，捕捉到“我先去别处看看价格”的放弃者。大多数能够挽回的购物车都会在第一个小时内完成。大多数在第一个小时后仍未转化的购物车，如果没有第二次触达将不会转化。30 分钟的第一次等待时间太急：它会打断客户正在进行的比较购物。4 小时的第一次等待时间太慢：购物车上下文已丢失。一小时处于临界点。
25 小时。第二次触达在第二天进行，故意设定为 25 小时而不是正好 24 小时，这样晚上放弃的用户就不会在收到第一条消息的同一小时收到第二条消息（大脑会认为这是垃圾邮件）。25 小时的等待时间会将第二次触达转移到晚上放弃者的次日早晨例行事务中，或者将早晨放弃者的次日晚上，这是 10% 折扣优惠的实际触达窗口。
73 小时。在购物车失效前的最后一次尝试。三天后，订阅者的意图要么已经通过其他渠道实现（在这种情况下，退出规则已经触发），要么已经完全停滞。20% 的折扣加上紧迫感是购物车失效前的最后一次有效推动。等待超过 96 小时会在保证的利润成本下导致挽回率急剧下降；在消息 2 之后短于 48 小时会训练订阅者等待折扣。
静默时段涵盖了整个序列。晚上 11 点放弃的用户的 1 小时第一次触达本应在午夜发送。当 `reschedule` 设置为早上 8:01 时，消息会推迟到第二天早上。购物车放弃工作流程将保持交付可问责状态，而不是在夜间悄悄发送。
折扣阶梯防御
折扣阶梯为 0% / 10% / 20%。显而易见的替代方案是在所有三次触达中提供统一的 15% 折扣。尽管统一折扣结构在原始恢复率上占优，但阶梯式折扣在净恢复收入上占优。以下是代表性 WooCommerce 中等市场规模的计算。
场景。 20万推送订阅用户。70%购物车放弃率。平均订单价值145美元。通过推送工作流追踪到每周约12,000个被放弃的购物车（在订阅用户与电子邮件重叠之后）。
所有三次触达统一15%折扣。 假设这会将原始恢复率提高到30%。这相当于每周恢复3,600个购物车，按145美元的平均订单价值计算，总收入为522,000美元。每个恢复的购物车都支付15%的折扣，因此净恢复收入为每周522,000美元 × 0.85 = 443,700美元。
0/10/20阶梯式折扣。 假设这会产生25%的原始恢复率（较低，因为第一条消息没有激励）。但恢复分布在三次触达中：12%在第一条消息（无折扣）上转化，8%在第二条消息（10%）上转化，5%在第三条消息（20%）上转化。每辆车的净收益：12% × 145美元 + 8% × 145美元 × 0.90 + 5% × 145美元 × 0.80 = 17.40美元 + 10.44美元 + 5.80美元 = 33.64美元/个被放弃的购物车。按12,000辆车计算，每周为403,680美元，略低于统一折扣。
但毛利率的现实更为严峻。大多数中型WooCommerce商店的毛利率在35-45%之间。统一的15%折扣会将利润率降至20-30%。第一条消息0%的转化率可以保持全部利润。运行阶梯式折扣的留存团队放弃了约3个百分点的恢复率（28% vs 31%），并恢复了更大比例的利润美元。净贡献利润，而不是总恢复收入，才是应该争取的正确数字。
阶梯式折扣的第二个论点是用户培训。一个列表如果持续在每次购物车提醒中都看到15%的折扣，就会学会等待折扣。下一季度的统一15%折扣恢复率会下降，因为用户已经学会了这种模式。0/10/20的阶梯式折扣保留了以全价转化的选项。
第三个论点是细分。在第一条消息上转化的用户是高意向客户，值得在下一次营销活动中进行不同的再营销。只在第三条消息上转化的用户对价格敏感，值得细分到以价格驱动的留存路径中。阶梯式折扣产生信号；统一折扣产生噪音。
每次购物车归因和挽回收入的计算
PushEngage中的推送工作流分析在每个节点跟踪三个数字：排队用户（在此节点等待）、完成用户（已通过）和退出用户（在此节点离开工作流，通常是因为触发了退出规则）。
以下是为在20万订阅用户、平均订单价值145美元的商店上运行的活跃WooCommerce购物车放弃工作流提供的节点级分析：
| 节点 | 排队中 | 已完成 | 已退出 | 备注 |
|---|---|---|---|---|
| 开始 (cart_abandoned) | 0 | 11,940 | 240 | 事件触发和工作流扫描之间有240个购物车已转化 |
| 等待1小时 | 220 | 11,720 | 0 | 正常队列深度 |
| 操作：消息1 | 0 | 11,720 | 0 | 已发送通知 |
| 等待24小时 | 280 | 9,290 | 2,150 | 2,150个购物车在消息1上转化（最高意向恢复） |
| 决策：是否仍被放弃？ | 0 | 9,290 | 0 | 剩余购物车根据目标进行检查 |
| 操作：消息2（10%折扣） | 0 | 9,290 | 0 | 已发送包含SAVE10的通知 |
| 等待48小时 | 120 | 7,460 | 1,710 | 1,710个购物车在消息2上转化 |
| 决策：是否仍被放弃？ | 0 | 7,460 | 0 | 最终检查 |
| 操作：消息3（20%折扣） | 0 | 7,460 | 0 | 已发送包含SAVE20的通知 |
| 结束 | 不适用 | 7,460 | 不适用 | 7,460 个购物车未通过推送恢复 |
通过推送恢复的总数：240（接触前）+ 2,150 + 1,710 = 4,100 个购物车。原始推送恢复率：4,100 / 12,180 = 33.7%。按 145 美元 AOV 计算的已恢复购物车价值为每周 594,500 美元毛利润。扣除阶梯折扣后（240 个购物车 0%，2,150 个购物车 0%，1,710 个购物车 10%），净收入为每周 570,795 美元。
按此方式阅读漏斗。两个等待（24 小时和 48 小时）是退出率最高的节点，这是正确的模式：客户在等待窗口期间决定购买，而不是在阅读通知时。如果您的工作流显示相反情况（操作节点退出率高，等待节点退出率低），则时间设置过长，应缩短等待时间。如果 START 节点显示异常高的退出率，则放弃阈值设置过短，您捕获的购物车实际上并未被放弃。
这是留存经理可以在下一次损益表审查中辩护的已恢复收入项目。WooCommerce 推送通知上周通过购物车放弃工作流恢复了 570,795 美元的净收入，每次推送发送成本为零，加上平台订阅费。每恢复美元的成本足够低，以至于财务部门不会提出后续问题。
多渠道协调：推送 + 电子邮件 + WhatsApp + 在线聊天
上面的 3 条消息推送工作流与电子邮件恢复序列并行运行。相同的架构也可以根据订阅者状态跨渠道升级。使用一个工作流引擎，旅程的构成如下：
- 开始： 带有 cart_id 和 cart_value 的
cart_abandoned事件 - 等待： 1 小时
- 决策 1： 订阅者是否订阅了网页推送？是：发送网页推送提醒；否：继续
- 等待： 30 分钟
- 决策 2： 推送是否已触发并被点击？是：结束；否：继续
- 决策 3： cart_value > 200 美元？是：发送 WhatsApp 消息；否：通过 HTTP 请求向 ESP 发送电子邮件
- 决策 4： 订阅者当前是否在网站上？是：触发实时聊天 ping；否：继续等待消息 2
- 在目标
purchase时结束
四个渠道，一个工作流，一组退出标准，一个订阅者身份。这是留存团队无法组合的编排，因为每个渠道都位于不同的工具中。使用单独的供应商，购物车工作流将变成六次同步，两个关于谁算作 VIP 的分歧细分引擎，以及没有统一的收入归因。
使用一个工作流引擎，旅程就是一个对象。有关在单个留存计划中如何组合推送和电子邮件的更多信息，请参阅关于推送和电子邮件多渠道编排的父文章。
侧边栏：通过您的人工智能助手管理购物车工作流程
通过 WordPress 插件 4.2.4 和 WordPress Abilities API，可以从任何支持 MCP 的 AI 助手管理购物车流程。该插件公开了 pushengage/list-push-automation-campaigns（返回当前的 WooCommerce 推送自动化配置）和 pushengage/update-push-automation-campaign（按 ID 启用、禁用或重新配置活动）。这两种能力都要求用户拥有 WordPress manage_options 权限，并且要求网站上激活了 WooCommerce。
对于运行 Claude、ChatGPT 或 Cursor 并公开了 PushEngage MCP 的留存经理来说，这意味着可以在计划的网站停机期间暂停购物车放弃工作流程，之后重新启用，或者重新配置以更换文案变体，而无需打开 WP 管理后台。更多信息请参阅 PushEngage AI 助手公告。
在 PushEngage 中构建
设置过程很短。在 WooCommerce 网站上安装 PushEngage 插件（它会自动检测 WooCommerce 并公开特定于 WooCommerce 的事件）。将插件连接到 PushEngage 帐户。在 PushEngage Workflows 构建器 中导入购物车放弃工作流程模板。
它预装了 1h / 25h / 73h 的时间设置、折扣阶梯占位符和退出购买规则。将占位符优惠券代码替换为您自己的真实代码。配置放弃阈值（大多数商店的默认 60 分钟是合理的）。激活工作流程。在扩展之前，观察前 200 个被放弃的购物车通过它进行处理。
如果这是商店中的第一个 PushEngage 工作流程，免费套餐将为您提供 200 个订阅者和完整的 Workflows 引擎，足以在请求付费套餐的预算之前，在受控列表中证明该渠道的有效性。从免费套餐开始，在本周运行第一个实例。
这改变了什么
本文是五篇 WooCommerce 特定推送工作流程规范之一。其他文章涵盖 WooCommerce 浏览放弃工作流程、降价提醒、补货通知和 WooCommerce 购后工作流程。有关更广泛的跨平台购物车放弃处理，更广泛的购物车放弃手册 在战略层面涵盖了该主题。
关于这在完整的电子商务留存计划中的位置，电子商务推送通知 中心文章是概述。
周二打开 WooCommerce 仪表板看到 46,000 美元未收回购物车款项的留存经理有一个选择。是继续优化已停滞的电子邮件序列，还是在其之上叠加推送作为第二个渠道，运行不同的时间、不同的格式、不同的退出规则。上面这个 3 封消息的工作流程，与已有的任何电子邮件节奏并行运行，可以收回电子邮件无法触及的 12-25% 的购物车价值。
通过 0/10/20 的折扣阶梯，恢复的收入比统一折扣的工作流程具有更高的净利润率。通过购买时退出规则，工作流程会在购物车转化时停止触发。通过按节点分析，该项目可以通过数字而非轶事向财务部门证明其合理性。这就是整个购物车放弃恢复论点，以及整个购物车恢复自动化论点，都包含在一个工作流程中。
