在您的PushEngage账户的某个地方，有一个购物车恢复滴灌营销活动已经发送了八个月。它仍然显示“活动”。自从创建它的人在春天调到别的团队后，没有人动过它。它的点击率几周以来一直在下滑——不是骤然下跌，只是每个月悄悄地损失一两个百分点——因为没有人再打开仪表板的那个标签页，所以没有人注意到。
您的自动化悄无声息地失败，而仪表板不会告诉您
在别处，有一个您为挽回客户序列构建的工作流。它也仍然被标记为活动。但是，一批订阅者在六月份进入了这个序列，但从未越过第二步，并且仍然停在那里——既没有转化，也没有退出，只是卡住了，除非您去寻找他们，否则他们是看不见的。
这正是滴灌营销活动和工作流审计对留存团队的真正意义：不是一个重新设计项目，不是一个重建项目，只是在缓慢的渗漏变成真正的漏损之前，抓住那些运行不佳的自动化。而且，这正是您现在可以通过聊天窗口而不是通过仪表板爬行来运行的检查类型，使用的是PushEngage MCP服务器内置的两个工具：pushengage_list_drip_campaigns和pushengage_list_workflows。两者都是只读的。它们会根据需要显示滴灌营销活动分析和工作流分析，告诉您哪些是活动的，哪些是暂停的，以及订阅者在哪里卡住了——修复工作仍然在仪表板上进行，但查找工作不再需要了。
大多数团队只有在订阅者抱怨或月度报告看起来不佳时，才会发现有问题的自动化。到那时，暂停的自动化和卡住的客户群通常已经存在了数周。本文中的审计旨在在这些情况发生之前同时发现它们。
滴灌营销活动和工作流是需要分别检查的两种不同事物
PushEngage 提供了两种不同的自动化对象，审计必须分别查看它们，因为它们失败的方式不同。
一个滴灌营销活动是一个线性的自动回复序列——一组固定的通知，按照预定的时间表按顺序触发（欢迎系列、注册后培育、固定节奏的重新参与序列）。它不分支。其中的每个订阅者都按相同的顺序接收相同的步骤。
一个工作流是一个分支自动化，具有入口条件、决策点和退出标准——当您需要处理购物车恢复序列时，它会根据订阅者是否点击而表现不同，或者当有人购买时停止的挽回客户流程。当逻辑需要比“发送这个，然后发送那个”更复杂时，大多数留存团队会选择PushEngage的PushEngage Workflows可视化构建器。
每个关于“审核营销自动化”的竞争对手指南都将这些视为可互换的——一个混合的“营销活动”列表供审查。它们并非如此。表现不佳的邮件序列通常是复制或时间问题，而邮件序列的分析（发送、查看、点击）足以发现它。表现不佳的工作流可能会导致订阅者堆积在一个永远无法解决的步骤上，而线性邮件序列甚至无法做到这一点——工作流分析需要完全不同的形状（进入、活动、完成、失败）来暴露这一点。分别检查它们，并为每个检查正确的数字，是找到正确的问题类型与错过它之间的区别。
如果您还没有设置邮件序列，PushEngage 关于配置邮件自动回复器的指南将引导您完成设置。本文假设您已经运行了一些邮件序列，并且需要知道它们是否仍在发挥作用。
审核邮件序列：pushengage_list_drip_campaigns
问您的助手一些类似的话：“列出我活跃的邮件序列及其分析。”pushengage_list_drip_campaigns 工具会返回与您提供的状态过滤器（活动或暂停）匹配的每个邮件序列，当您设置include_analytics时，每个序列都会附带发送、查看和点击的计数。
这样就可以一目了然地发现两种问题。第一种是状态漂移：一个您以为已暂停的营销活动实际上仍在运行，或者一个您以为在运行的营销活动自上次无人记得的设置更改以来一直处于暂停状态。第二种是缓慢衰退：一个仍在按计划发送的营销活动，但转化率只有以前的一小部分。
以下是使用说明性数字为一家中型市场的 Shopify 账户运行三个邮件序列的布局情况：
| 营销活动 | 状态 | 已发送 | 查看 | 点击 | 隐含点击率 |
|---|---|---|---|---|---|
| 购物车恢复邮件序列（3次触达） | 活动 | 4,820 | 3,110 | 96 | 3.1% |
| 欢迎系列 | 活动 | 6,340 | 4,290 | 258 | 6.0% |
| 挽回客户再参与 | 暂停 | 0 | 0 | 0 | — |
欢迎系列运行良好。挽回客户邮件序列已暂停——值得注意，因为如果这对您来说是新消息，那么本应收到再参与提示的订阅者却什么也没收到。但真正的发现是购物车恢复邮件序列：对于购物车放弃序列，3.1% 的点击率大约是精心安排的多触达序列应产生的点击率的一半。如果该营销活动以前运行在 6% 的水平，现在下降到 3%，那么这两个数字之间的差距就是每次发送时流失的已恢复购物车价值。一个每月发送 4,820 次的邮件序列，如果点击率损失一半，那不是四舍五入的误差——而是您在未决定的情况下停止恢复的特定、可量化的废弃购物车收入。
审核工作流：pushengage_list_workflows 和卡住的订阅者问题
工作流暴露了邮件序列无法出现的故障模式，因为线性序列没有分支可以迷失。工作流有——而这正是订阅者变得沉默的地方。
让您的助手说“列出我带有分析的活动工作流”。pushengage_list_workflows 工具会按状态筛选工作流，并将 include_analytics 设置为 true 时，每个工作流都会返回已进入、活动中、已完成、失败和目标完成的计数。
将这四个数字一起读出，就会出现一个单独的问题，而单独的参与度指标会完全隐藏这个问题。以一个说明性的挽回工作流为例：
- 已进入：在此期间，有 1,200 名订阅者触发了工作流的进入条件（30 天无活动）。
- 活动中：有 640 人仍在工作流中间，介于第一步和最后一步之间。
- 已完成：有 310 人到达终点并实现了目标（重复购买）。
- 失败：有 40 人在转化前触发了退出条件（已取消订阅、触发了抑制规则）。
将这些数字加起来：640 + 310 + 40 = 990。剩下大约 210 名订阅者进入了工作流，但既没有有意义的活动，也没有完成，也没有失败——这是一部分卡住的订阅者，很可能堆积在某个特定步骤，因为某个条件永远无法解决（由于损坏的细分引用而从未发送的通知，没有退出路径的等待步骤）。这 210 名卡住的订阅者是仅通过状态检查永远无法发现的泄漏点，因为工作流仍然显示“活动中”并且仍然在技术上运行。
这是工作流审核可以捕获的最有价值的一点，它特定于 PushEngage 的分支自动化工作方式——线性滴灌活动没有订阅者卡住的步骤。如果这部分卡住的订阅者代表了 30 多天无活动并可能通过有效的挽回序列回归的购物者，那么 1,200 名进入者和 990 名已解决者之间的差距就是您未看到的重复购买率，而不仅仅是停滞的自动化。
同样的计算也适用于购物车恢复工作流，而且风险更高，因为时间更紧迫。如果一个浏览放弃工作流显示 3,400 人进入但只有 2,100 人已解决（活动中加上已完成加上失败），那么 1,300 名订阅者的差距就是查看了产品、触发了工作流但从未收到本应让他们回来的通知的购物者——不是因为工作流完全失败，而是因为工作流中的某些东西悄悄地停止了他们的前进。滴灌活动的已发送/已查看/已点击数字永远不会暴露这一点；只有分支工作流的进入与已解决的数学计算才能。
对于在同一次检查中值得检查的相邻自动化类型——PushEngage 的 触发式广告系列 是根据实时行为而不是固定时间表或工作流的分支逻辑触发的，并且通常会馈送相同的 细分规则，这些规则决定了谁首先进入工作流。MCP 的 pushengage_list_workflows 工具不包括触发式广告系列，但完整的月度审查仍应大致了解它们。
数字实际上在告诉你什么
一旦您提取了滴灌广告系列分析和工作流分析，您就会看到一个简短的发现列表，而不是一堆仪表板选项卡。下一步是确定什么是紧急的，什么是仅仅需要清理的——这一点大多数审计清单都完全忽略了。
一种简单的方法来分类您发现的内容：
- 活跃且正在下降——紧急。一个仍在发送的滴灌或工作流，但转化率远低于其自身历史记录，每天都在亏损收入。首先修复文案、时机或细分。
- 活跃工作流中的卡住的订阅者——紧急。堆积在某个步骤中的订阅者既没有转化也没有退出；他们停留的时间越长，他们就越有可能完全无法触达。
- 已暂停但仍被其他地方引用——中等。一个已暂停的自动化，而其他流程仍然指向它（工作流分支假设它已激活），可能会为被路由到它的订阅者创建一个无声的死胡同。
- 已暂停的草稿，无依赖项——低。您会发现最常见的已暂停自动化之一只是一个没有人删除的旧测试；可以安全地保留它，或者在您有时间的时候清理它。
并非所有发现都需要相同的响应速度。一个本周有卡住的订阅者堆积的购物车恢复工作流，与一个已经悄悄下降了两个月的欢迎滴灌广告系列竞争关注——工作流通常会获胜，因为这些订阅者未得到解决的每一天都更接近于完全无法触达。相比之下，下降的滴灌广告系列在几周内已经损失了相同数量的收入；本周或下周修复它几乎不会改变计算结果。按泄漏增长的速度进行分类，而不是按您首先注意到的自动化进行分类。
需要明确说明的是：以上所有内容都是发现，而不是修复。pushengage_list_drip_campaigns 和 pushengage_list_workflows 是只读工具——它们告诉您哪些已激活，哪些已暂停，以及订阅者在哪里卡住，但它们都不能编辑广告系列、调整工作流步骤或更改状态。实际的修复——重写通知、重新指向损坏的细分引用、暂停下降的滴灌——仍然在 PushEngage 仪表板中进行。审计的目的是确切地告诉您去哪里以及为什么，这样您在仪表板上花费的十五分钟就可以花在两件重要的事情上，而不是盲目地滚动浏览您构建过的所有内容。
开始：将 Claude、Cursor 或 Claude Code 连接到 PushEngage
从聊天窗口运行此审计，首先将 PushEngage MCP 服务器连接到您使用的任何 AI 助手。将服务器添加到您客户端的 MCP 配置中——对于 Claude Desktop 或 Cursor，只需添加一个指向 npx -y @pushengage/mcp 的条目，因为不需要全局安装。重新启动客户端，然后要求它登录到 PushEngage：浏览器标签页会打开以授权连接，因此您的凭据永远不会通过助手本身传递。
授权后，请选择您要使用的网站，之后所有网站范围内的工具—包括pushengage_list_drip_campaigns和pushengage_list_workflows—都将默认使用该网站。有关完整的操作指南，包括配置文件路径和故障排除连接启动问题，请参阅完整的PushEngage MCP设置指南。
让审计成为一种五分钟的习惯，而不是一个季度项目
PushEngage 的运行量真实可靠 — 150 多个国家/地区的 25,000 多名企业主在一个给定的 30 天窗口期内通过该平台发送了超过 152 亿条通知。在这种规模下，一个悄悄地表现不佳一个月才被人注意到的滴灌活动或工作流，不仅仅是一个小失误；而是一个五分钟的检查本可以在第一周就发现的、可挽回的购物车价值或重复购买收入。
这就是为什么与其偶尔进行审计，不如经常进行审计的实际情况：一个卡住的工作流或一个下降的滴灌活动的成本会随着它在无人注意的情况下运行的每一天而累积，而审计本身花费的时间比你原本需要开会解释为什么上个季度的数字不佳要少。审计滴灌活动和工作流不需要日历提醒或专门的分析师 — 它只需要五分钟和你已经在这篇文章中看到的两个提示。
周一，让您的助手列出带有分析的滴灌活动和工作流，如果您正在权衡工作流或高级细分是否值得添加到您的设置中，请查看PushEngage 计划，然后去修复那个真正需要修复的问题。
