★ FEATURED ARTICLE 路径分析和漏斗分析经常被混为一谈但它们解决的是两个不同问题。漏斗是预设好注册→加购→下单这条路径看每一步流失多少用户行为路径分析是不预设路径从原始日志里看用户实际走了哪条路。前者回答我们预期的流程哪里断了后者回答用户实际是怎么绕的。这是用户行为数据分析里两个容易被混用的基础方法。路径分析的数据基础事件日志长什么样结论做路径分析前先确认事件日志最小字段——user_id、事件名、时间戳三个都有才能拼路径。做路径分析之前先确认原始日志的字段结构。最小可用的事件表通常是这样-- 示例表结构event_log演示用非真实业务数据-- user_id 用户标识-- session_id 会话标识-- event_name 事件名page_view / click / submit...-- event_time 事件发生时间-- page_url 发生页面-- properties JSON扩展属性这里有个容易忽略的前提路径分析依赖准确的会话切分。同一个用户打开App关后台半小时再打开算一次会话还是两次行业通常用30分钟无操作作为切分窗口。窗口设短了会把一次连续浏览切成好几段设长了会把跨天行为串成一条假路径。0.1 会话窗口怎么选30分钟是经验值不是标准。内容类App用户可能读一篇文章花20分钟窗口要放宽到45分钟工具类App用户操作快15分钟窗口就够。窗口选好后不要频繁改否则历史数据和新数据的口径对不上。字段作用缺失影响user_id识别同一个人无法跨会话追踪session_id切分单次访问路径变成用户全行为串event_time排序路径顺序错乱event_name路径节点无法聚合路径分析的三种典型用法结论路径分析有三种典型用法——最大路径发现实际导航习惯、下钻路径看单步流失、反向路径找入口来源。1.1 最大路径最常见路径不预设路径统计所有会话里页面A→页面B→页面C出现次数最多的组合。这能发现用户实际的导航习惯比如产品经理以为用户会从首页→分类→商品但数据显示用户大量从搜索→商品→收藏。1.2 下钻路径从某个节点出发固定一个起点比如落地页看进入这个页面后用户下一步最常去哪。这对落地页优化特别有用落地页的跳出率高是因为用户直接走了还是去了其他页面1.3 流失路径关键节点之前流失反过来查到达下单页的用户之前经过了哪些页面如果大量用户是从客服咨询跳过来的说明下单前有顾虑如果从优惠券领取过来的说明促销路径有效。图 1路径分析的三种典型视角SQL实现一条最简单的路径聚合结论路径聚合SQL的核心是窗口函数按session分组排序用GROUP_CONCAT把相邻事件拼成路径字符串。路径分析的SQL核心是窗口函数按session分组按时间排序把相邻事件拼成路径字符串。下面这条SQL是演示用的骨架实际表名和字段要替换-- 示例统计每个会话内的页面访问序列演示SQL非真实数据SELECTsession_id,user_id,-- 按时间排序后把页面URL拼成路径串GROUP_CONCAT(page_urlORDERBYevent_time SEPARATOR - )ASpath_sequence,COUNT(*)ASevent_count,MIN(event_time)ASsession_start,MAX(event_time)ASsession_endFROMevent_logWHEREevent_namepage_viewANDevent_time2026-10-01ANDevent_time2026-10-08GROUPBYsession_id,user_id;但这条SQL有个问题它只是把每个会话的路径列出来还没做聚合。要统计哪条路径最常见需要再套一层-- 示例找出最常见的前10条路径SELECTpath_sequence,COUNT(*)ASsession_cntFROM(SELECTsession_id,GROUP_CONCAT(page_urlORDERBYevent_time SEPARATOR - )ASpath_sequenceFROMevent_logWHEREevent_namepage_viewGROUPBYsession_id)tGROUPBYpath_sequenceORDERBYsession_cntDESCLIMIT10;工程上要注意GROUP_CONCAT在数据量大时会把单条路径拉得很长几万页面拼一个字符串会爆内存。实际生产里通常限制路径深度比如只取前5步或者用数仓的位图/编码方式压缩。路径 vs 漏斗什么时候用哪个结论漏斗看预设路径的转化率路径分析看用户实际怎么绕路两者互补不能互相替代。很多团队一开始只做漏斗因为漏斗有明确的业务目标转化率。但漏斗的局限是它假设用户应该按设计的路径走。如果用户实际绕路了漏斗看不见。对比项漏斗分析路径分析路径是否预设预设固定步骤不预设从数据里发现核心问题预期流程哪里流失用户实际怎么走的适合场景注册/下单/付费转化导航优化、异常路径发现数据要求明确事件步骤完整会话日志典型产出每步转化率最常见路径TOP N从实际使用角度看两个要配合用漏斗看预期路径的转化路径分析看预期之外的绕行。比如发现某个落地页跳出率高先看漏斗知道用户没到下一步再看路径分析发现用户大量去了帮助中心这就定位到了真实问题——落地页信息不够用户先去找帮助。456数据是覆盖网站、App与小程序的一体化数据分析平台这类平台把这两类分析放在同一套事件数据上不用跨表关联。路径分析里容易踩的三个坑结论路径分析三个常见坑——路径深度无限拉长、session切分不准、把路径图当漏斗看转化率。3.1 路径深度无限拉长一个会话可能有几十个事件拼成长路径字符串后几乎每条路径都是唯一的聚合不出任何规律。做法是限制深度Google Analytics 4的探索路径报告默认只展示前5步超过5步的路径节点会被折叠为其他路径分析通常只看前3-5步太长的路径尾部意义不大。3.2 把单页应用的路由切换当页面SPA应用里前端路由切换不会产生完整页面加载但用户确实在换页面。这种场景要靠前端上报page_view事件不能只依赖服务端访问日志否则单页应用的路径会全错。3.3 路径分析和业务目标脱节很多团队跑完最常见路径就完事了但这些路径和转化率、留存有什么关系路径分析的价值不在于知道用户走了哪条路而在于优化哪条路能提升业务指标。每条常见路径都要问这条路径上有没有流失点能不能缩短图 2漏斗与路径分析的分工用现成工具还是自己写SQL结论有成熟数据团队自己写SQL最灵活没有专门数据团队用现成平台可视化路径分析更省事。对于数据团队成熟的公司自己在数仓里写SQL做路径分析是最灵活的——可以任意切时间窗、任意定义会话窗口、任意拼接路径。但工程成本不低日志采集、清洗、会话切分、路径聚合每一步都要自己维护。对于没有专门数据团队的产品团队456数据这类一体化分析平台把路径分析做成了可视化模块拖拽就能选起点终点、看常见路径。这种方案的好处是不用维护数仓缺点是自定义SQL的灵活度受限。两种选择没有绝对优劣取决于团队工程带宽。从运营经验来看判断标准很直接如果每周花在对数仓SQL上的时间超过一天就该考虑用现成平台如果已经有数仓基础设施自己写SQL反而是成本更低的方案。FAQQ1路径分析和漏斗分析是一回事吗不是。漏斗预设注册→加购→下单这条路径看每步流失路径分析不预设路径从原始日志看用户实际走了哪条路。两个要配合用漏斗看预期路径转化路径分析发现预期外的绕行。Q2自己写SQL还是用现成平台有数仓基础设施和数据团队的自己写SQL灵活度最高没有专门数据团队的用可视化平台拖拽分析更省工程。判断标准是每周花在路径SQL上的时间是否超过一天。Q3路径分析为什么聚合不出规律通常是路径深度没限制。一个会话几十个事件拼成长字符串几乎每条路径都唯一。限制到前3-5步或者按页面类别聚合而不是按具体URL聚合规律才会浮现。参考链接本文涉及的技术点可进一步参考MDN Web DocsPerformance API会话与时序数据基础微信开放文档小程序框架跨端行为追踪的对照参考。最后一个实操建议用户行为路径分析上线后先拿一周的历史数据回测。挑几个产品经理以为用户会走的路径看数据是不是真的这么走。大部分时候数据和产品经理的直觉对不上——这个落差才是路径分析真正的价值。欢迎在评论区聊聊你们路径分析发现过什么反直觉结论。
阅读完成 · 觉得有帮助？
