上个月咱们了解到埋点数据从上报到生成报表大体分为五个关键环节：

埋点->上报->后台记录日志->计算&入库->展示

今天咱们介绍下统计数据出问题后，一般的原因有哪些，应该如何跟进。

1、报表数据为0

一天，韩梅梅找到李雷

韩梅梅：『老李啊，咱们这个版本新加的埋点怎么报表上都是0啊？』

李雷（惊讶的）：『啊？我看看！』

老李为啥会『惊讶』呢，因为这个数据的上报在版本上线前已经测试通过了。不过，为了保持程序猿做事的严谨性，老李还是通过『抓包』或者『查日志』的手段确认了客户端功能无误，然后果断的找到负责后台数据统计的同学，将问题抛给了他们。

小编点评：

数据有上报而报表数据为0，这种问题一般会出现在『计算&入库』和『展示』环节。因为『上报』和『后台录入日志』这两个过程是与具体的埋点功能无关的，它们对应的逻辑和功能相对稳定。而『计算&入库』和『展示』环节则多需要根据不同的统计需求做修改，所以在验证客户端埋点功能正常后，最有可能出问题的就是这两处。如果出现这种异常，向韩梅梅一样，先找到李雷确认功能正常后，再联系后台负责数据统计的同学跟进，一般情况下，异常的数据都是可以恢复的。如果不幸确实由于客户端的Bug导致数据没有上报，那数据就只能等下个版本修复了。（韩梅梅：『胡说，不是还有热补丁吗？』好吧，产品会技术，谁也挡不住，小弟佩服！）

2、报表数据大面积突降

韩梅梅：『老李啊，怎么今天咱们的日使用、在线时长、点击量…（此处省略一万个数据名词）都比平时少了一半？』

李雷（胸有成竹地）：『我找人帮你看看！』

老李从运维同学处了解到，昨天对服务器上的日志进行了迁移，由于迁移数据迁移过程太长导致一些日志没有参与『计算&入库』，等下会重新部署昨天的统计任务，恢复数据。

小编点评：

如果已经稳定很久的报表，突然出现大范围的数据突降，先找找运维同学吧，看看最近日志分析系统有做策略调整或者日志迁移，导致报表中只收录了部分日志的数据。如果是的话，不用担心，即便你不找上门，运维同学也会主动跟进，把数据恢复的。

3、报表数据突增

韩梅梅：『老李啊，这两天咱们没做什么推广，怎么天天乱跑的下载量突然上涨了好几倍？是不是你又出Bug了？』

李雷（无辜地）：『怎么可能！』

老李当然无辜了，心中一万匹羊驼：『产品没做推广，我们程序猿也改不了线上版本的代码啊，前几天还正常运行的统计逻辑，突然到某一天错乱了，你以为我写的是『千年虫』啊』。

小编点评：

线上的单个数据或者相关的几个数据突然出现异常增长，很有可能是被人恶意刷量。要确定这种问题，直接找数据组的同学查下原始日志，确认下是不是有个别IP或者用户ID对应的PV数量明显异常。如果这样都查不出来异常原因，恭喜，你提前完成了KPI！

4、历史数据出现问题

韩梅梅：『老李啊，今天做数据对比的时候，发现去年3月份的曝光量数据好像不大对，你快帮我看看啥原因？』

李雷：。。。

其实老李想说『你把我小时候弄丢的奶嘴找回来，我就帮你找曝光量不对的原因！』

小编点评：

要确认问题的原因，上报数据的原始日志是十分重要的线索。报表中的数据，可以追溯到几年前，但是原始日志由于数据量太大，可能只会在服务器存储几个月甚至几天。所以，对于这种要求，程序猿只能说『臣妾做不到啊！』。

5、报表数据明显低于预期

韩梅梅：『Lucy，昨天咱们的新版本访问这个页面的只有6人，看来咱们高估了用户的需求。』

Lucy：『是啊，太出乎意料了，我预计至少应该有3000人访问呢。』

李雷听到了韩梅梅和Lucy的对话，默默的在开发中的版本上修复了这个关键路径数据漏报的Bug。

小编点评：

这种问题找负责埋点同学准没错，肯定是遗漏了重要的用户路径，重新埋点吧。

6、业务流复杂的漏斗统计数据异常

在一个韩梅梅刚刚建立的群中

韩梅梅：『@all 昨天投放的天天乱跑推广Banner只带来了5个新增，请大家帮忙看下原因！』

群里的一百多号人认真的读完了韩梅梅发来的消息后，就各自继续忙自己之前的工作去了。

小编点评：

从push下发banner数据到用户成功安装应用，中间需要经过多个业务能力的配合，如果漏斗中的数据出现异常，只需要逐级找相关负责人确认数据即可。一股脑将所有相关不相关的人员全部拉到一起，只能证明自己业务能力的低下，而且这样做往往会导致事情变得负杂，降低问题跟进的效率。实在不了解整个流程的话，找个负责任的开发协助你一下吧。

小编总结：

常言道，常在河边走，哪能不湿鞋。常年埋统计数据，咋还能不让数据出个错呢。然而如果产品经理如果能做到以下几点，随不说可保万无一失，即便遇到问题也必定游刃有余，应对有方：

1. 及时关注重要数据，有问题及时发现、反馈，有助于程序猿找Bug。
2. 影响埋点数据的因素考虑清楚，如果数据出现异常，原因是否可追溯，如有需要，可以多设置几个辅助埋点。
3. 一些重要的数据埋点可以跟技术同学一起讨论制定。
4. 除了熟悉自己负责的业务外，外围业务也要了解。
5. 多关注『给产品经理讲技术』中的技术科普性文章（我很认真的哦~），增强自己对问题的认识、分析能力。

相关阅读：

《整天看用户埋点数据，知道数据是咋来的吗？》

《产品后悔药来了，讲讲热补丁技术》

《妈妈再也不用担心我的需求赶不上版本发布了》

PS：

如果一个稳定了很久的数据报表在某一个天突然发生异常，看看那几天有没有一下情况出现：

1. 客户端或者前端发布新版本
2. 后台日志系统是否近期有调整
3. 数据统计服务是否近期有调整

如果数据异常事件正好与上述三个事件中的某一个重合，数据异常的原因十有八九就是它造成的了。可记好了哦，这个诀窍一般人我不告诉他~

#专栏作家#

给产品经理讲技术，微信公众号（pm_teacher），人人都是产品经理专栏作家。资深程序猿，专注客户端开发若干年，对前端、后台技术略懂，热衷于对新的科技领域的探索。

本文原创发布于人人都是产品经理，未经许可，不得转载。