图片

一句"用户不喜欢",就要重做页面?

销量下降,马上认定价格太高。阅读量下降,马上决定换标题。

团队刚改完注册页,上线第二天,仪表盘上"注册完成"的曲线往下掉。会议室里,有人脱口而出:"用户不喜欢新页面。"接下来的讨论,就变成了"改回旧页面还是重新设计"。

一句"肯定是",就可能决定整个团队接下来忙什么。

我们看到的是"注册完成下降","用户不喜欢新页面"只是对它的一种解释。等到大家说"新页面就是原因",这个解释已经被当成了结论。提出猜测很正常,但还没查证就按它安排返工,后面的精力可能都花错了地方。那怎么检验一个猜测值不值得信?

面对同一个结果,我们可以提出几种解释,再逐一查证。这种从观察到的现象出发,寻找可能解释的推理方式,叫作溯因推理。

哲学家皮尔士在1878年的《演绎、归纳与假说》中系统讨论了它,将它与演绎、归纳并列为三种基本推理。通俗的表述是"从有限的事实证据出发,提出一个能解释这些事实的、最合理的假说"。

溯因推理,就是针对已经核对过的异常现象,依据已有知识提出一个或多个假设。如果假设成立,眼前的现象就说得通,但假设本身仍需后续证据检验。

完成注册的人真的少了,还是数据漏记了?

看到数据下降,先核对一下:这个异常是真的吗?

先看面板上的变化能不能直接拿来比较。上线第二天的数字,可能受到星期差异、记录延迟的影响,也可能只是正常波动。需要选一个合适的时间窗口,看看下降幅度是否超出了平常的范围。指标定义和分母有没有变,埋点的触发规则是否调整过,数据是否完整,也都要核对。

然后再看实际的注册行为。面板记录的"注册完成"事件少了,数据库里新创建的账户也少了吗?

这两层检查回答的是不同问题。面板记录发生变化,未必意味着用户行为也变了。事件名、触发时点或去重规则一变,即使用户照常完成注册,面板上的数字也可能少一截。

核对数据时,当然也会提出猜测。怀疑记录延迟或口径变化,本身就是在寻找解释。实际调查往往是一边查,一边调整想法。先核验异常,是提醒我们至少分清哪些已经确认、哪些还没查过,别拿着一个含糊的印象就开始找原因。

可以试着把异常写成一句完整的话:先说清楚是哪些对象、在什么时间段出现了变化;再说清楚按什么指标、跟什么基准比,变了多少。再注明目前哪些信息可信,哪些还待核实。只说"销售不好""用户不满意",还不足以让调查有一个清楚的起点。

注册数据下降,还有哪些原因值得查?

假设现在已经确认,面板记录的"注册完成"事件确实下降了,但真实账户创建数还没查。再看那句"用户不喜欢新页面"。

要查这个猜测,先得弄清用户经历了什么。是看见页面后觉得不信任,直接退出?是填到一半嫌麻烦,放弃提交?还是已经填好了,却怎么也提交不成功?

即使知道用户在哪一步离开,也还不能直接认定原因。

主动退出,可能与页面设计有关,也可能是访客原本就没多大兴趣,或者临时被别的事情打断。填到一半放弃,可能是表单太长、担心隐私,也可能是网络出了问题。提交失败,则可能涉及校验规则、特殊输入格式或外部服务。

这些行为都还需要解释。继续往下查,要看用户在哪个环节退出,退出前停留了多久,以及问题是否集中在某些渠道、设备或人群中。

页面之外的变化也要考虑。新渠道带来的访客,注册意愿可能更低;验证码服务超时,会让想注册的人也注册不了;记录规则变了,则可能只影响面板上的数字。

沿着这些问题,可以列出至少四类候选解释。

先说清几个技术词。"埋点"可以理解成设置在页面或流程中的记录器,用来记录用户操作。"前端校验"是页面对输入信息做的检查,比如手机号格式不对时弹出提示。"分层漏斗"则是把注册过程拆成几步,按渠道、设备或人群分别看每一步有多少人继续、多少人离开。你可以请技术同事帮忙核对,先把要查的问题说清楚。

第一类,测量或口径变化。事件名、触发时点或去重规则调整后,面板数据可能下降,真实账户数却没有变。检查时,可以对照同一批注册行为的新旧记录规则,再与数据库中的独立账户记录核对,看看有没有漏记、重复统计等差异。

第二类,前端校验摩擦。新增字段或校验规则,可能让部分用户提交不了。如果这个解释成立,问题应当能在某些浏览器、设备或输入组合中观察到,比如校验拒绝、程序报错或放弃提交增加。但这几种情况要分开看:拦截不合格输入,可能是校验在正常工作;程序异常涉及代码问题;用户自行退出又是另一回事。它们的记录方式也可能不同,不能一概算作"报错"。

第三类,流量构成变化。新渠道带来的访客,可能原本就不太愿意注册。即使每个渠道内部的注册率都没变,只要低注册率渠道的访客占比提高,总体注册率就会下降。

这种影响也可能反过来发生。高注册率渠道的占比提高,会掩盖各渠道内部注册率的下降,让总体看起来没有变化。因此,既要看每个渠道的注册率,也要看它在全部访客中占了多少。

第四类,外部服务异常。第三方验证码或短信服务超时、失败,都可能阻断注册。如果这个解释成立,应能在相关请求中发现更多超时、重试或失败。比较不同页面版本时,还要先确认它们使用的是同一套服务、调用路径和配置。

这四类解释可以同时成立。比如记录规则变了,漏记了一部分事件;新校验规则又确实挡住了一部分用户。列清单是为了方便调查,没必要为了分类整齐,硬把它们变成只能选一个的答案。

图片

如果真是这个原因,还应该看到什么?

听到有人说"肯定是这个原因",可以接着问这句话。

每个解释都要往下写两件事:如果它成立,我们还应该看到什么;如果看到什么情况,我们会对它产生怀疑。暂时写不出来,可以先把解释说得更具体些,比如究竟发生在哪个环节、涉及哪些用户、需要什么条件。

假设你怀疑,新校验规则让某个浏览器上的用户更容易被拒绝提交。那么,对应的校验拒绝率应该上升。查了记录,却发现没有变化,这能削弱这个解释吗?

先确认你查的记录究竟覆盖了什么。程序错误日志未必记录正常的校验拦截,用户填到一半退出,也不一定会出现在错误日志里。如果相关行为根本没有被记录,"日志没变"就回答不了这个问题。

只有确认记录覆盖了相应的浏览器和输入情况、前后的比较条件也一致,拒绝率仍然没有变化,这个结果才会削弱刚才的解释。预期的迹象没有出现,只有在我们确实有条件观察到它时,才有判断价值。

图片

还有些解释已经说清了机制和预期,却暂时拿不到资料。比如想联系流失用户做访谈,手头没有足够的联系方式。没有取得的证据,当然不能当作事实;但这个解释也不能因此从考虑范围中消失。

尤其当某种原因一旦成立,会带来较大损失时,资料难取更不能成为搁置它的理由。是否值得尽快补证,要一起看证据能帮助区分多少问题、延误可能造成什么损失,以及取得资料需要付出多少成本。

几种解释都说得通,先查什么?

接下来要找的,是能帮助比较这些解释的证据。

比如,"测量变化"指向记录规则的差异,"校验摩擦"指向特定输入被拒绝。账户总数可以提供线索,却不能单独区分它们。

两种机制可能同时发生,真实账户数下降时,仍然可能存在漏记。反过来,校验摩擦造成的损失,也可能被新增流量抵消,让账户总数维持稳定。

所以,查测量问题,要对照新旧记录规则与独立账户记录;查校验问题,则要按输入类型、页面版本和运行环境,查看具体的拒绝或失败情况。

先查哪一项,还要权衡证据的区分价值、取得成本和延误损失。这几条标准未必指向同一个方向。核对口径可能最省力,排查短信服务可能最紧急,而用户访谈也许更有助于分清某两种解释。

判断原因的调查顺序,与止损的处理顺序可以不同。已经发现短信服务超时,可以先处理,不必等所有原因都查清。与此同时,继续寻找最有助于比较解释的信息。

查出数据漏记了,页面还要重做吗?

假设这次查到,改版当天调整过事件触发规则,新旧规则对照后确认存在漏记。系统也保留了足够的原始记录,可以按旧规则重新计算。重算之后,"注册完成"事件的下降幅度明显缩小。

这说明记录确实出了问题,但还不能据此认定新版页面没有问题。总体数据正常,可能掩盖某些人群中的下降。

看一组假设数据。改版前,高注册率渠道 A 有250名访客,注册率为40%,创建了100个账户;低注册率渠道 B 有750名访客,注册率为20%,创建了150个账户。合计1,000名访客、250个账户。

改版后,渠道 A 有750名访客,注册率降到30%,创建了225个账户;渠道 B 有250名访客,注册率降到10%,创建了25个账户。合计仍然是1,000名访客、250个账户。


访客数
注册率
账户数
改版前 A
250
40%
100
改版前 B
750
20%
150
改版前合计
1,000
25%
250
改版后 A
750
30%↓
225
改版后 B
250
10%↓
25
改版后合计
1,000
25%
250

总数没有变化,两个渠道内部的注册率却都下降了。高注册率渠道的访客占比提高,抵消了这部分下降。如果只看总体数据,就会漏掉这个问题。

到这里,团队可以安排下一步了。先修正事件触发规则,再按修正后的口径重新计算注册表现,同时看总体和各渠道的数据。

如果修正后,总量和各渠道内部的注册率都没有异常下降,结合已经确认的漏记情况,可以暂不回滚页面,继续监测。具体观察多久,要看业务周期和数据量。

如果某个渠道内部的注册率仍在下降,就继续查这个渠道是否存在校验摩擦、页面体验等问题。后续监测中,如果某渠道的注册率持续偏离它的历史波动范围,也应重新调查。

临时止损和原因调查可以同时进行,不过每次改动都要留下记录。修正埋点、优化页面、调整服务配置,如果都在同一时间发生,即使数据随后恢复,也很难分清是哪项改动起了作用。因此,要记录版本、时间和变更范围,并保留改动前的记录与日志。

再回到那间会议室。大家开始分工,分别去查埋点版本、真实账户数、前端记录和渠道数据。原来围绕"页面要不要改回去"的争论,终于有了几个可以查清的问题。

溯因推理帮团队列出了值得调查的解释,也指出了下一步该找什么信息。后面仍要比较和检验。

正式比较多个解释时,可以使用竞争性假设分析等方法;根据新证据更新概率,可以使用贝叶斯更新等方法;判断某个因素是否具有因果作用,则需要相应的因果识别方案。日常调查未必每种方法都用上,但至少要知道,自己手里的是线索、支持证据,还是足以作出判断的结果。在医疗、法律、合规、人事等高风险情境中,不能仅凭未经验证的候选解释作出结论。

AI列出了一堆原因,接下来该追问什么?

可以把异常描述和已知背景交给 AI,请它列出机制不同的候选解释,再为每个解释补充预期迹象和检验问题。

AI写出来的文字往往很流畅,这种流畅会让人忽略其中还有多少猜测。要留意 AI 有没有过早锁定某个解释,以及它列出的几条原因,是否只是同一个意思换了几种说法。

把这些解释放在一起比较,再追问:哪两个最难区分?查到什么信息,才应该改变目前的判断?

下次复盘,先把这四个问题问清楚

遇到指标突变、用户流失或转化下降,可以先用这四个问题整理讨论。

第一,我们确认发生了什么? 哪些数据核对过了?与什么对象、什么时间段作比较?还有哪些信息没查清?

第二,除了最先想到的那个,还有哪些可能的解释? 先各自写,再放到一起讨论。第一个听起来合理的解释,很容易把后面的思路都带向同一个方向。

第三,如果真是这个原因,还应该看到什么?什么情况会削弱它? 这个解释成立时,本来应该出现什么迹象?我们目前有没有条件观察到它?写下预期迹象,也写下什么结果会让自己改变看法。

第四,下一步查什么,最有助于比较这些解释? 选能帮助区分不同解释的信息。同时分清楚:哪些问题需要马上处理,哪些可以等证据回来再定。

把要查的资料和负责人定下来,下一次讨论就能带着新证据回来。


模型档案卡

模型名称

溯因推理(Abductive Reasoning)

一句话定义

针对已经核对过的异常现象,依据已有知识提出一个或多个假设。假设若成立,应能解释眼前的现象,但假设本身仍需后续证据检验。

来源

皮尔士(Charles Sanders Peirce)在1867年已区分三种论证类型,1878年在《演绎、归纳与假说》中系统讨论,二十世纪初又作了进一步发展。在这一探究过程中,溯因提出假设,演绎推出预测,归纳通过观察和实验进行检验。

调用口诀

先核对,再列解释;写出预期和削弱条件,选能帮助区分的证据继续查。

使用边界

溯因推理不能独自确证原因,后续还需比较和检验,必要时配合概率更新、因果识别等方法。高风险情境中,不能仅凭未经验证的候选解释作出结论。

这是思维模型系列的第 104 篇。

下次复盘,可以和团队一起试试这四个问题。把已经确认的事实、目前的猜测、下一步要查的证据写清楚,再分好工。转给一起做项目的同事,下次有人说"肯定是这个原因",就顺着问一句:"如果真是这样,我们还应该看到什么?"