上个星期，一位刚转行做电商数据分析的朋友带着他们后台导出的漏斗报表来找我，日均几万人进首页，最后支付成功却只有两百多，他问我这个数字到底正不正常。我点开明细看了一眼，发现真正的问题根本不在用户身上，而在于他们每一步之间的衔接定义：用“商品详情页PV”做分子，用“整站独立访客”做分母，不同统计口径拼在一起，数据当然永远对不上。聊完之后，我把这几年做漏斗分析电商用户行为的一套思路重新梳理了一遍，写在这篇里，适合需要自己搭漏斗、盯转化、追流失的数据分析师、运营和独立站经营者参考。
1. 定口径、埋点与数据底座：漏斗分析最不该跳过的第一步
很多人拿到漏斗工具的第一反应是“赶紧把页面配好、把步骤连起来”，但漏斗分析电商用户行为这件事，真正能决定成败的往往不是后面那张漂亮的趋势图，而是最前面没人愿意细看的数据底座。底座搭歪了，后面所有结论都是自欺欺人。
1.1 先定义“每一步”是什么：事件、会话与用户
漏斗的核心单位是行为事件，而不是页面。同样是“浏览商品页”这件事，在统计系统里既可能是page_view事件，也可能是product_detail_view事件。如果前后两端用的命名不统一，分析的时候就会乱套。
我在实际项目里至少会把这几类事件拆清楚：
- 曝光类事件：首页曝光、搜索结果曝光、推荐位曝光，通常只用来衡量“看见了多少”。
- 浏览类事件：进入商品详情页、浏览评价、查看参数，这类事件表达的是“用户产生了兴趣”。
- 互动类事件：加入购物车、点击结算、领取优惠券、切换规格，这类事件距离交易更近。
- 转化类事件：提交订单、支付成功、支付失败回调，这是漏斗的终点，也是财务口径的起点。
定义完事件之后，还有一个容易被忽略的问题：用户在未登录状态下浏览，登录后加入购物车，再下单支付，这一整条行为链怎么串起来。如果不做用户身份识别，你会在漏斗里看到同一个人的行为被切成两段，算出来的每一步用户数都会偏大，转化率也会被稀释。
我的经验是：漏斗分析里优先使用 user_id（登录账号）作为主键，同时把 device_id 或 cookie_id 作为辅助键。当 user_id 为空时，用设备标识暂时替代；一旦用户完成登录，把这段时间内的历史行为并入同一个 user_id。这样既照顾了游客转化场景，又能保证数据连续性。
1.2 埋点方案里最容易埋错的几个参数
埋点听起来是工程师的活，但真正决定埋点能不能用的，往往是业务和数据侧的人。常见的问题有三个：
第一，商品ID和订单ID混用。加入购物车事件上报的是商品ID，支付成功事件上报的却是订单ID，中间缺少“订单明细商品”这一层关联，后续想分析“哪些商品加购多但支付少”就只能靠猜。
第二，关键参数在按钮点击时没有透传。比如用户从搜索结果页进入商品详情页，商品详情页的上报事件里没有携带搜索关键词和渠道来源，漏斗做出来之后想按渠道拆分，却发现数据根本拆不了。
第三，按钮位置调整后埋点失效。很多团队用可视化埋点工具，页面上某个按钮被运营挪了个位置，埋点自动失效，漏斗里对应步骤的数据突然变成0，大家还以为是线上故障。
针对这些问题，建议在埋点方案设计阶段就强制约定公共参数：统一的用户ID、会话ID、页面路径、商品ID、渠道ID、时间戳，任何事件都必须携带这些字段。埋点上线之后，前两周不要急着看趋势，先做数据质量核对，拿真实操作记录去对照底层明细，确认每一步的计数和人的预期一致，再开始建漏斗。
1.3 数据清洗：把爬虫和测试流量挡在漏斗外面
漏斗数据突然变得“好看”或者“难看”，很多时候不是用户变了，而是数据里混进了不该有的流量。我在某个电商项目里就遇到过，某天凌晨商品详情页的PV暴涨，加购量却没变化，后来查出来是爬虫在遍历商品库。
比较有效的基础清洗规则包括：
- 过滤明显异常的User-Agent（空UA、爬虫标识、无头浏览器标识）。
- 过滤短时间内高频访问但无任何加购行为的IP段。
- 过滤内部测试账号和公司办公网段的访问。
- 过滤支付测试订单和相关的浏览行为。
- 对同一用户在同一秒内的重复点击做去重。
清洗规则不是越严格越好，比如“无加购行为的IP”不能一刀切，否则会把大量只看不买的真实用户误杀。更稳妥的做法是：在主漏斗看板中使用“清洗后数据”，同时保留一份“全量数据”供排查异常时对比。两个数字差很多时，说明流量质量本身可能出了问题，这本身也是一个监控信号。
2. 漏斗怎么搭：阶段拆分、指标计算与流失率口径
数据底座准备到位之后，再来搭漏斗本身。漏斗分析电商用户行为的核心产出是一张能回答“用户走到哪一步不走了”的表，但这张表的每一步怎么切、怎么算，决定了它到底是一张废表还是一件趁手的工具。
2.1 电商主链路的五层漏斗怎么切
标准电商主链路通常可以切成五层：进入网站（首页或落地页）→ 浏览商品详情 → 加入购物车 → 进入结算页 → 支付成功。这五层覆盖了从“看见”到“付钱”的全过程。
不同业务形态可以在这个基础上调整。做内容电商的，可能要在此之前加“阅读内容/点击种草”这一步；做跨境独立站的，要把“选择物流方式”“填写地址”单独拆出来；做订阅制电商的，支付成功之后还可以继续看“次月续费”这一步，形成一个复购漏斗。
我常用的切法是把“结算页”继续拆成三个子步骤：进入结算页、填写完收货地址、点击提交订单。因为现实中很多用户走到结算页后，在填写地址这一步就放弃了，如果不拆开，你就会以为用户是在支付环节流失的，实际上去支付之前就已经走了。
2.2 用SQL还原每一步的用户量与转化率
有了事件定义之后，计算每一步用户量可以用SQL完成。以一张基础事件表为例，表中的关键字段包括：user_id、session_id、event_type、page、item_id、ts。
SELECT step, COUNT(DISTINCT user_id) AS user_cnt FROM ( SELECT user_id, CASE WHEN event_type = 'page_view' AND page = 'home' THEN 'step1_enter' WHEN event_type = 'page_view' AND page = 'product' THEN 'step2_view_product' WHEN event_type = 'add_to_cart' THEN 'step3_add_cart' WHEN event_type = 'checkout' THEN 'step4_checkout' WHEN event_type = 'pay_success' THEN 'step5_pay' ELSE NULL END AS step FROM events WHERE dt = '2024-01-15' AND user_id IS NOT NULL ) t WHERE step IS NOT NULL GROUP BY step注意，这段SQL得出的是“每一步的总用户数”，并不是严格的顺序漏斗。如果你要看“走完了上一步又走下一步”的连续漏斗，需要把事件按用户和会话排好序，用窗口函数或者专门的路径分析模块来做。以我实际项目的经验，第一版先看每步总量是可以的，至少能快速定位明显短板，但追问“是否连续”时必须回到有序路径。
转化率和流失率的计算口径如下：
- 相邻步骤转化率 = 本步骤用户数 ÷ 上一步骤用户数。
- 整体转化率 = 最终支付用户数 ÷ 进入漏斗用户数。
- 步骤流失率 = 1 - 相邻步骤转化率。
给管理层汇报时，我通常会把“步骤用户数”“相邻转化率”“整体转化率”三列一起展示，因为他们真正关心的是每一步之间到底漏掉了多少人，而不是某一个孤立的百分数。
2.3 时间窗口与“跨天访问”的处理
用户在电商平台上的行为很少集中在一次连续访问里完成。他们可能上班路上用手机看了商品，中午在公司电脑上加了购物车，晚上回家才支付。这给漏斗带来的最大问题是：时间窗口怎么取。
如果只按单次会话算漏斗，那么“跨会话完成购买”的行为会被切成碎片；如果把时间拉长到30天，又很难判断用户到底是因为哪一次访问进来的。
我的处理方法是分层看：
- 会话级漏斗：关注一次连续访问里的流失，适合分析页面体验、加载速度、流程顺畅度问题。
- 天级漏斗：以当天为窗口，统计当天从进入到支付的全链路，适合日常运营监控。
- 订单周期漏斗：以用户从第一次“进入商品页”到最终“支付成功”的完整时间为窗口，适合分析决策周期长的商品，比如高客单价的数码、家具、定制服务。
日常监控用天级漏斗足够，做体验优化看会话级，做品类运营分析再看订单周期。三个口径各有价值，但不能混在同一个图表里。
2.4 新客与老客的同环比：同一个漏斗要分两条线看
新客和老客的漏斗形态差异非常大。新客对你的品牌和商品没有信任基础，从详情页到加购这一步通常会大量流失；老客已经买过，可能直接搜索复购，甚至从订单历史里再次购买，根本不会走完整的浏览链路。
如果你把所有用户混在一起看，得出的结论往往既不适合新客也不适合老客。我在做会员制电商项目时，会把漏斗按“是否首单用户”拆成两条主线，再进一步区分设备、渠道和会员等级。
有了新老客的对比，你才能回答一个很常见的问题：为什么整体转化率一直上不去？如果答案是“新客转化率低但占比在扩大”，那就说明拉新增长正常，但承接能力还没跟上；如果是“老客转化率也在降”，那就要检查商品、库存和服务本身出了什么问题。这两者对应的动作完全不同。
3. 从漏斗结果找问题：流失、复购、异常波动的三条排查链路
漏斗搭完之后，真正烧脑的部分才开始：数据出来了，然后呢？漏斗分析电商用户行为最有价值的场景，是把“某一步流失率高”这个现象，拆解成可执行的问题根因。下面是我在原项目复盘里常用的三条排查链路。
3.1 商品详情页流失高：先判断是“不想买”还是“进不了页”
详情页的平均流失率高，在电商里几乎必然成立，因为大量用户只是随便逛逛。真正需要警惕的是两种情况：一种是详情页加载速度突然变慢，另一种是商品信息展示不完整。
排查时先看技术指标：详情页首屏加载耗时、图片资源加载失败率、服务端接口报错率。我接手过一个改版项目，详情页流失率在改版后一周内上涨了12个百分点，运营以为是价格问题，后来查接口日志，发现新版页面在弱网环境下会先阻塞渲染，用户等不到内容就退出了。这是技术问题，却不是通过改漏斗能解决的。
如果技术指标正常，再回来看用户意图。从详情页离开后的去向，往往比“离开”本身更有解释力。如果大量用户离开后直接搜索其他商品或点击相关推荐，说明当前商品匹配度不够；如果离开后直接退出网站，则可能是商品价格、评价或库存信息没有打动他。
3.2 购物车到结算的断裂：运费、库存、优惠券的叠加陷阱
我在多家电商项目里发现，购物车到结算页之间的流失，通常会集中在几个很具体的业务规则上：
- 包邮门槛设计不合理。用户加购的商品总额差几块钱才到包邮线，结算时看到运费立刻犹豫。
- 优惠券领取即失效。用户在详情页领了券，等到结算时发现不满足使用条件，心理落差很大。
- 库存状态在加购后发生变化。尤其秒杀和限量款，用户加购时显示有货，结算时却变成无货，体验非常差。
- 登录状态中断。游客身份加购，点结算时被要求登录，流程中断带来的流失通常比预期高很多。
对这一层的排查，关键是抓“进入结算页”和“提交订单”之间的行为。比较实用的做法是给“运费”“优惠券金额”“库存状态”“登录提醒”分别打点，统计出现每种提示之后再放弃结算的用户比例。哪一类提示出现频次高、放弃率高，哪一类就是优先优化项。
3.3 结算页支付失败：支付渠道回调与前端报错的差距
支付成功这一步，数据最容易出现“假差异”。有一种情况是：支付渠道已经扣款成功，但回调通知没有及时到达，前端一直停留在支付中状态，用户以为失败就关了页面；还有一种情况正好反过来，前端显示支付成功，但服务端没收到回调，订单被标记为未支付，用户来投诉才知道出了问题。
排查时建议对齐三个数据源：支付渠道的流水、订单系统的状态、前端埋点的结果。三者一致，才算一个真实的支付成功。如果支付成功率突然下降，先不要乱改支付页面，先看看是不是渠道维护、银行限额调整或者回调队列积压。
3.4 分渠道看漏斗：广告流量进来了，为什么就是不下单
整体漏斗表现稳定，不代表每个渠道都正常。我在看渠道漏斗时常发现一种情况：某信息流渠道的点击量很高，但从落地页到商品详情页的转化率却只有其他渠道的一半。再看点击按钮在页面上的位置，才明白用户是被夸张的广告素材吸引进来的，落地页却完全没承接住广告里承诺的内容。
分渠道看漏斗时，阶梯可以是：广告曝光 → 点击落地页 → 商品详情 → 加购 → 支付。重点看前三步，尤其是落地页与广告创意的匹配度。信息流渠道的漏斗表现弱，很多时候不是流量质量不行，而是承接页没接住流量。落地页里的主标题、首屏素材、活动说明，最好与广告创意保持同一种语言和情绪，用户才不会产生“到了另一个世界”的抽离感。
为了快速定位渠道问题，我建议用一张表把所有主要渠道的漏斗数据摆在一起对比：
| 渠道 | 落地页用户数 | 浏览商品页用户数 | 加购用户数 | 支付用户数 | 落地页→商品页转化率 | 整体转化率 |
|---|---|---|---|---|---|---|
| 搜索广告 | 23,400 | 15,200 | 4,900 | 1,360 | 65.0% | 5.8% |
| 信息流广告 | 41,200 | 19,800 | 4,100 | 680 | 48.1% | 1.7% |
| 内容种草 | 16,700 | 9,800 | 3,200 | 760 | 58.7% | 4.6% |
| 直接访问 | 12,300 | 8,400 | 3,600 | 1,150 | 68.3% | 9.3% |
信息流渠道的付费流量占比很高，整体转化率却只有搜索渠道的三分之一左右，这通常意味着两种可能：要么人群定向不够精准，要么落地页与广告创意的承接没做好。先做一轮落地页匹配测试，再调整出价策略，往往比直接砍预算更有效。
4. 漏斗之外还要配合什么：路径分析、多维拆解与用户验证
漏斗最大的优点是简洁，最大的缺点也是简洁。它把所有用户行为压成了一条直线，而真实用户的行为是发散的。只看漏斗，你只能知道“他在哪里掉了”，却不知道“他跑去哪里了”，更不知道“他为什么跑”。所以我在做用户行为分析时，几乎从来不会只交付一张漏斗图。
4.1 漏斗只能告诉你“在哪掉”，路径分析告诉你“掉去哪了”
围绕漏斗里的每一步，再往下钻取一层用户去向分布：
- 从商品详情页离开的用户，下一个事件是搜索、点击关联推荐、查看店铺首页、还是直接关闭网页？
- 从结算页离开的用户，是返回购物车修改商品数量，还是去领优惠券，还是直接结束会话？
- 支付失败的用户，后续有没有在30分钟内重新发起支付？
这些去向分布可以直接影响优化动作。举个例子，如果大量用户离开商品页后跑去搜索同类商品，说明当前商品页上的推荐位可能没有命中需求，你可以在商品页推荐模块里加“相似价位”“相似风格”的算法策略，而不是只盯着漏斗自嗨。
路径分析工具不一定要很复杂，有一张能够按“上一个事件→当前事件→下一个事件”聚合的行为转移矩阵就够了。先看Top 10的转移路径，再看异常会话的具体事件序列，通常就能找到方向。
4.2 把用户分成人群再看漏斗：设备、地区、新老客、购物偏好
漏斗数据经过人群拆解之后，隐藏的差异会迅速暴露。我用过的几个比较有效的拆分维度如下：
- 设备维度：iOS端和Android端的漏斗表现经常不一样。某些项目的Android WebView在弱网环境下加载慢，加购率就会明显低于iOS；但如果不拆分，两个数据混在一起，平均值看不出问题。
- 地区维度：物流配送范围、偏远地区运费、本地仓库存情况都会影响支付决策。分地区看漏斗可以发现，某地区的加购率不低，但结算流失偏高，原因是整单运费过高。
- 新老客维度：前面说过，两者天然不同。更细一点，还可以把“新客”再分成“首访用户”和“注册未购用户”，后者往往离成交更近。
- 商品品类维度：生鲜、家电、服装的决策链路完全不同。服装用户可能反复看评价，家电用户可能只比较两三次就下单，放在同一个漏斗里没有意义。
每次做完人群拆解之后，我会做一个很朴素的记录：哪个维度差异最明显，哪个维度下漏斗形态出现结构性变化。这些记录会沉淀下来，变成下一次实验的假设来源。
4.3 定量结论必须配合定性验证：回访、问卷与后台投诉工单
漏斗数据是“他们做了什么”，但很少能回答“他们为什么这么做”。要补上这块拼图，最常用的手段是用户回访和问卷。
印象比较深的一次是：某个产品的结算流失率连续三周上涨，后台数据显示大量用户在填写地址页退出。我们一度怀疑是地址填写流程太长，后来回访了十几个用户才发现，真正的原因是页面上的运费预估和前端计算器不一致，用户修改收货地址之后，看到的运费比实际结算时的高出很多，不敢继续付款。这是漏斗数据本身很难直接暴露的信任问题。
后台投诉工单也是被严重低估的信号来源。我会定期把“支付失败”“运费争议”“优惠券不可用”这类的工单关键词与漏斗中的流失环节做对应。工单数量激增的环节，通常与漏斗的流失尖峰高度重合，把两套数据放在一起看，会得到更完整的证据链。
5. 从诊断到落地：一次移动端详情页的流失优化实验复盘
聊完了方法论，最后讲一个完整案例。这个案例里的数值做了脱敏处理，但整个思考路径是我实际做过的漏斗分析电商用户行为项目的复刻，能帮你把前面所有内容串起来。
5.1 定位问题：移动端从详情页到购物车的流失率飙升
某电商项目在一个季度末复盘时发现，整体支付转化率环比下降了0.4个百分点，看起来不算大，但放到月GMV上就是一笔不小的损失。我们用漏斗逐层拆解后发现，问题集中在“浏览商品详情 → 加入购物车”这一步：移动端的相邻转化率从24%跌到了16%，而PC端的转化率基本稳定。
数据继续往下拆：Android端比iOS端更严重；低价商品比高价商品更严重；从搜索渠道进来的用户流失最明显。这些现象共同指向一个假设：移动端商品详情页的加购入口出现了某种系统性问题，而非单纯的供给或价格问题。
5.2 提出假设与A/B实验：详情页首屏的CTA位置
打开移动端商品详情页之后，发现新版页面把“加入购物车”按钮从首屏移到了需要向下滑动两次才到达的位置，首屏被大面积的主图、标题和达人测评覆盖。在商品详情页停留时间短的搜索流量用户，根本滑不到加购按钮就在中途退出了。
基于这个观察，我们设计了两个版本的实验：
| 实验版本 | 变化内容 | 预期效果 |
|---|---|---|
| A（对照） | 维持新版页面，加购按钮在次屏 | 保持现状 |
| B（实验） | 恢复首屏加购按钮，点击后弹起规格选择面板 | 提高详情页→加购转化率 |
实验从设计到上线花了两周，实验周期为7天，流量按用户ID随机分流，确保同一个用户只看到同一个版本。为了保证结果可信，我们还提前排除了大促期，避免活动补贴对加购行为的干扰。
5.3 结果复盘与推广策略：不只是看转化率，还要看客单价与退款
实验结束后，B组的数据明显优于A组：
- 详情页到加购的相邻转化率从16%提高到19.4%。
- 整体支付转化率从1.7%提高到1.9%。
- 客单价略有下降，约0.6%，在统计上不显著。
- 退款率没有出现明显变化。
最终方案的净效果是：GMV提升约5.8%。但由于客单价有轻微下降趋势，我们没有直接把新版本全量推送，而是先观察了两周，确认购物车结构和关联购买没有出现负面变化之后，才逐步放量到100%用户。
这里有一个我特别想提醒的经验：转化率提升了好事，但如果加购入口提前了，用户可能在不经意间更冲动地下单，随后退货率上升，账面上看转化率更好，实际利润反而受损。所以漏斗优化的复盘里，至少要同时盯住三个指标：转化率、客单价、退款率。
做漏斗分析这几年，我最大的体会是漏斗永远是一面镜子，照出的不是数据本身，而是业务在流程设计、承接能力和规则合理性上的真实状态。如果你想在自己的项目里第一次尝试，建议从主链路开始，先搭一个五层漏斗，把口径定清楚，把埋点核对好，别急着堆复杂的分析模型。跑通一个能反映真实业务变化的漏斗，比做十个看起来很高级、数据却对不上的图表有用得多。
