精益商业思维

先说数据收集。数据收集有漏斗式、切片分析、A/B测试、灰度测试等多种方法，在此不详细展开，只给大家简单讲一讲。

漏斗式数据分析对于电商特别常用。比如，有多少人在网页上浏览了这件商品，又有多少人把它添加到购物车里，最后实际上有多少人成功支付，每一层的折损率都反映在数据上面。把整个流程画出来，随着用户流失，就像一个层层筛选的漏斗，所以人们管它叫漏斗式数据分析，如图5-1所示。

漏斗式数据分析的核心目的是要做什么？要降低每一批用户被漏斗筛选掉的比例。

为什么浏览这个品类商品的人，只有40%放入购物车了？可能是因为他们具体想要的某品牌的东西在这里没有，所以他转去其他网站了。

为什么已经放入购物车了，但最后没有生成订单，或者订单已经生成了，最后却没有支付？很可能是消费者在其他电商网站发现了更便宜的同类商品，或者这里不支持他想使用的支付手段。

做漏斗式数据分析，就是为了找出各种可能导致客户留存减少的因素，努力把衰减降到最低。

还有一种分析方法叫Cohort Analysis，有人翻译为同期群分析，我把它称为切片分析，Cohort Analysis用于留存率分析特别方便。

举个例子，一家公司在App Store新推出了一款游戏。他们主要分析每天的新增用户是多少，这些新增用户中第二天、第三天及一周内持续登录的比例是多少。这就是最简单的切片分析。

切片分析主要用来跟踪和评估每一个版本的改进效果。比如说1.0版本，七天之后新用户的留存率可能是20%，我改动之后推出了1.1版本，发布七天之后新用户留存率可能提高到25%了，它主要是进行这种对比分析。所以，每一天都是切片，切当天新注册的这些人在未来七天、两周或者一个月的留存率。

切片分析主要用来对比产品不同版本之间的优劣，看一看新版本的留存率是否更高，来评估产品体验是否有了改进。但注意，必须得是新用户，因为老用户的留存率比例本来就高，不能把两者混在一起。特别是有很多App可能是不需要注册的，必须用一些技术手段把新老用户区分出来。

还有A/B测试，如图5-2所示。一个产品设计可能有两套方案，究竟A好还是B好，谁也说不清楚，怎么办？可以把50%的用户导到A方案，把另外50%的用户导到B方案，最终根据数据决定到底选哪个方案。

比如一个App，底栏是放三个按钮还是两个按钮，宣传素材应该放美女的照片还是应该放帅哥的照片。再比如，在一个产品的用户注册流程中，可以尝试两个方案，因为不确定哪个转化率高，通常的做法就是做个A/B测试，用两套方案来对比一下。

按理说这事应该很重要，但采用的公司却很少，这是为什么呢？

因为两个方案，选A还是选B，产生的效果是相对隐性的，而且是非常长期的。你把按钮放左边还是放右边，老板往往不会提明确的要求，你也很难说明白两者到底有多大的区别，所以也就懒得做这个事，而且所有的A/B测试都是有成本的，不是写两行代码就行，你需要做用户分流，还得有两套设计方案、两套研发系统，一个都不能少。

但同样有成本，为什么A/B测试在广告上就用得很多呢？原因很简单。因为广告涉及钱，而钱是显性成本。如果你是负责人，你肯定也希望在小范围测试一下。所以大家通常会设计几套方案，比如先花20万元选几家平台，分别投放不同的文案试一试。然后根据这些数据反馈，看哪个效果好，最后再决定进行推广时用哪个文案，或者最终选定哪个平台做大力投放。

虽然从长期来看，把用户的注册流程优化好，一定是个细水长流的好事。如果你的注册率每天都能够提高1%～2%，长期来讲价值就会巨大，而且还不花一分钱。

但在注册流程中，你带来的用户后续注册的成功率怎样，未来他的活跃度怎么样，因为并没有一个统一的标准，老板也没法比较，所以这块就变成隐性成本了。

另外还有灰度测试。灰度测试其实很简单，主要用于成熟产品，通常有一定用户规模后才需要用这种方式。一个成熟产品增加了一个新功能，但不确定这个新功能对大多数人是否有价值，特别是涉及商业化的部分。那该怎么验证呢？

最简单的方法就是筛选少量用户，给他们升级到新版本，其他的用户还用老版本。比如深圳地区的用户都用新版本，其他省市的用户还用老版本。

就像微信，每发布一个新版本，总是会有一些人先用到，大部分人后用到，为什么要让一部分人先尝鲜呢？有两个目的，第一个，要确认这个功能是不是大家喜欢的，因此先放给一些用户去体验。还有一个比较重要的目的，需要确认这个版本没有特别重大的bug。总之，对于重要的产品，一定都会用灰度测试。

因此，就需要提前部署两套环境，根据你预设的规则，把不同的用户导向不同的版本。通过小范围的验证，确保新功能广受好评后，再进行全面的更新。

说到这里，我给大家讲一讲小米是怎么通过灰度测试快速迭代产品的。大家知道小米早年大概有500～1000人的工程师团队在做MIUI。每1～2个月都会有一个全版本升级，这个肯定是稳定版，而且是半强制的，也就是不断通过弹窗提示更新，总有一天用户会升级。

你可能会说，每1～2月推出一次版本更新，挑战并不大，很多公司都能做到。但小米真正厉害之处在于，他有一个每周更新的版本。大家注意，参与每周更新的也是百万量级以上的用户。

既然到了百万量级以上，就得同样要求是相对稳定的版本，因为百万级的人群数量不算小了。

为此，小米还搞了个“爆米花奖”。因为每周的版本更新都会推出三四个新功能，小米会做用户调研，让用户选出其中最喜欢的一个功能，给负责开发这个功能的组员每人发一桶爆米花作为奖励，相当于一个荣誉。通过每周更新，一些重要的功能，最多用一周时间就能收到用户反馈，这种迭代速度是很快的。

但这仍然不是最厉害的，小米还有个每日更新。当然，每日更新不要求是稳定版本，更多的是程序员突然想到了一个点子，想尝试一下，只要做得足够快，第二天就能看到用户反馈。

这个每日更新是非常厉害的，因为不要求是稳定版本，所以对于参加每日更新的用户限制也很严格，必须是在MIUI论坛里面活跃度非常高的用户，才有资格申请。当然，也包括开发者，小米内部的员工，以及跟小米合作的一些其他公司的员工，总共一万名核心测试用户，也可以称为忠实粉丝。

普通的互联网公司能做到每两周更新一个版本就不错了，而小米却做到了每日更新，你想想这个差别得有多大。随时想到一个点子，马上就可以更新版本去验证，第二天就能拿到用户的直接反馈，这其实是很不容易的。这也堪称是小米高速发展的巨大助推器。

当然，灰度测试是需要花时间的，会把产品发布的时间周期拉长。有时候，业务部门“立功心切”，会选择跳过灰度测试，这就会带来很多问题和隐患，不少大公司都曾经在这上面栽过跟头。

大家知道，手机QQ和微信有一个很大的区别，那就是对于微信来讲，默认所有用户都是在线的；对手机QQ来讲，用户头像图标亮着代表在线，不亮代表不在线。手机QQ曾经有一个版本，想学微信，把这两个状态给模糊了，不再区分上线还是不上线，所有用户的头像都是亮的。这个版本刚开始发布，用户就感到非常不爽，后台遭到各种投诉。这其实算一次产品事故了，如果灰度测试做得充分，是不应该出现这个问题的。

这些年支付宝一直没有停止在社交方面的努力。但也正是因为没充分进行灰度测试，在2016年时他们也搞砸过一次，甚至引发了众多网友的愤怒。当时支付宝推出了“校园日记”“生活在海外”“白领日记”等社交功能，“只允许女性发帖”“芝麻信用分达到750分以上才能评论”等引发了广泛热议，前期确实吸引了网友的关注，不过后来随着“圈子”内容的失控，流向低俗，最后招来的是一片骂声。蚂蚁金服董事长彭蕾都亲自出来道歉，一夜之间下架了该功能。这也是灰度测试不充分导致的问题。

许多玩过游戏的朋友都知道，游戏厂商通常会设一个体验服。体验服总是比正式服早一个版本，其实这正是在做灰度测试。

以上谈了不同的数据收集方式。必须承认，不论是A/B测试还是灰度测试，精益商业对团队的开发能力是有一定要求的，比如快速迭代新版本，对团队也是巨大的压力和挑战。

还有一点，公司内部一定要有数据反馈系统。如果没有数据反馈系统，就无法形成有效学习的闭环。有一些大家比较常用的数据反馈像友盟等，能够解决一些通用的指标。但有些比较特殊的数据指标，必须要在代码加一些日志，这也是蛮重要的。我看过一些研发文档，专门讲一款游戏应该怎样在游戏中加日志，玩转各种数据，非常有意思。