漏斗流失诊断:7 步定位流失点(Claude + GA4 实操)

71% 的流失。这是上个月一家 SaaS 客户的屏幕上跳出的数字——他转给我一张截图:12,400 个访问了定价页的访客,只有 3,580 个点了"开始免费试用",其中 1,022 个走完了账号注册。CEO 在截图上方发了四个字:"漏斗在哪儿漏的?"

面对这种情况,团队的本能是改东西——重写标题、重新设计表单、上新价格档位。我看过资金充足的团队就这么干 8 周,上线后才发现漏的其实是邮件验证步骤(压根没埋点)、4G 网络下 6 秒的移动端渲染、或者某个影响了 2% 用户、却把平均值严重拉偏的支付通道故障。

漏斗诊断不是创意题,是刑侦题。你要找的是某个特定步骤、某个特定分群中的某一个具体故障,唯一的办法就是不断从新角度切数据,直到某个角度告诉你点什么。GA4 的漏斗探索报告能给你漏斗的形状;Claude 用对提示词,几分钟就能完成本来需要一个分析师一个下午的交叉分段和假设生成。两件事加在一起,两小时之内你就能从"漏斗坏了"走到"我知道先修哪 8% 的用户"。

下面是我跑的 7 步流程。多数步骤都是交了学费才学会的。

步骤 1:把漏斗定义为事件,不是页面

漏斗分析里最大的坑,是把漏斗当作一串 URL 序列。基于页面的漏斗能告诉你"我们在 /pricing 和 /signup 之间丢了用户",但回答不了为什么——因为真正的原因都不在 URL 里。用户放弃,可能因为表单校验花了 9 秒,可能因为 6.1 寸屏幕上 CTA (Call To Action, 行动召唤) 按钮在首屏之外,可能因为会话过期,也可能因为价格在中途变了。所有这些信号都在事件里。

动手之前,先把你漏斗的 4-6 个事件按用户必须完成的顺序写下来。给一个 B2B SaaS 免费试用场景,我通常用这套:

1. view_pricing(自定义事件,定价页浏览时触发)
2. cta_click(事件,标签为"start_trial")
3. signup_start(首个字段聚焦或 /signup 浏览)
4. signup_submit(表单提交,成功或失败)
5. email_verified(自定义事件,点击验证链接时触发)
6. first_login(自定义事件,首次进入控制台)

如果这些自定义事件还没建,先建。漏斗开始漏了才装仪表,等于被盗了才装监控——用 GTM (Google Tag Manager) 的 dataLayer 推送,或者让工程直接发事件。这一步没得商量,通常开发花 2-4 小时。每分钟都值。

步骤 2:在 GA4 漏斗探索里搭好漏斗

打开 GA4,进 Explore → Funnel exploration,按顺序配好 6 步。这里几个设置多数人会配错:

• "Closed funnel" 只在确实需要时才勾。 封闭漏斗更严——跳过步骤的用户直接算流失。开放漏斗更宽松,通常也更贴近你业务真正关心的东西。默认开放,只有怀疑用户在钻步骤跳跃的空子(媒体类站点之外很少见)时才切到封闭。
• 回溯窗口(lookback window)要匹配你真实的转化周期。 7 天是 GA4 默认值,对慎重型购买几乎都太短。B2B 试用注册的中位验证时间是 3 天的话,把窗口设到 30 天,否则你会把大量合法用户错判成流失。
• 一开始就要加一个细分维度。 我习惯直接把 Device category(移动/平板/桌面)加上作为行维度。点两下就能回答"漏的是不是只发生在移动端"——这是流量偏移动的业务里最常见的答案。

保存后会看到一张 6 根柱子的图。第一件要做的事是把每两个相邻步骤之间的绝对流失率写下来。上面那个客户案例里,最差的是第 2 → 3 步(CTA 点击 → 注册开始),-71.2%。这个数字就是后面整次调查的焦点。

步骤 3:按流量来源做交叉分段

现在你已经知道"漏在哪儿",还要知道"是谁漏的"。最快的办法:再建一个漏斗探索,按 Session source / medium 拆分每一步。比较付费搜索、自然搜索、邮件、直链在漏点处的流失率。

我那个客户身上,拆分结果跟谁想的都不一样。付费搜索是 58% 流失,自然搜索 73%,邮件 64%——但付费搜索的体量是自然搜索的 4 倍,所以绝对值上付费搜索贡献了 71% 的流失用户。CEO 本能想看的是自然搜索(相对最差的渠道),但数字指向付费。这是 Claude 能极大加速的部分。

这个分段环节我用的提示词大致是:

你是一名漏斗分析师。下面是 GA4 漏斗探索报告的导出(附件 CSV),按会话来源/媒介拆分了漏点步骤。请识别:(1) 哪个分群绝对流失最高;(2) 哪个相对流失率最差;(3) 流失率超过渠道均值 1.5 倍的分群;(4) 我应该先查哪一个分群。输出简短 Bullet Brief,3-5 条即可。

Claude 通常 30-40 秒产出 Brief。"超过渠道均值 1.5 倍"这条规则是多数人会漏掉的——你容易盯着绝对值最扎眼的那个分群,但真正该追的是相对于自己渠道"反常"差的那一个。同样的数据,不同的镜头。

步骤 4:按设备、浏览器、操作系统做交叉分段

如果漏点扛过了来源/媒介这一关,下一个轴几乎总是设备。同样的分段方式,这次按 Device category 拆,然后 Browser,再 Operating system。多数 B2B 漏斗的答案都很刺眼:移动端流失率是桌面的 2-3 倍;移动端里面,内嵌浏览器(LinkedIn、Facebook、Twitter)再翻一倍。

上面那个客户,移动端占流量 61%,但贡献了 84% 的步骤 2 → 3 流失。移动端再按 Browser 拆,锁定一个真凶:Facebook 的内嵌浏览器。在 Facebook 内嵌浏览器里,从 cta_click 到 signup_start 的流失率是 91%,Safari 移动端 67%,Chrome 移动端 62%。

这是 Facebook 内嵌浏览器一个已知问题——它会剥掉某些 JavaScript 行为、不支持特定的 window.open 模式、session-storage 行为也不同。这些在 URL 漏斗里根本看不到。整个调查从打开设备拆分的瞬间到结束,用了 18 分钟。修法是检测到 Facebook 内嵌浏览器,强制用用户默认浏览器打开注册页。结果是这一分群的步骤 2 → 3 流失在第一周从 91% 降到 71%。不算完美,但 30 天内多回收了 218 个净注册。CEO 这次回的邮件不止四个字了。

步骤 5:加上定性这一层

定量数据告诉你"在哪",不告诉你"为什么"。到第 4 步你已经有一个紧凑的假设——"Facebook 内嵌浏览器把注册流程搞坏了"——但还需要确认原因就是你以为的那个,而不是恰好相关的另一个原因。多数分析师停在这里,多数分析师也修错了。

按下面这个成本从低到高的顺序,拉三类定性数据:

1. 会话录像(有的话)——Microsoft Clarity 免费,而且支持 4 事件的自定义触发器。看 10-15 段漏点分群的会话。不要总结,直接看。91% 流失的真正原因,通常前 4 秒就看得见。
2. 页内调研(Hotjar 的一道单选题,或者两字段表单,只在到达漏点步骤的用户上触发)。问:"是什么阻止你完成这一步?"开放回答很快聚类。5 条"我被重定向回 Facebook"就够了。
3. 过滤到漏点步骤的客服工单和聊天记录。同一分群出现"页面坏了""注册不了"这种话术的尖峰,就是直接确认。

那个客户身上,会话录像里 12 段看了 11 段都是同一个模式:CTA 点击在 Facebook 剥掉了功能的浏览器里打开了注册 URL,页面渲染了,但表单的第一个 focus 事件永远不触发。工程侧确认是 react-hook-form(一个 React 表单库)在 Facebook WebView 里初始化 state 时的已知兼容问题。定性层不只是确认了假设——它直接告诉工程改哪一行。

步骤 6:用 Claude 起草可被验证的假设

到第 6 步,你心里应该已经有了一个成型理论,但它还在脑子里。把它拿出来。我用一个 Claude Prompt 把诊断压缩成一条可被验证的假设,带明确的通过/失败标准。结构跟我做活动复盘用的是同一个:

给定以下漏斗数据、会话录像观察和定性反馈,请起草一条可验证的假设。格式:(1) 判断——一句话,陈述我认为正在发生什么;(2) 证据——3 条 Bullet,引用数据和观察;(3) 反证——这条假设最有力的反对论据是什么;(4) 测试——一个 7 天的实验来确认或证伪,带明确的"确认"指标阈值;(5) 负责人——测试的单一负责人。控制在 200 字以内。

"反证"这一段是我加了以后才补上的——看过太多"诊断"最后变成确认偏见的。强迫模型(和你自己)把"最可能错在哪里"写出来,能拦下我大概三分之一的原本会直接交付的假设。那个客户身上,反证是:"也许 Facebook 内嵌浏览器用户本来就质量更低——广告定向带来的就是低意向用户。" 真实存在的可能。测试方案是:让 Facebook 内嵌用户走深链修复、用系统默认浏览器打开注册页的那一拨,跟控制组里同一分群比完成率。如果修复后内嵌完成率能追到跟桌面相差 5 个百分点以内,浏览器就是原因;追不到,定向就是原因。

步骤 7:跑测试,把经验沉淀下来

假设被测试证实,就把修复上线、重新测。如果没被证实,不要回去跟数据较劲——直接回到第 4 步换另一个分段角度。失败的假设本身也是结果:它告诉你原因藏在你还没检查的那个轴上,下一轮的可疑范围就缩窄了。

测试无论通过还是失败,都写一页"经验"——不是复盘,就是一张 A4:原始漏斗、漏点步骤、集中的分群、假设、测试、结果、以及你新加的"永久埋点",让这个漏点不可能再悄悄回来。最后这条 Bullet 最关键。一次漏斗诊断如果落不在埋点上,就是一次性修复,不是体系。我看过的大多数"我们把漏斗修好了"的故事,18 个月后同一根漏斗又坏了,因为没人想到加告警。

那个客户身上,修复上线后,这个分群的流失率从 91% 降到 71%,我们顺手在 Looker Studio 里设了一条告警:Facebook 内嵌的步骤 2 → 3 流失率一旦回到 80% 以上就告警。这条告警后来帮他们躲过两次回滚:一次是某个 JS 库升级又把 focus 事件搞坏了,一次是他们的广告代理在没人知道的情况下,把 Facebook 这条 campaign 重定向到了更冷的人群。两次告警都在每日站会前就触发了。

两个我总在踩的坑

即使有这套框架,我还是会犯同样两个错。第一个是在第一个看似合理的原因处就停下诊断。91% 的流失很扎眼,一旦找到一个分群是罪魁祸首,大脑就宣布胜利。忍住。漏斗里最贵的问题,往往藏在第一个原因背后的第二、第三个原因。第 4 步看着已经够有结论了,也一定要跑第 5 步——定性层,正是把"假设"和"事实"区分开的东西。

第二个是忽略那些"太小"的分群。GA4 有时会告诉你某个操作系统版本或浏览器版本 100% 流失,但只有 47 个用户。很容易当噪声丢一边。别丢。47 个用户的 100% 流失,还是 47 个流失;而这 47 个用户有时候是早期采用者、媒体、或者高价值客户,他们的口碑比这次转化本身更值钱。相对流失率超过渠道均值 2 倍的,不管绝对体量,都查。绝对体量告诉你"急不急",相对率告诉你"是不是真的"。

漏斗诊断的目标不是找到这一次的漏点。是搭一套系统,让它能在你的 CEO 发问之前,自己找到下一个。