产品数据最容易让人误会的地方，是它看上去很像答案。转化率掉了、某一步停留变长、回访少了，图上都清清楚楚。可这些只是记录下来的结果，原因还在图外面。
看到漏斗变化，我第一反应通常不是给它配一个故事，而是去看埋点定义和产品路径。说实话，有些波动查到最后也只能确认一件事：现在的证据还不够。这个结论不漂亮，但比把猜测写成事实稳妥。
先查有没有量错
我会从事件本身查起：它在什么时候触发，重复操作会不会多记，某个页面或版本有没有漏记。产品已经改过，埋点文档却没跟上，也会让同一个字段前后表达两件事。
假设某一步转化突然下降，设备分布也在同一时间发生变化。这里有两种可能：用户行为确实不同，或者某一端的记录出了问题。在确认之前，直接讨论页面文案或交互原因还太早。
这部分工作不显眼，常常只是对字段、核对触发条件、顺着路径重走一遍。它却决定了后面的分析有没有起点。
把数字放回产品里看
记录没有问题，才轮到解释。漏斗把一段复杂经历压成几个步骤，便于比较，也会省掉很多细节。用户从哪里来、当时想完成什么、页面给了哪些选项，都会改变同一个退出事件的含义。
停留变长就是个常见例子。阅读页面上，它可能代表用户愿意花时间；操作流程里，也可能是入口难找。拆分人群和场景时，我会先说明为什么要拆，免得在许多切法里挑中一个最抢眼的结果。最后得到的解释也许很窄，不过边界清楚，下一步才知道该查哪里。
历史数据分不出来时，再做实验
几个原因都说得通，历史数据又只能说明它们同时发生，这时实验才有用。动手前，我会写清楚想改变哪种行为、主要看什么结果，以及什么情况会让我改掉原来的判断。
看完结果再换关注指标，很容易找到一个看起来不错的角度。可实验原本想回答的问题也跟着丢了。主要指标要提前定，可能受影响的其他环节也要留意，尤其要防止一个步骤变好、后面的体验反而变差。
实验也可能没有给出明显差异。样本是否足够、改动是否真的触达目标行为，都需要回头检查。有时最合适的处理就是暂时不下结论，再改设计或补一次观察。
写到证据能到达的地方
分析写到结尾，最怕一句笼统的“指标下降了，建议优化”。我会把观察到的变化单独写清，再说明目前更像哪种解释、依据是什么。还没确认的部分，直接标出来。
下一步未必总是改产品。也可能先修埋点，缩小问题范围，或者什么都不动，继续观察。数据工作很少替人做完决定，它更像是把可用的证据摆整齐，让讨论少绕一点路。