> 原文出处：http://blog.devtang.com/blog/2015/09/03/how-to-monitor-data/ > 作者：唐巧 [TOC=2] ## 前言 上一篇文章中，我们介绍了为什么要关注数据，在本文中我将分享具体如何做。 ## 关注宏观和细节 大多数人都能做到关注宏观的数据，拿互联网产品来说，日活，月活，流失率，NPS（净推荐值），这些都是宏观的数据。宏观数据能够反映出产品的整体状况，是值得长期关注的。 但是在宏观之外，我们还应该关注一些细节的数据。拿日活来说，我们可以再进一步进行分析，比如： * 日活中新用户所占的比例 * 日活中 iOS 和 Android 的各自占比 * 日活中大家集中活跃的时间段 * 日活中用户的会话（Session）次数分布，时长分布 * 日活中用户平均使用你的产品核心功能的次数 当你把数据拿放大镜看得更细的时候，你可能就会发现一些问题。带着这些问题，你进一步分析，就可以找到更多信息。 举一个我们创业产品小猿搜题的例子，我们发现日活中的用户，有相当一部分用户只是注册了，但是并没有使用我们产品的核心功能，于是我们担心会不会有一些付费推广渠道「刷量」。 所以，我们将新增用户中不活跃的比例按渠道来划分。通过这样的划分，我们很容易找到那些效果差的渠道，从而选择更有效的推广渠道。 ## 关注原始数据 原始数据是什么？就是那些不是通过别的数据计算出来的，不能被分割的数据。这些数据是最最真实的，而其它通过计算出来的数据，因为进行了二次加工，所以不一定能够完全反映出产品的问题。 再举一个小猿搜题的例子，我们为了研究 NPS 给我们打零分的用户。把这些用户的搜索数据、操作记录都抽样出来，一个用户一个用户看，然后进行分类整理。最终我们发现这里面小学生用户占比很高，从而调整了产品的策略，在内容和算法上对小学生进行了兼顾。 关注原始数据除了能改进产品外，还能在技术上提高代码的质量。我们曾经遇到过一个很难复杂的 Bug，在我们的测试机中都无法复现，但是我们通过分析相关用户的操作记录，找到了具体崩溃的操作方法。 虽然该操作方法不能在我们自己的机器上复现 Bug，但是我们却能找到相关的关键代码。通过一些针对这些代码的讨论，我们就找到了 Bug 的原因。现在回想起来，如果没有这些原始数据，要修复这个 Bug 就要困难很多了。 ## 关于面试 其实不光做产品要看「原始数据」，面试一个人也是。我在面试的时候，会选一个候选人简历上的事情，进行深入了解。我会让他提供详细相关工作的数据和事例。通过这些「原始数据」，我能够更加方便地「还原他真实的工作场景」，从而对他的工作质量作出尽量客观的评价。 举个例子，有一个产品实习生候选人在简历上写他运营了一个微信公众号，「粉丝逾千，单日粉丝增量 200 以上，数篇文章阅读量超过 3000」。但是在面试中，详细追问这些数字，我们才发现他说的「逾千」是指 1000，而「单日粉丝增量 200 以上」是指的最高的一天，其它信息也都是有夸大的成分。 还有一次，我面试一个技术候选人，这个候选人说他有代码洁癖，觉得前公司的代码「很乱，受不了」。但是我让他具体举几个例子的时候，他却很难说出实际的例子。还有候选人说他喜欢看技术书，但是却无法说出他印象最深的一本技术书以及其中的部分观点。 通过了解细节，我们就可以揭开简历中光鲜描述的外衣，了解到事情背后的细节，这对我们评价候选人至关重要。 ## 数据可视化 数据可视化是指将原本枯燥的数据，用折线图、饼图、柱状图等方式呈现出来，它可以使我们更容易发现数据的规律，也更容易发现数据的异常。 在小猿搜题项目中，数据可视化多次给我们带来巨大的帮助，包括： * 了解数据的特点：我们将小猿搜题的 QPS 按每小时为频率画出成一条折线图，所以我们很容易知道我们服务器高峰期的时间段以及访问量。 * 发现服务异常：我们将服务器搜索的失败率占比画出成一个饼图，有一天，这个饼图中显示出失败率突然变高了。同时，每日的 NPS 分数突然也变低了很多。我们借此发现了新扩容的一台服务器故障。因为那台服务器是新加的，所以运维忘记了增加监控，如果没有数据可视化的帮助，这个故障可能会持续更长时间。 * 监控核心质量：我们将小猿搜题的一些核心指标画成折线图，然后大家都努力让核心指标更优。 * 发现恶意攻击：一些重要指标，我们都会可视化出来，这样当这些数据指标变化时，我们就会进一步分析原因，从中我们还发现了一些竞争对手恶意的攻击行为。 ### 数据可视化工具 我们当然不可能所有的数据可视化都是自己手工用 Excel、Numbers 之类的工具来生成。所以，我们开发了一个数据可视化的平台，我们把它叫做 flyboard。 flyboard 提供了各种数据可视化的方式，包括数字，折线图，饼图，环形图，柱状图等。如下图所示：  我们将所有的原始数据都归集到分布式存储 [Hbase](http://baike.baidu.com/view/1993870.htm) 中，然后通过配置一些定时的计算任务，就可以以几乎实时地方式，看到产品的各项可视化指标。 这些指标，有宏观的，也有一些比较细分的，如果我们对某项指标的数值有疑问，我们就会进一步写一些分析脚本，来从 Hbase 中计算一些数据进行检查。 在猿题库公司，我们的三个产品（猿题库、小猿搜题、猿辅导）的办公区域，都挂着一个巨大的显示器，这个显示器除了用于 Scrum 的每日站会同步进度外，平时都用 flyboard 显示着产品的各项核心数据。 悄悄告诉你一个秘密，我们的 flyboard 可视化平台是开源的，项目地址是：[https://github.com/yuantiku/flyboard](https://github.com/yuantiku/flyboard) ，在 Github 上你可以下载到完整的代码，我们也附有完整的安装使用说明文档。如果你还没有使用任何数据可视化工具，欢迎尝试一下 flyboard。 ## 学习写 SQL 由于有 [Hadoop](http://baike.baidu.com/view/908354.htm)、[Hbase](http://baike.baidu.com/view/1993870.htm) 、 [Hive](http://baike.baidu.com/subview/699292/10164173.htm) 的存在，产品经理也可以通过一些简单的 SQL 语句，就可以生成 [MapReduce](http://baike.baidu.com/view/2902.htm) 任务，进行分布式的数据分析运算。 所以数据分析最最常用的办法就是写 SQL。在很多公司，产品经理都在这方面能力比较欠缺，这使得产品经理在需要数据时，需要向技术提需求。技术会根据自己的工作排期。这样一来一回，一般一个简单的数据分析都需要一天时间。 这样的低效率的方式，会扼杀产品经理的一些数据分析需求，特别是那种需要探索式发现的数据分析工作。因为这种工作需要不停地根据数据分析的结果，调整各种策略来写尝试的 SQL。 所以在猿题库，我们希望产品经理都能有基本的数据分析能力，一些简单的 SQL 都是需要自己能够写的。当然，一些特别复杂的 SQL，产品经理可能还是需要向技术同事咨询。 具体如何写 SQL，市面上已经有非常多的相关书籍了，我在这里就不再展开介绍了。 ## 数据查看和分析一定要方便 如果你仔细观察就会发现，很多革命性的产品就只是让某件事情更方便了一点点。智能手机其实只是让你上网更方便了一点，但是这种方便使得人们从以前有「离线和在线」的状态，变成了永久在线。于是，移动互联网诞生了，本质上来说，移动互联网就是一种人们永久在线的网络，但是就是这么一点点的方便，使得很多行业被完全颠覆。 而数据分析也是一样，我们应该尽量让数据触手可得，这样我们才能将数据分析的效率最大化，一定程度上的效率提升就会产生质变，使得我们专注于数据做更多事情。 我们之前移动端统计用 Flurry，但是 Flurry 在中国实在太慢了，即使挂上国外的 VPN 也很慢！如果产品经理每次登录 Flurry 要 10 秒钟的话，那么他就可能将注意力临时转移到别的事情上，然后就可能忘记本来要看的数据。 为了让数据触手可得，我们放弃了对 Flurry 的使用，我们自己开发了日志收集平台，然后自己写日志计算程序，将一些核心指标全部自己计算在 flyboard 上，我们也另外开发了一套数据分析平台，实现 Flurry 中的类似功能。现在，我们已经能够非常舒服地分析数据了。 所以，如果你的公司不能很方便的查看和分析数据，那么一定要想办法改进，这些数据就像人的神经系统一样，传递着产品的健康数据，重视这些数据，才能够做好产品。 ## 总结 总结一下本文中的观点： * 重视宏观数据和细节 * 关注原始数据 * 数据可视化 * 学会用 SQL * 数据查看和分析一定要方便

> 原文出处：http://blog.devtang.com/blog/2015/09/02/why-we-need-monitor-data/ 作者：唐巧  [TOC] ## 前言 由于科技的进步，以及数据「数字化」地存储，使得现代人类可以获得海量的数据。而有了这些海量的数据之后，借助于一些数据分析工具和方法，我们就可以从数据中找到社会运行的「秘密」。 在工作中，借助这些「秘密」，我们有可能发现商业中的新机会，也可能验证或推翻自己的一些猜想。数据分析，使得我们对「秘密」的探索有了一个可靠的方法。 在本文中，我想分享一下工作中学到的发现数据中秘密的心得。 ### 稻盛和夫的故事 我们先看看 [稻盛和夫](http://baike.baidu.com/subview/974414/5032771.htm) 挽救日航的故事吧。他的这段传奇经历曾经被很多媒体报道，我将故事摘要如下： > 2010 年 1 月 19 日，日本航空公司申请破产保护。日航有 58 年历史，一度被视作日本战后经济繁荣的骄傲象征。 > > 2010 年 2 月 1 日，受日本首相邀请，稻盛和夫答应出日航董事长，一年之后，日航扭亏为盈，利润是对手全日空的三倍。 仅仅用了一年时间，日航做到了三个第一，一个是利润世界第一，一个是准点率世界第一，一个是服务水平世界第一。 在日航重新上市之后，稻盛和夫分享了他 [挽救日航的秘密](http://money.163.com/12/1026/01/8EN3V9EN00253B0H.html)。这里面涉及的内容很多，其中有很重要的一条，就是稻盛和夫非常重视日航具体的运营数据，他花了很大的力气来优化数据的获取，从而能够对日航的现状进行判断。 稻盛和夫是这样说的： > 我担任董事长后，最为吃惊的是，公司的各项统计数据不仅不全，而且统计时间很长很慢，往往需要 3 个月之后才能搞全数据，以至于经营者无法迅速掌握公司的运营情况。 所以，在对企业内部进行改革时，我特别关注统计工作。经过改革，现在各个部门的数据做到即有即报，公司详尽的经营报告，做到了一个月内完成。 如果把日航看过一个生病了的病人，稻盛和夫的做法其实和现代医学的做法类似，就是首先进行各项检查，获得病人的身体指标信息，有了这些检查数据，我们就可以利用各种基于数据的经验，来进行病情诊断和治疗。所有的治疗手段又可以通过再次的检查来验证，从而进一步改进治疗方法。 人做为一个生命体，全身密布的神经负责着各种信息的传递，所以我们的大脑能够接受到各种信息，从而做出决策，饿了吃饭，冷了加衣服，保证着我们身体的健康。 而企业没有天生的神经系统，所以数据收集和分析就显得异常重要了。日航作为一家运营了 50 多年的公司，居然在这方面做得非常差，难怪会进入破产的边缘。而稻盛和夫用的办法也很简单，先让数据能够收集起来，那么后续依据数据做决策就不再那么困难了。 ## Monitor your data（监控你的数据） 我刚毕业的时候加入的是网易公司，当时负责做网易邮箱的底层 Restful Api。当时我们部门的老大郭常圳常常讲要「monitor your data」，我当时作为一个应届生，刚开始对这个口号不太理解。我当时想：数据当然是重要的，但是也不值得老挂在嘴边讲吧？但是后来我才慢慢发现，这其实确实非常重要。 作为程序员，我们开发一个后台服务，大家有没有测试过以下数据： * 这个服务能够承受多少的 QPS（每秒访问量）？ * 平均响应时间和 99% 的响应时间是多少？ * 如果服务器压力增加，我们能不能通过简单的加机器来解决，需要加多少台机器？ * 当前线上服务瓶颈在哪里？ * 按当前的增长速度，多久我们得需要加机器？ 当时郭常圳带领我们，将我们做的每一个服务都进行了详细的压力测试，我们对于我们的服务承受力有着非常详细的数据测试结果。 这一点每个公司都做到了吗？其实不是。我还记得我们后来和网易的网站部共同开发网易微博后台，当时我们因为要将邮箱微博和网易微博数据合并，需要进行在线的数据迁移。我当时负责数据迁移工作，在我向网站部询问我应该用多大的请求压力来迁移数据时，对方只是回答：“尽量慢点”。 我当时就傻掉了，谁能告诉我什么叫 “尽量慢点”？于是我只能小心翼翼，一点一点地增加压力，最后我发现，他们的数据库其实一点压力都没有，我根本就不用控制压力都不会影响线上服务。但是，由于他们「monitor your data」做得不好，所以他们对任何可能的压力都心怀恐惧，不敢乱动。 后来我也私下和他们求证了一下，他们果然完全不知道他们的服务器能够承受多少 QPS。大家也可以问问自己公司的服务器同事，自己的服务器能够承受的 QPS 是多少，就知道自己的公司在这一点上做得好不好了。 而现在，数据驱动的思维更加深入到互联网开发中了。因此，国外的 New Relic 这类公司，才可以获得上亿美金的估值。 New Relic 的工作原理是放很多小的探针到你的程序代码中，这些探针收集到非常详细的程序运行数据，就可以为你优化服务器提供有效的建议。 ## 产品上的「monitor your data」 如果说技术上的「monitor your data」只是影响服务稳定性的话，那么产品上的「monitor your data」就会决定产品的成败了。 我认为产品上的数据分析有以下作用。 ### 验证想法 在互联网行业工作这么多年，我发现了一个秘密，就是任何新的互联网产品，都不是靠用户调研或数据分析来的。 因为用户调研非常难做，稍不注意就会被别的因素影响，所以乔布斯曾经说他从来不做用户调研。而数据分析对于一个新产品来说，会陷入无米之炊的尴尬境地。 所以很多新产品的第一版都是创始人或产品经理「拍脑袋」的产物。这一点其实是非常现实的做法。「拍脑袋」依赖于创始人的经验，如果创始人经验丰富，那么很可能产品对了 7 分，错了 3 分。另外那 3 分的错误假设，可以在产品上线后迅速通过数据来验证，从而迭代修正这些假设。 所以数据分析对于产品来说，第一大作用就是验证（或推翻）产品经理的假设，从而使产品能够得到快速迭代改进。 ### 发现新的秘密 很多时候，数据分析不光会得到你的产品本身的状态，还会发现一些新的机会。借助这些新发现，我们对产品产生新的认识。 拿我们的创业产品「小猿搜题」来说，我们一直在监控它的  [NPS（净推荐值）](http://baike.baidu.com/item/%E5%87%80%E6%8E%A8%E8%8D%90%E5%80%BC/3783368) 数据。为了把数据分析得更加细致，我们把打 NPS 0 分的用户行为进行了抽样分析，最终我们发现，虽然我们的 slogon 叫「初高中拍照搜题利器」，但是却有大量的小学生用户在使用我们的产品。 我们并没有为小学生做任何的产品上的优化，所以造成了这部分用户没有被很好的满足。所以，我们最近在内容和搜索算法上针对小学生做了特别优化，同时将产品的 slogon 修改成了「中小学拍照搜题利器」。 如果没有细致的数据分析，我们可能就错过了几千万的潜在用户。 ### 发现数据规律 一个产品会有非常多的指标，日活，月活，留存率，年龄分布，用户使用习惯等，产品经理应该对这些指标了如指掌，在对这些数据熟悉之后，产品经理就可以发现数据中的变化规律或异常点，从而对产品带来一些改进。 在这一点上，我喜欢讲林彪的一个故事。 > 1948 年辽沈战役开始之后，在东北野战军前线指挥所里面，每天深夜都要进行例常的 “每日军情汇报”：由值班参谋读出下属各个纵队、师、团用电台报告的当日战况和缴获情况。 > > 那几乎是重复着千篇一律的枯燥无味的数据：每支部队歼敌多少、俘虏多少；缴获的火炮、车辆多少、枪支、物资多少。 > > 司令员林彪的要求很细，俘虏要分清军官和士兵，缴获的枪支，要统计出机枪、长枪、短枪；击毁和缴获尚能使用的汽车，也要分出大小和类别。 > > 经过一天紧张的战斗指挥工作，人们都非常疲劳。整个作战室里面估计只有定下这个规矩的司令员林彪本人、还有那个读电报的倒霉参谋在用心留意。 > > 1948 年 10 月 14 日，东北野战军以迅雷不及掩耳之势，仅用了 30 小时就攻克了对手原以为可以长期坚守的锦州之后，不顾疲劳，挥师北上与从沈阳出援的敌精锐廖耀湘基团二十余万在辽西相遇，一时间形成了混战。战局瞬息万变，谁胜谁负实难预料。 > > 在大战紧急中，林彪无论有多忙，仍然坚持每晚必作的 “功课”。一天深夜，值班参谋正在读着下面某师上报的其下属部队的战报。说他们下面的部队碰到了一个不大的遭遇战，歼敌部分、其余逃走。与其它之前所读的战报看上去并无明显异样，值班参谋就这样读着读着，林彪突然叫了一声 “停！” 他的眼里闪出了光芒，问：“刚才念的在胡家窝棚那个战斗的缴获，你们听到了吗？” > > 大家带着睡意的脸上出现了茫然，因为如此战斗每天都有几十起，不都是差不多一模一样的枯燥数字吗？林彪扫视一周，见无人回答，便接连问了三句： > > “为什么那里缴获的短枪与长枪的比例比其它战斗略高”？ “为什么那里缴获和击毁的小车与大车的比例比其它战斗略高”？ “为什么在那里俘虏和击毙的军官与士兵的比例比其它战斗略高”？ > > 人们还没有来得及思索，等不及的林彪司令员大步走向挂满军用地图的墙壁，指着地图上的那个点说：“我猜想，不，我断定！敌人的指挥所就在这里！” > > 随后林彪口授命令，追击从胡家窝棚逃走的那部分敌人，并坚决把他们打掉。各部队要采取分割包围的办法，把失去指挥中枢后会变得混乱的几十万敌军切成小块，逐一歼灭。 > > 廖耀湘对自己静心隐蔽的精悍野战司令部那么快就被发现、打掉，觉得实在不可思议，认为那是一个偶然事件，输得不甘心。当他得知林彪是如何得出判断之后说，“我服了，败在他手下，不丢人。” 有些时候，一个数据中的异常点，就是一次决定性的机会。而产品经理只有做好「monitor your data」，才能抓住这样的机会。 ### 培养产品直觉 有一些产品，产品经理自己就是目标用户，所以可以比较容易用同理心来分析出用户的需求。但是像我们猿题库这次创业，目标用户都是初高中生，我怎么知道这些 00 后的需求、想法和兴趣爱好？ 除了多和他们聊天，多用他们喜欢的产品外，分析他们的行为数据也至关重要。郭常圳常常说：“我们做产品要有场景化思维，要还原用户当时真实的使用场景”。而通过分析一些用户使用数据，就有助于我们还原用户使用场景。 这种事情做得多了，我们就会更加了解用户了，慢慢就形成了产品的直觉。 ## 总结 关注数据和数据分析能力，是互联网时代生存的基本技能。不管是做产品还是做技术，养成「monitor your data」的习惯，都可以让你将工作做得更加出色。 本文讲完了为什么要关注数据，在下一篇里，我将分享具体如何做。