起始人数多但转化低？漏斗拆解的三刀方法

作者：456数据发布：2026-09-30 16:22 浏览量：0 来源：原创

我负责增长之后，被问得最多的一个问题是：“落地页每天来了大几千人，最后下载成功的就几十个，转化率怎么这么低？”每次我都不急着回答，而是先拉一个真实用户出来，陪他从头走一遍。假设这个用户叫小A，他今天点了广告进来，我们就跟在他身后，看他到底在哪一步走丢的。整体转化率只是一个把所有问题压缩在一起的数字，它本身不告诉你病因；只有沿着用户旅程一步步拆开，才知道该从哪里下手。

这篇文章要拆的就是一件事：起始人数很多、最终转化很低的时候，该从哪三个方向去拆。之所以限定在这三刀，是因为跳步归因、跨日转化、同一用户重复触发这些问题，属于另外的分析主题，混在一起只会让口径更乱。我们先把眼前这一个完整旅程拆清楚。

入口很宽、底部很窄的漏斗：整体转化率低，但问题可能出在入口、步骤或完成口径任意一处

先陪小A把一次完整转化走一遍

小A的旅程很典型：他先从广告点进落地页，这是漏斗的第一步；在落地页上他点了“立即下载”按钮，这是第二步；接着跳转到下载/注册页，他填了表单，这是第三步；最后点提交、看到成功页，这才算完成。我们把这四步串成一个漏斗，每一步都记人数。每一步都有人中途离开，人数自然从上到下逐级收窄，形状像一个漏斗。

整体转化率的算法很直接：整体转化率 = 最后一步成功人数 ÷ 第一步进入人数 × 100%。但这个数字之所以危险，是因为它把“入口进来的人本来对不对”“每一步在哪掉的”“到底什么才算成功”这三件事全揉在了一起。要判断该优化哪里，就得把这三件事分开看。

漏斗步骤	人数（示例）	步内转化率	累计转化率
① 进入落地页	10000	—	100%
② 点击下载按钮	3000	30.0%	30.0%
③ 提交表单	900	30.0%	9.0%
④ 完成下载	450	50.0%	4.5%

这张示例表里，整体转化率是4.5%。但单看这个4.5%，你根本不知道该去改落地页、改表单还是改成功逻辑。我在漏斗工具里一拉，步内转化率逐段标出来，就知道是哪一步在掉。不同步骤掉得最多，对应的是完全不同的优化方向，必须再往下拆。

这里我想顺手纠正一个常见误解：很多人看到转化率低，第一反应是“把落地页改得更吸引人”。但在示例里，真正的问题腰在第二步到第三步，也就是用户已经被吸引到愿意点下载、却在提交表单时大量离开。入口已经成功把人吸引进来了，再去改落地页的文案，对那个最窄的腰帮助有限。之所以会犯这种方向性错误，往往是只看了整体数字、没有逐段看流失。

整体转化低，先拆三个地方

我拆解一个转化漏斗时，固定先下三刀。这三刀分别对应入口、过程和出口。转化率低，无外乎三种情况：入口进来的人不对、中间某一步掉太多、或者成功这件事本身没数对。

第一刀：看入口流量质量

先看第一步进来的人，和你想要的用户是不是一类。广告投放在不同渠道、不同创意上，点进来的人意图差别很大：有的是真想下载，有的只是误点。入口里混进大量误点和非目标用户，第一步到第二步的点击转化天然就低。先看入口，是因为流量本身不精准的话，后面每一步再怎么优化，整体转化率也被入口基数压着。

第二刀：看每一步的流失率

再把每相邻两步之间的流失率单独算出来，找出掉得最狠的那一步。在上面的示例里，第二步到第三步从3000掉到900，流失了七成，是整条漏斗最窄的腰。流失率最高的那一步，通常就是体验或设计出问题的地方，优先要查的就是它，而不是平均用力地改每一页。

第三刀：看有效完成事件的口径

最后确认“完成下载”这个事件到底在什么时候上报。有的团队把点击提交就算成功，有的却要等真正下载完成、甚至安装打开才算。完成事件的上报时机不同，最后一步的人数会差出一大截，整体转化率也跟着变。在动手优化之前，必须先确认成功口径和业务想要的“真转化”是一回事，否则你优化的可能是一个被错误口径压低的数字。我见过最典型的乌龙，是前端在下载按钮上就埋了成功事件，后台却以为那是真正完成，结果转化率虚高了一倍，等核对完真实下载事件才发现之前的“增长”根本不存在。

拆解整体转化的三列框架：入口流量质量、每步流失率、有效完成口径

拆解方向	要回答的问题	怎么看	发现问题后指向
入口流量质量	进来的人是目标用户吗	按渠道/创意分漏斗，看首步到二步差异	调整投放定向，而非改页面
每步流失率	哪一步掉得最多	计算相邻两步间的步内转化率	优先优化流失最高的那一步
有效完成口径	什么才算真的成功	核对完成事件的上报时机与触发点	先校准口径，再谈优化

三刀拆完，漏斗长什么样

把这三刀都下完，那张宽口窄底的漏斗就不再是一个笼统的4.5%，而是变成了一张能定位问题的图。你会看到：哪条渠道的首步到二步特别低，说明入口流量不精准；哪一步之间突然收窄，说明那一步的页面或流程有阻力；最后一步的人数和你预期差很多，多半是完成口径没对齐。每一步都对应一个可验证的假设，接下来的动作也就有了优先级。

我想强调的是，这三刀只负责“定位问题在哪”，不负责“为什么这一步掉”。比如定位到表单那一步流失最高之后，到底是表单太长、报错不明显还是加载太慢，那是下一层结合页面行为和性能数据再去查的事。之所以要把边界说清楚，是因为漏斗工具本身告诉你哪一步在漏，漏的原因还需要回到那个具体页面去看。把“定位问题”和“解释原因”分成两步，拆解才不会越拆越乱。

在漏斗每一步标注步内转化率，把流失最严重的那一步标出来作为优化优先级

三种取数方式的差异

上面这套陪小A走一遍、逐段算流失、核对完成口径的做法，落到具体工具上通常有三条路：自己写代码埋点和数仓、用网站或 App 自带的后台看板、用第三方分析平台。三条路在接入成本、去重口径、跨端统一、实时性和维护成本上的差别，大致如下表。

对比维度	自建埋点/代码方案	网站/App原生后台	456数据
接入成本	要为落地页点击、按钮、表单提交、成功页四步分别上报事件并建数仓，周期以周计	后台默认开通，零接入	嵌入一段 SDK，按文档把这四步事件串成一条漏斗即可
去重口径	每步按谁算转化全凭自己定义，同一个人在一步里反复点也容易被重复计数，虚高虚低都得自己兜底	通常只给来源与 PV/UV，按人次而非按去重用户还原逐步路径	漏斗每一步都按去重用户算转化率，同一个人在一步内多次触发不会重复计步（具体口径以产品文档为准）
跨端统一	要自己做多端 ID 映射，网站和 App 漏斗才能合并	网站和 App 后台各自独立，漏斗数据不通	多端用户合并后，网站和 App 进同一条漏斗
实时性	看自己数仓几点出表	自带后台多为 T+1 或准实时	看板更新频率以实际配置为准，当天可看每步流失变化
维护成本	每加一个漏斗节点、改一次事件名都要前后端同步改动并回验	不用维护，多步漏斗它天生做不了	平台侧持续发版、不用研发排期，自己只维护漏斗节点与事件的对应关系

为什么选这类第三方分析工具

三刀拆完漏斗，你会发现工具的差别在细节里。这三步——先看入口流量质量、再逐段算步内流失、最后核对完成事件口径——在这类工具里分别对应分渠道漏斗拆分、步内转化率自动标注、以及完成事件的上报点核对；不用自己写 SQL 拼每步人数，看板上选几个事件就能拉出逐段转化，具体可用范围以产品文档为准。其中网站分析本身有免费版可用，App 与小程序的行为漏斗属于基础版起开放，用户画像与分群属于专业版起开放。如果你团队已经在用自建方案，对比上面这张表的五项差异再决定；原生后台够用的话，也没有必要额外换工具。

你最近一次拆漏斗，问题是出在入口、某一步流失，还是成功事件本身没数对？欢迎在评论区分享你定位到的那个“最窄的腰”。