统计数据出问题，产品经理应该怎么办？
2016/3/13 人人都是产品经理

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

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

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

     及时关注重要数据，有问题及时发现、反馈，有助于程序猿找Bug。

     影响埋点数据的因素考虑清楚，如果数据出现异常，原因是否可追溯，如有需要，可以多设置几个辅助埋点。

     一些重要的数据埋点可以跟技术同学一起讨论制定。

     除了熟悉自己负责的业务外，外围业务也要了解。

     PS：

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

     客户端或者前端发布新版本

     后台日志系统是否近期有调整

     数据统计服务是否近期有调整

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

     专栏作家

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

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

     起点学院《首席运营官实战训练营》4月北京、深圳、广州三地同时开课，猛戳“阅读原文”抢占座位

    http://weixin.100md.com
返回 人人都是产品经理 返回首页 返回百拇医药