漏斗回答一个问题:开始的人里有多少走到了最后,其余的人在哪一步离开?要把这么简单的报表做出误导性的答案并不容易,但团队们每周都在做到。下面五个错误几乎覆盖了我们被请去排查的所有漏斗。每一个都有能在图表上看出来的征兆,和几分钟就能做完的修法。
读完你会知道
- 为什么按浏览量搭的漏斗每一步都虚高
- 缺少时间窗怎样把漏斗变成一张「终身报表」
- 一套五分钟例行检查,让漏斗经得起追问
错误一:数次数,不数人
最古老的漏斗错误是数某一步的页面加载了多少次,而不是多少人到过这一步。一个刷新了三次结账页的访客变成三次结账;一个在第二步和第三步之间来回的访客把两步都撑大了。征兆是后面的一步比前面的一步还大,按人数这是不可能的。
修法:漏斗按访客(有登录就按识别出的用户)搭,不按事件。TapCub 的漏斗在时间窗内每人每步只数一次,不管触发多少次。
错误二:没有时间窗
漏斗需要一个窗口:一个人从第一步走到最后一步有多长时间。没有它,一月看过定价页、六月才买的人,和十分钟内做完两件事的人算在同一条漏斗里。转化率看着挺健康,却对你想修的那个结账流程什么都没说。
修法:选一个和决策匹配的窗口。结账用一个会话或 24 小时;试用到付费用 14 天或 30 天。把窗口写进报表标题,免得有人拿 1 天的漏斗和 30 天的漏斗比。
错误三:强制严格顺序
真实路径是乱的。人们打开定价页,去读文档,回来,开始结账,看一眼竞品,再回来付款。要求各步严格相连、中间不能有别的动作的漏斗,会把所有绕过路的人丢掉。征兆是在一个页面本身没问题的步骤上流失了大多数人。
修法:默认用「按顺序,中间可以有其他动作」。严格顺序留给产品本身强制了顺序的流程(比如多步表单),以及诊断有没有人跳步的时候。
错误四:混合分群和机器人
对全部流量做的漏斗,把行为完全不同的群体平均到了一起。新访客和回访、手机和桌面、付费和自然流量,以及伤害最大的:真人和机器人。一个把每个定价页地址都抓一遍、却从不开始结账的爬虫,会给漏斗加一个肥大的顶部和一个吓人的第一步流失。征兆是流量高的日子第一步流失特别大。
修法:先把漏斗筛到真人(TapCub 默认如此,「只看真人」开关对漏斗生效),再一次按一个维度拆分。发现通常就在拆分里:整体 46% 的流失,可能桌面端是 20%、手机端是 70%。
错误五:读总数,不读最大流失
整体转化率是漏斗里最没用的数字。它是每一步的乘积,什么动它都动,却什么都指不出来。要读的是单步之间最大的那次流失,因为改那一步对总数的影响最大。
下面的示例漏斗里,2,400 个访客到达定价页,1,248 个开始结账,674 个到达支付,508 个完成。总转化率 21%。有用的事实是结账到支付之间 46% 的流失,那正是运费出现的地方。
结账漏斗 · 只看真人 · 24 小时窗口
最近 30 天定价页
2,400
开始结账
1,248
支付
674
完成
508
五分钟例行检查
信任一条漏斗之前,先过一遍下面的表。五分钟,五个错误全能抓到。然后养成习惯:先读最大流失,按设备和来源拆分,最后才看总数。想深入步骤设计的话,行为分析页用同一组示例数据展示了漏斗、路径和留存,转化率计算器能帮你估算修好一步值多少。
最后一个习惯:保存漏斗时把窗口和筛选写进名字(「结账 · 真人 · 24 小时」),分享保存的报表而不是截图。会议上大多数漏斗争论,其实是两个人在看两条配置不同的漏斗,却以为是同一条。一个命名并保存的定义能在争论开始前结束它,也让你不用重建就能逐月比较同一条漏斗。
| 检查项 | 问题 | 如果答案是否 |
|---|---|---|
| 数人不数事件 | 每一步是不是每个访客只数一次? | 把漏斗切换为按访客计数 |
| 时间窗 | 设了转化窗口并写在标题里了吗? | 设一个和决策匹配的窗口 |
| 顺序 | 是「按顺序、中间可有其他动作」吗? | 除非产品强制顺序,否则放宽 |
| 只看真人 | 机器人排除了吗? | 打开只看真人 |
| 最大流失 | 先读了最大的单步流失再看总数吗? | 从那一步开始,按设备和来源拆分 |
TapCub Team
设计、开发并支持 TapCub 的这群人。我们写自己网站上量到的东西,也写客户问得最多的问题。