朱江毕业于上海交大计算机系，2009年加入触宝，经历了从技术到产品的转变。先后负责触宝云服务的研发，触宝电话生活黄页业务，现在负责触宝电话的产品管理及商业化工作，是触宝电话主要产品负责人。以下为演讲实录：
谢谢大家，我叫朱江，我今天给大家演讲的题目是《触宝的数据驱动产品实践》。非常抱歉，刚才主持人对我们的商业化转型比较感兴趣，但是我今天的转型没有涉及到。因为这次大会主题是数据驱动，作为一个工具类的产品，也有大量的用户，我们确实也在数据驱动这方面有很多想要跟大家分享和探讨的部分，这就是今天我的演讲主要内容。
我的演讲分四部分，第一部分介绍一下我自己，第二部分讲一下对于数据驱动的理解。第三部分讲一下实战案例，最后是我们的总结和反思。
我是上海交通大学计算机硕士，2008年的时候我在谷歌实习，实习很兴奋的时候就告诉我不招人了。然后工作就没有着落了，那个时候我在交大的BBS上发现一个帖子，有一家公司拿了全球创新大奖。我就抱着好奇的心理，投了一个简历过去，我就加入了触宝。那时只有一个创始人，没有一个员工，现在触宝已经完成了D轮融资，投资我们的有红山资本、IDG，触宝今年到了用户体量比较大的规模。我们的目标是两年左右的时间再上一个台阶。我有个外号叫触宝教主，我听到这个词的时候总想到一个人，就是照片上的人，就是东方不败，总感觉自己哪里少了点什么。
直到有一天我看了一篇文章，阿里的蚂蚁金服的老大讲，创业者一定要有一种特质，就是雌雄同体，后来我知道了，我就是触宝教主。接下来讲讲我对数据驱动的理解，我认为数据驱动产品迭代的关键，是建立一套强调实验和追求结果的文化。并且利用数据分析，直接和间接的对产品的核心指标去进行增长。核心指标包括我们比较关注的用户规模、留存，像触宝的拨打电话的数量。旁边这张图是推特当年引入了所谓的增长团队之后，加大了迭代速度，它们的用户增长规模的斜率发生了明显的增加。我认为数据驱动的关键因素是这么几个，第一个是要有高效的工具。因为我们要完成实验，要完成迭代，可能不能完全靠人力，需要有一套方法论，有一套成熟的工具支撑你。所以这套高效的工具是重要的因素之一。另外有高效的流程让各个环节迭代起来，比如一到两个周期，比如这个团队里面每个人都有明确的目标，每个人都有自己可以去利用的资源。利用就是要能够提出假设，去把它切割成一个相对比较可行，又比较小的集合去做试错。在试错之后，要能把方案进行总结提炼。然后进行发布，要减少对用户的影响，最后形成一个循环。
我讲讲触宝曾经用过的数据分析工具，我相信很多人也都用过。首先传统的方式是用数据库和日志的方式来分析。数据库的分析和日志的分析，很多人做过技术有一定的了解。这种分析方法在团队小的时候，或者用户规模小的时候很实用，数据库都在服务器上面，随时可以拉数据。日志一般也是在服务器上本来就有的，就顺带利用它做分析。这种方法的问题是效率很低，一旦有需求要跑到数据库去查。因为数据库的设计是为用户分析的，不是为分析服务的。另外数据随时都有可能丢，比如宕机了，就查不了。我们用过SDK，它是一个完整的解决方案，可以提供从分析到报表，有一整套的分析。但是用户体量比较大的时候，对隐私会非常关注。如果这个数据被泄露到第三方平台上，对于企业或者用户，都是有风险的。
另外就是这种数据分析平台通常只能解决一部分的数据分析纬度，举个例子百度的统计。我在网页上可以拿到它的数据，但是服务器还有下单、订单的数据，客户端还有用户行为的数据，这些东西没有办法打通。我用这个工具只有解决一部分问题，当我想连在一起看的时候就发现不行了。所以后来我们也开始搭建自己数据分析的体系，最早用的就是hadoop，这是一个山寨版的谷歌大数据处理平台。那时候我们的数据就TB级别的数据，每次分析需要由开发来配合写一个脚本，然后就上平台跑这个脚本，大概一两个小时可以出结果。因为公司有很多产品经理有这个需求，所以大家需要排队去跑。我们也有一个数据报表的体系，就是rainbow，就是把一些常态化的数据呈现为报表，把一些关键的数据点做监控。这样的方法持续了很长时间，到了去年，我们对现在这套方案又做了升级。也是响应之前的图，如果我们想要把整个迭代的流程加快，数据驱动速度加快，就要有更高效的工具。一个小时或者小时级别的分析，已经不能满足我们的需求了。
同时产品和开发配合的方式，也有这样那样的弊端。所以我们在原来的基础上做了一次升级，引入了一套开源的方案，druid、dril、superset，这是一套在线的实时分析。drill搭建了类似于数据库查询的脚本。superset做可视化的展示，我们现在的数据规模是TB级别的。数据查询效率非常高，基本是秒级别的。对于大部分产品的查询，没有那么复杂，哪怕数据量是千万级别或者亿级别，要查很多用户的数据，依然可以在秒或者十几秒的时间里面，就把结果出来了。这样有一个好处，一旦发现我原来假设的数据不对的时候，我不需要再用复杂的方法去提交需求，然后做分析。同时因为引入了这套系统之后，它的查询方式实际上可以变得比较轻量级。所以在整个公司普及，让产品经理自己学习语句，去查询自己有权限的数据。用这样的方式去做，每个产品经理都可以找到每一个用户在触宝平台的数据，而且他可以做非常多的分析。引入这套系统，我认为我们数据驱动的整套体系速度提升很多。
这是一个简单的截图，上面就是举个例子。上面是一个命令行，实际它有一个网页，可以打一个语句。比如我要查昨天在上海激活的，并且还打过我们的免费电话等等，就可以把这些通过一个语句查出来，下面可以出结果，可以是亿级别的，它跑的很快。下面是一个rocord的数据，里面可以把报表接到数据仓库里面，用自定义的方式展现出来。这样可以做出满足自己产品需要的业务报表。
另外我们在数据分析这块，引用了一些算法或者引用了一些方法。首先第一个比较常用的就是经营创业的概念就是同期群分析。就是我想找出两类差不多一样的人，但是让他们去体验产品里面有一定差异的功能，这样的情况就可可以知道到底是功能的问题还是其他问题。所以同期群是一个常用的方法，比如我一个功能升级的时候，我就用一个用户画像的方式把人抓出来，让他们体验有一定差异的功能，我最后就能看到一个结果。另外我们也建立了流失模型，流失模型指的是我们把现在存量用户行为数据和他的流失数据做了一个建模，也就是说可能这个人他装了触宝电话，他没有打交道。他可能搜了一个联系人没搜出来，他可能就流失掉了。我们可以通过海量的行为数据，用函数建模。可以理解成以后来一个用户，我就知道他的流失概率有多大。当我知道他的流失概率大的话，我就可以做一些有针对性的运营，比如赠送一些触宝分钟数或者额外的一些激励。
另外也会做相关性的分析，主要指的是想了解这个产品的功能和我们核心数据之间的关系，相关性有多大。举个例子在触宝电话里面换过皮肤的用户他的留存率，他对留存的帮助到底是正相关还是负相关。是换过皮肤的人更愿意留下来，还是没换过的更愿意留下来。我们通过这样的行为，它对于核心指标是有帮助还是有害的，有利于我们做产品的改进。
接下来我讲一个实战案例，在触宝里面真实发生的。去年8月份增长团队做了一个小型的战役叫做八月会战。目标就是大幅提升触宝电话的留存率，那个阶段触宝电话出现了稍微下降，增长团队当时接到了任务，怎么能够在一个月的时间把留存率提升，目前是把新用户的七日留存率的绝对值提升8%。举个例子七日留存率是50%，就要提升到58%。如果大家做过产品肯定是了解的，就是要把七日留存率在一个月的时间里面提升百分之8个点，几乎是不可能的。这个战役持续了四周，这次战役一共发布了6个灰度版本，1个正式版本，直到找到产品稳定了，这是概括的数据。那么我们做了什么呢？
第一周，我们是这么想的，我们要降低流失率，流失的人少了，留的人就多了。我先要分析流失的人的原因。下面是一个开启电费电话，下面需要填手机号、验证码，再一点就进入到主界面。注入了主界面，大部分用户都会选择打个免费电话，就这么四步。第一步打开应用，就是右边的应用，假设是百分之百。第二步开启免费电话，只有69%的人。第三步是填好吗有55%，一直到最后。这就是数据，问题最大的是第一步，只有69%的人点了开启免费电话，那31%的人走了，所以就要想办法把这些人留下。产品的灰度方案是这样的，我们做了四套方案。第一套方案做了基准，就是右边原来的界面。后面的三套方案是这样的，大家看得不太清楚。
这三个共同特点就是换了一张图，告诉你触宝可以免费打电话外，还可以免费领流量，换了一个更强的刺激。这三个的区别在于说，下面开启免费电话还有一个功能叫赞助开启。不打免费电话，你也可以进来。第二个变化就是少了赞助开启。第三个就是把按钮调下来，你注册就送你分钟数，就是激励。就是这三套方案，加上原来的方案，我们做了灰度对比。就是到底转化率能不能提升，大家觉得哪个方案效果最好？结果是四个方案转化率几乎一样，还是没变化，然后就分析数据。有一部分人是换手机了，他注册了以后，就变成了我们的老用户了。因为数据分析好多细节，就是一开始进到第一个界面，大家都认为是新用户，而你登录以后就变成了老用户，所以人就变多了。所以发现第一步的转化率是很高的，实际上100个人里面有90几个人都点了。
接下来想改进的方案是用一个强运营的方案，就是今天用触宝打电话，你明天再用送你流量，后天再用还送你，你就别走了，就用了强运营的方式。就是用户打开触宝电话就给他一个大红包，就是天天有红包，这个红包就放到界面的右下角，大家觉得这个方案怎么样？结果是留存基本没提升，非常出乎我们的意料。为什么给用户好处，他没有留下来的意思呢？后来事后经过很长时间去分析，我们发现用户来到触宝他最急切的事情是打免费电话，因为这是我们的核心功能。你去引导做别的事情的话，不是一个合适的时机。也许他对其他事情有兴趣，但是阻碍了他体验核心功能，这不是一个明智的选择。
所以到了最后一周，必须要完成这个目标，最后走投无路做了这么一个改版。就是登录完了以后，第一步是设权限，允许让我启动、允许让我读通话记录、联系人，设完之后给你一个新手指南，恭喜你注册成功了，可以去打免费电话。就做了这么一件事情，这件事情对比的方案是这样的。原来也是注册完，先弹一个红包告诉你，你得了一个300分钟的通话时长，要来学一下怎么拨打免费电话。你点一下，就告诉你拨打之前要设一下权限，设了权限之后进入第三个界面。这个界面没有通话记录的，过一会儿可能会刷取。第四个界面就弹出一个小熊猫，你抢到一个小钱包，可以看看有什么东西。这是之前的方案，这个方案现在换成了这个。这件事情实际结果完成了8%的目标，原因是非常曲折的，我给大家解释一下。
我们做了留存率的分析，我把关键数据隐掉了。触宝的留存率有一种阶梯性的下降趋势，它会下降一段时间再平缓，再下降再平缓，是这样的趋势。我们分析数据下降的原因是什么，因为原因有很多，各种各样的因素。用户的因素、渠道推广的因素、服务器的质量因素，包括版本因素等等，都有关系。我们就分析下降的阶梯性，他持续一段时间突然下降，觉得可能是跟发版有关系。但是发现每个版本的发布留存率变化不大。然后我们找到某个版本发布留存率突然就跳水，我们看这个版本跟之前的两个版本有什么区别。区别在于原来那个版本，留存率高的版本就是图的这个东西，低的版本就是这个东西。
原来的方案是好的，后来我们改的方案变坏了。当时也是纠结了很久，我们后来发现原因可能很多，我们分析可能是因为这个流程里面，在第二步权限引导，把它拆开了。先引导一个最重要的权限是打电话的权限。打电话权限开启的话，就直接进入下一步。而原先的是三步，另外三个被后置，后置就导致用户找不到了。而这两个权限会影响到打电话的质量，我们猜测是这个原因。然后就把曾经的好的版本抓出来，投到市场上去看一下留存会不会再涨上来。发现投放了之后数据真的涨上来了，所以我们做的事情就是把曾经改坏的东西改回去了，最后的结果就是留存率上升了7个百分点，这个案例还是挺耐人寻味的。
我们也做了事后的总结和反思，也跟大家分享一下。首先数据分析一把双刃剑，一旦分析错了影响决策，这怎么破呢？我刚刚举的例子，第一周分析错了，这一周就白干了，归零了。那怎么办呢？首先要从多个纬度去分析。实际上你的用户量大了，一定会在这个领域里面会有各种各样的问题。哪怕你用枪去指着数据开发师说这个点不能错，他依然会犯错误，所以这要从多个角度去分析数据，要从多个角度去佐证。第二个你做数据分析通常有目的性的，我认为一个好的产品经理要多做有目的的观察。就是你只看它的结果是什么，你不带着任何目的，不带着任何的假设，只是观察它们两个是关系是什么。当你就这样的观察之后，可能就会有一种量化的概念。也就是新用户点击注册，进到填手机号里面，他是不是70%？这个事情对于有经验、有过去数据观察的人会直接告诉你，这个数据肯定是不对的。最后总结下来，是要多建立总结的关系。
上面一个人叫大卫·休谟，他说：“我们无从得知因果之间的关系，只能得到某些事物总是会联结在一起，而这些事物在过去的经验里又是从不曾分开过的。”就好像苹果，苹果从树枝上断开和它落到地上，在过去都是永远在一起发生的。换句话说，明天你遇到一个苹果从树上掉下来，它不能被证明一定会落在地上，它有可能会飞到天上去。说这个例子的意思，我们往往会从数据分析里面形成一些自己的假设，因为是这个原因，所以是这个结果。其实你要知道每建立一个因果关系，就已经走到了一条岔路了。当你知道相关的关系越来越多的话，就会形成一种感觉，这种感觉会告诉你可能是存在的。
第二个是发现数据异常的时候，如何找到原因？你今天看到这个数据，要反问这个问题，通常是很难找到原因的。我们能找到这个原因，它是一个综合性的结果。运气不好的话，通常是发现不了原因的。因为数据的因素太多了，最后反过来推变量太大了，可能就是那天天气不好。所以反推是很难的，但是怎么样能尽量去发现原因呢？第一个就是多维度地去分析，第二个就是要形成直觉。直觉的形成就是多观测去形成一种感觉，这种感觉听起来很玄，但是其实是存在的。
第二个，是不是每个产品改动都要做AB测试呢？我个人感觉AB测试一定要做，但是它的效率很低。为什么很低呢？因为你会冒出很多的假设，你会让开发不停地做AB测试码？开发可能会“杀”了你。所以不能每个都做，但是一定要坚持做。就像你玩游戏屏幕是黑的，你突然把一个屏幕点亮了，你看到一个局部，你就知道了一点点信息。你再从别的局部再点亮一点点信息，你从局部知道多了以后，就会由点形成面，这就是AB测试的作用。所以我自己的总结就是做数据分析的目的是什么呢？它的质量目的是从数据中直接发现问题，指导产品的改进。就像刚才说的我发现留存下降，去分析数据，找到原因，问题解决了。
它的主要目的还是从数据中培养直觉，培养叫接近产品上帝的直觉。产品上帝是什么呢？我自己认为所有的产品假设，都有那么一个人，他可能不是一个人，他可能是个神。他知道这个假设的答案，他知道所有假设的答案，他不会出错，我就把他定义为产品的上帝。你就要尽量接近这个产品上帝，想的东西要尽量是一样的。产品经理经常决策的困境是，首先大家知道假设有一种答案是最好的，我们知道有一个最好的答案。
因为大家都是人，人都是会犯错的，那凭什么你说的是对的，那说的也有可能是对的，那大家就做测试，可能就陷入一个循环。那怎么办呢？那就是听老板的，还有的公司听老板娘的，还有是听自己的。我产品经理比较牛，我就听我的，不听老板的。下一个就是AB测试，这个很常见，大家吵架没结果去测试，你们两个最初的方案，最后开发就倒霉了。所以一般来讲这种情况下，我们认为实际上可能最好的解法，还是想办法去听最接近上帝的人。但是这个人是谁呢？谁也不知道答案，所以你要把自己变成最接近产品上帝的人。那怎么形成接近产品上帝的人呢？第一个你自己要有天赋，我承认这个行当里面天赋是很重要的。也许有些人很努力，但是努力只能获得有限的回报。产品经理的天赋我个人认为很重要。
第二个要有大量的产品实践，大家看到张小龙讲产品经理他的理解，他讲到五条，其中有一条也是大量的产品实践。因为就算是一个再接近产品上帝的人，你依然不是上帝，要通过实验的方式去进行修正。我相信做到这样的结果之后，就会从一个开始有一定的天赋能够定性分析的人，你知道它好还是不好，到最后你会定量去分析一个人，你知道他是好多少。希望大家都能够成为接近产品上帝的人，谢谢。
最后给触宝打个广告，我们也在招产品运营，各位职位的同学们，欢迎大家联系我，谢谢。两位老总的演讲非常精彩，因为我一直也在跟数据打交道，大家在下面听的很认真。因为我们无数次的产品迭代中遇到了无数次这样的问题，尤其是大版本发布遇到小版本的迭代，这样的问题是常常出现的。没有人能够说谁是对的，到底产品迭代的时候，这个功能设计听谁的？听产品上帝的，还是听老板、老板娘，还是自己的，还是AB测试的呢？我司其实用的方法也是产品测试，在产品与运营撕逼的过程中，大家有没有发现？不管是听产品上帝还是听老板的，还是听老板娘的，还是听自己的，还是听AB测试，所有人都会说，这是用户说的，我们都在听用户的。没有人说会听我的，每个人听我的人，他说我们的用户他们想要这个。
所以这其实是产品，不管是玩产品还是玩运营，甚至是玩营销，这个里面都有一个万能的上帝叫——上帝。