用户卡住了你却最后一个知道：vibe 项目的会话录像与热图实战

用户说“你家网站卡住了”，你却连他卡在哪一步都不知道：先讲一个虚构的教训

先讲一个虚构的教学例子。阿琳一个人用 AI 搭了个在线简历工具“简历工坊”，上线三个月，用户量慢慢涨起来了。可后台数据越看越不对劲：注册转化率从 42% 掉到了 27%，客服邮箱里隔三差五就有一封“你家网站卡住了”“点保存没反应”“我填了半天全没了”。阿琳去看数据分析后台，只能看到“第三步流失率高”——可第三步到底发生了什么，是按钮点不动、是表单报错看不懂，还是页面直接白屏了？她猜了三周，改了三版，全没改到点子上。

后来她接了会话录像：随机抽 5% 的会话录下来。第一天就破案了——第三步那个“保存并继续”按钮，在小屏手机上被底部的输入法键盘顶出了可视区，用户点了半天点的是按钮下面的空白；更惨的是，保存失败时页面只轻轻抖一下，没有任何报错文案，用户以为是网卡了，狂点十几下，点了十几次重复提交。阿琳修了两个地方：按钮改成吸底、保存失败弹明确提示。两周后转化率回到 41%。

这个例子想说的是：数据分析告诉你“哪里不对”，会话录像告诉你“到底发生了什么”。一个只会看数字的团队，修 bug 靠猜；一个会看录像的团队，修 bug 靠看。本文讲的就是怎么把会话录像和热图这两样工具接进你的 vibe 项目：录什么、不录什么、录多少才够、隐私怎么处理、热图三种图怎么读、从录像到修复的工作流怎么跑，最后是一份上线检查清单。本文所有例子里的人名、产品名和数字都是虚构的教学例子，只用来把道理讲清楚；文中的比例和天数都是工程经验建议，不是哪个官方标准，照着用之前先按你自己的产品和用户量验算一遍。

先划界：这篇只管“看用户实际怎么用的”，不管另外四件事

动手之前先把范围划清楚，站内已经有几篇写在前面的指南，本文是拼图里新的一块，不重复它们讲过的事。第一篇是《数据分析实战》，讲的是埋点、漏斗和指标：多少人来、多少人走、哪一步掉得多——那是“数”的层面。第二篇是《错误监控与崩溃上报实战》，讲的是前端报错、崩溃上报和错误边界——那是“代码出没出错”的层面。第三篇是《可用性测试实战》，讲的是请真人来、看着他用、听他说——那是“主动找人测”的层面。第四篇是《用户反馈循环实战》，讲的是用户主动告诉你哪里不好——那是“用户开口说”的层面。

本文讲的是第五种：用户没有开口、没有报错、测试也没测出来，但他就是卡住了、走了。会话录像和热图解决的是“沉默的流失”——用户没投诉、没报错，只是默默关掉页面。这种流失在数据后台只显示为一个数字，在录像里却是一段活生生的“他点了这里、等了三秒、又点了那里、最后关掉了”。

还有三件看着像、其实不是这篇的事。第一，A/B 测试：录像告诉你哪里卡，A/B 测试告诉你改成哪样更好，两件事接力，但不是同一件事。第二，用户访谈：访谈问的是“你为什么这么想”，录像看的是“你实际这么做了”，一个问动机、一个看行为。第三，性能监控：页面加载慢不慢是性能监控的事，录像只管“加载慢的时候用户干了什么”。划界的意义很实际：录像和热图是“看”的工具，不是“测”的工具，也不是“问”的工具，先把它的位置摆对，再谈怎么用。

一、会话录像到底录了什么：不是录屏，是“重放”

先把一个常见的误会拆掉：会话录像不是把用户的屏幕录成视频。你的服务器上没有一段 MP4，它录的是 DOM 的变化——用户在页面上每一次点击、滚动、输入、鼠标移动，都被记成一条条事件；回放的时候，录像工具按时间线把这些事件重新“演”一遍，还原出用户看到的页面。这个机制决定了三件事：第一，录像文件很小，一次会话通常只有几十 KB；第二，回放可以快进、跳段、按事件筛选；第三，也是最重要的——录像里根本没有像素，只有数据，所以你能控制哪些数据进录像、哪些不进。

一个会话里通常有五类事件值得录。第一是点击：点了哪个元素、坐标在哪、有没有点中可交互的东西。第二是滚动和鼠标移动：用户在页面上逛到了哪里、鼠标在哪个区域停留最久。第三是输入：用户在哪个字段停了多久、删改了几次——但注意，这里只录“行为”，不录“内容”，后面隐私那节会细讲。第四是页面变化：路由跳转、弹窗出现、报错提示、加载状态。第五是会话信号： rage click（短时间内对同一位置狂点）、dead click（点了没有任何反应的元素）、u-turn（进了页面又马上退回上一页）。这五类合在一起，才能还原出“用户到底经历了什么”。

反过来，有三类东西不应该进录像。第一是密码、卡号、身份证号这类敏感字段的输入内容——录下来就是事故。第二是用户自己上传的文件内容、粘贴的大段私人文本。第三是第三方 iframe 里的内容，比如内嵌的支付页面——你录不到，也不该录。判断标准就一句话：录像里只应该有“用户怎么和你的界面互动”，不应该有“用户的私人信息是什么”。

选工具的时候，先问自己三个问题。第一，你的用户量有多大？日活几百的小产品和日活十万的产品，采样策略完全不一样。第二，你的页面是单页应用还是多页？单页应用的路由变化、动态内容更多，录像工具要支持得好才行。第三，你的数据要不要出境？录像数据默认存在服务商的服务器上，对数据主权有要求的产品要选支持自托管或指定区域的方案。这三个问题的答案，基本就决定了你该用 SaaS 还是自托管、采样率设多少、预算留多少。

二、录多少才够：采样率是成本和运气的平衡

会话录像最容易踩的坑，是两个极端：要么全量录，要么只录 1%。全量录的问题是钱和噪音：日活一万的项目，全量录一个月就是 30 万段录像，存储和回放成本直线上升，而且 99% 的录像都是“用户正常用完就走”，没人有时间看。只录 1% 的问题是运气：你要找的那个 bug 可能恰好发生在没被录到的 99% 里，等用户投诉来了，你手里还是没有录像。

经验上可以按三个档位来。第一档是“全量录关键页”：注册、支付、核心操作页，这些页面一个用户一辈子也就走几次，出问题代价最大，全量录也花不了多少钱。第二档是“按比例采样普通页”：5% 到 10% 是常见的起点，既能攒下足够的样本，又不会把存储撑爆。第三档是“条件触发全录”：用户点了报错、连续三次操作失败、停留超过 5 分钟没进展，这类会话自动全录——因为出问题的会话才是最值得看的。

采样率不是定一次就完事的，要跟着产品阶段调。上线第一个月，用户量小，全量录都没问题，目的是尽快攒下第一批“真实用户怎么用”的素材。用户量上万之后，改成关键页全量加普通页 5% 采样。用户量再大，就要按“问题密度”动态调：某个页面最近投诉多，它的采样率临时提到 50%，问题修好了再降回去。采样率是一个运营参数，不是一次写死的配置。

还有一个省钱的技巧：录像可以只存 30 天。绝大多数 bug 的排查窗口就是出问题后的头两周，30 天足够覆盖；超过 30 天的录像，价值断崖式下跌，除非涉及客诉纠纷要留证。存 30 天和存 90 天，存储成本差三倍，价值差不到一成。这笔账要算清楚再定保留期。

三、隐私先行：录像的第一行代码应该是“不录什么”

会话录像是一个“先想好不录什么，再想录什么”的功能。顺序反了，上线第一天就可能出事故。隐私处理分四层，每层都要在动手之前定好。

第一层是字段屏蔽。所有密码框默认不录内容，这是录像工具的标配；除此之外，你要自己列一张“敏感字段清单”：手机号、邮箱、身份证号、银行卡号、地址、病历、薪资——凡是用户填的、能定位到具体个人的字段，内容一律不录，只录“这个字段被填了、填了多久、改了几次”。屏蔽要在客户端做，也就是数据还没离开用户浏览器就抹掉，而不是录下来再到服务端删。顺序错了，数据就已经泄露了。

第二层是内容脱敏。有些页面天生带敏感信息，比如用户自己写的笔记、聊天记录、上传的文件名。处理办法是按页面、按区域屏蔽：整个页面不录，或者某个区域打码。脱敏规则要写进配置、随代码走，而不是靠运营人员事后手动处理——手动处理一定会漏。

第三层是告知与同意。录像之前要告诉用户“我们在记录你如何使用产品以改进体验”，并且给一个明确的退出入口。不同地区的法规要求不一样，有的地方要求明确同意、有的地方只要求告知，具体的合规口径要按你的用户所在地区去核对，本文不展开法律细节。但有一条底线是不变的：用户退出之后，他的会话就不应该再被录，退出入口要真的能点、点了真的生效。

第四层是访问控制。录像的回放权限不是人人都有：只有负责排查问题的开发和客服能看，而且要按需授权。客服看录像是为了帮用户解决问题，不是为了围观用户的操作；开发看录像是为了定位 bug，不是为了翻用户的隐私。访问日志要留着——谁看了哪段录像、什么时候看的，出了事能查。这四层都做到，录像才算是一个“能放心开”的功能。

四、热图三种图怎么读：点击图、滚动图、移动图各看什么

会话录像是“看一个人”，热图是“看一群人”。热图把成千上万次点击、滚动、鼠标移动叠加在一张页面截图上，用颜色深浅告诉你用户集体的注意力去了哪里。三种热图各看不同的东西，读错了会得出完全相反的结论。

点击热图看的是“用户以为哪里能点”。颜色最深的地方，就是最多人点的地方。读它的时候要对照两个问题：第一，点得最多的地方是不是你想让用户点的地方？如果“取消订阅”比“继续使用”还红，说明你的界面在把人往外推。第二，有没有人点“不能点的地方”？一张装饰图、一行说明文字、一块空白区域，如果上面有一团红色，说明用户以为那里是个按钮——要么把它做成真的能点，要么改掉它的“可点”长相。点击热图最有价值的发现，往往是这些“点了也没反应”的地方。

滚动热图看的是“用户看到了哪里”。它按页面高度画一条颜色带，告诉你有多少比例的用户滚到了哪个位置。读它的时候记住一个数：首屏以下的第一个分界点，通常只有 50% 到 70% 的用户能到；再往下每多一屏，人数就掉一截。所以重要的内容——价格、核心卖点、行动按钮——不要只放在页面底部。滚动热图最常见的结论是“用户根本没看到那段内容”，而不是“那段内容写得不好”。

鼠标移动热图看的是“用户在犹豫什么”。鼠标停留久的地方，通常是用户在阅读、比较、犹豫的地方。读它的时候要小心一个陷阱：鼠标停留不等于眼睛在看，很多人鼠标随手一放、人早就去喝水了。所以移动热图只能当辅助证据，不能单独下结论——它最适合和点击热图对照着看：鼠标停留久、又没人点的地方，很可能就是“用户想点、但没敢点”的地方，比如一句写得含糊的说明、一项藏得太深的设置。

三种热图合起来，还有一个高级用法：分群对比。新用户和老用户的点击热图放在一起，差别会非常明显：新用户点得到处都是，老用户直奔主题。如果新用户的点击热图上到处是“死点”，说明你的新手引导有问题；如果老用户突然开始点一个以前没人点的角落，说明最近上的新功能被发现了。热图不是一张图，而是一组对比。

五、从录像到修复：每周一次的“录像会诊”怎么跑

工具接好了，录像存下了，接下来是最容易被忽略的一步：谁来看、什么时候看、看完怎么办。没有固定流程的录像，最后都会变成“存着但没人看”的数据垃圾。建议跑一个轻量的每周流程，分四步。

第一步是筛选：每周一早上，开发负责人花 20 分钟，从上周的录像里挑出 5 到 10 段“值得看的”。筛选条件就三条：rage click 次数最多的、报错后用户直接流失的、关键页面停留超过 5 分钟没进展的。不要随机抽着看，随机抽到的基本都是正常会话，浪费时间。

第二步是会诊：每周固定半小时，开发加产品加客服一起看这 5 到 10 段录像，每段只看关键的 30 秒到 1 分钟。看的时候只记三件事：用户卡在哪一步、卡的原因是什么、修起来要多久。会诊的规矩是“只看录像、不争对错”——录像里用户点了十次没反应的按钮，争论“用户应该看说明书”是没有意义的，修按钮才是正事。

第三步是分级：修不修、什么时候修，按三级分。P0 是“用户付不了钱、注册不了、数据丢了”，当天修；P1 是“用户能走完、但走得很别扭”，本周排期修；P2 是“用户犹豫了一下、但最后自己走过去了”，记下来、攒着一起修。分级的时候记住：rage click 次数是最诚实的优先级指标——用户狂点的地方，就是最痛的地方。

第四步是复核：修完之后，再去看同一页面的新录像，确认同样的问题是不是真的消失了。很多团队修完就以为修好了，结果用户换了个姿势继续卡。复核的窗口建议是修复上线后一周，采样率临时提到 50%，看 20 段新录像，没问题再降回去。没有复核的修复，等于没修。

这个流程还有一个附带的好处：它会慢慢改变团队的讨论方式。以前讨论是“我觉得用户会这么用”，现在是“上周三那段录像里用户就是这么用的”。前者是猜，后者是看。猜和看的差别，就是改三版都没改到点子上，和第一天就破案的差别。

六、指标与上线检查清单

录像和热图上线之后，效果要靠三个指标来验证。第一个是 rage click 率：每千次会话里出现 rage click 的次数，上线第一个月就应该看到它往下走——如果它纹丝不动，说明修的都不是用户真正痛的地方。第二个是关键页面流失率的变化：注册、支付、核心操作页的流失率，修完问题后两周内应该有可见的回升。第三个是客服工单里的“说不清”比例：以前那种“用户说卡住了、但说不清卡在哪”的工单，应该越来越少——因为客服可以直接去看录像，而不是靠猜。

最后是上线前逐项打钩的检查清单，一共 12 项，缺一项都别上线。录像范围：关键页全量、普通页采样 5% 到 10%、条件触发全录的规则定好，保留期 30 天。隐私：敏感字段清单列好、客户端屏蔽生效、按页面和区域的脱敏规则配好、告知文案上线、退出入口真的能点、回放权限按人授权、访问日志打开。热图：点击、滚动、移动三种都接好，分群对比能按新老用户切。流程：每周“录像会诊”排进日程，P0/P1/P2 分级标准写好，修复后复核的窗口定好。12 项全打钩，会话录像才算真正上线；缺一项，上线第一天就有人在群里问你没想过的问题。

说到底，会话录像和热图修的不是一个工具，而是一种工作方式：从“猜用户怎么了”变成“看用户怎么了”。猜的时候，你改三版都改不到点子上；看的时候，第一天就能破案。你的用户不会告诉你他卡在哪一步——但他的鼠标会。