作为产品经理，关注数据是一项基本工作。工作里常常会出现关注的指标或数据出现波动，或者在分析某个功能时发现难以理解的数据的情况，这时候我们需要去分析数据波动的原因，而我也和大家分享一下我的分析思路。

1. 确认数据源准确性

很多时候数据的问题仅仅是数据的问题。如果遇到一个数据波动或异常我们无法简单地分析出原因时，可能就要想想是不是数据源出了问题。

数据源可能是我们的业务数据库，如商品价格、销售额这些数据；也可能来自用户行为，如用户的点击、浏览等事件，这些数据源都极有可能出现问题，例如业务数据库同步出现问题，用户行为的采集、上报不准确等等。

有时候我们一股脑地从产品角度去分析，最后确实数据本身的问题，会做很多无用功。所以遇到一时间分析不出原因的问题，首先要考虑是不是数据源出现问题。这时候就得联系公司的数据产品经理、前后端行为上报方、大数据的研发确认。

一般有以下几个常见的因素会导致数据源准确性问题：

• 前端上报的事件与产品的定义不符：例如有的页面可能会预加载，从产品的角度看，预加载是技术的处理方式，不能算是用户的行为。但是前端往往会将预加载的事件不做区分地上报，导致数据与预期不符。
• 服务器重构/技术优化：服务器的工程师们不时会进行技术优化，这部分优化产品常常是难以感知的，同时又容易造成数据波动。例如有一次我司的Push发送量突然大增，定位问题发现是技术大大们对发送Push的服务器进行了优化，优化后目标用户量不变，单位时间发送量（QPS）提高，导致原本在规定时段内（如20:00~22:00）没有发完的push现在可以全量发完了。
• 大数据统计逻辑：产品使用的数据往往不是底层数据，而是大数据组研发们在底层数据基础上进行的聚合，在这个过程中，就有可能出现定义不一致的情况。这类问题建议先与数据产品经理沟通，根据我的经验，除非产品经理对数据侧比较了解，否则直接与数据组的研发沟通，沟通效率会比较低。

2. 维度下钻分析

要探索一个指标异常的原因，一个十分重要的工具就是维度下钻。通过从不同维度和不同力度的下钻，我们能够一步一步接近问题的本质。

例如一个页面的UV占比不断的下跌，我们就可以从新/老用户、页面各个入口流量、页面各板块点击等维度下钻进行分析，定位问题。

比如说我们通过新/老用户区分分析发现新用户进入该页面UV出现了显著下降，而老用户较为稳定，则可以猜测是新用户的引导方面出现了问题。

3. 抓住重要节点

第三点其实也属于第二点的一种情况，是从时间的维度去分析问题——数据通常都是会在一个时间点开始发生变动，这时候我们就得去研究这个时间点发生了什么事，是上线了新版本，还是调整了数值，或者有什么活动开始了。

无论是维度下钻或是抓住重要节点，本质上其实是通过对比找到问题。不同时间段的纵向对比，不同用户群体的对比，同业务线不同产品数据对比，都是我们快速定位数据问题的利器。

4. 持续性缓慢变化

最难的一种数据问题是缓慢变化的数据，即数据没变化没有明显的时间节点。这种问题是最难定位的。出现这种情况时，需要考虑一些随着时间改变会逐渐优化/恶化的因素。

例如我们公司有一次出现了一个指标长达3个月的缓慢小幅下降，大概每一周下降0.5个点，大家抓破脑袋研究很久以后，终于找到原因：我们使用了数美的一款异常用户拦截产品，这款产品自身会根据大数据不断优化，提高拦截准确性，拦截率会随时间缓慢提升，从而导致我们相关指标的不断下降。

所以这种异常会跟一些会随时间缓慢变化的因素相关，例如推荐算法的不断学习，用户习惯的缓慢改变等等。

5. 不要想当然，不放过任何细节

有时候原因就在眼前，只是我们想当然地觉得不可能是它，于是视而不见。

有一次我们的产品新增留存突然下降4%左右，这算是一个非常严重的问题了。老板紧急召集各负责人分析人，在经过八仙过海各显神通的集思广益后，排除了各种原因，发现数据变化的时间点与新版本发布有关。最终找到问题所在是新包内容比旧包增加了30mb左右，用户更新内容时会在更新页面多等待数十秒，因为增加的这几十秒导致敏感的新用户流失了4%左右。

在一开始，所有人都想当然地觉得这30M的体积不会造成如此大的影响，产品团队在排除掉几乎所有可能的因素，才在最后定位到这个问题。

新用户是最敏感的用户群体，任何等待、崩溃、体验不佳都可能导致用户留存下降。

针对这个问题，我们升级了更新策略，使用静默更新，即玩家进入app后如果有l更新资源，则原生就开始静默下载新内容。同时丰富更新页面的内容，使玩家在更新页面不那么枯燥，降低退出率。

作者：kakarotto；公众号：原住民的自修室

本文由 @kakarotto 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议