作者：李威，「糗事百科」产品总监 & 算法工程师，负责糗事百科数据增长及推荐系统 来源：GrowingIO 增长公开课第 31 期分享内容
大家好，我是糗事百科的李威。今天主要和大家分享一下，糗事百科是怎么从无到有开始做数据驱动的，希望能给大家一些思考。
糗事百科是一个始于 2005 年的产品，是国内首个专注于搞笑内容的社区。最早是以文字内容为主，用户在站内发表一些搞笑内容供大家娱乐。这也与当年的互联网环境相关，在web 1.0 时代，大家主要是在 PC 上、在网站上浏览内容。
随着网络环境的不断变迁，从 2G、3G，再到 4G。这个产品的主战场也逐渐从 PC 端转移到了移动端。内容形式也越来越丰富，从单纯的文字内容，逐步出现图片、GIF 动图，到现在以视频内容为主。这款产品基本见证了中国互联网的整个发展历程。
1.糗事百科的增长哲学
作为一款生命周期非常长的产品，我们也很早就开始回归商业本源。简单说，就是这款产品要能够“挣到钱”。
1.1 用户增长公式
怎样才算挣钱呢？
需要满足：平均每个用户创造的价值 ≥ 获取一个用户的成本。这个「成本」不仅包含推广拉新的成本，也包括团队、服务器、带宽等运营成本，最终平摊到每个用户头上。
对以上不等式左右两边进行进一步计算分析，获取一个用户的成本等于总花销除以总的拉新人数。单个用户创造的商业价值等于单个用户每日收入乘以用户平均生命周期活跃天数，下面对单个用户每日创造的价值进行拆解和计算。
用户生命周期活跃天数（ TAD ）如何计算？
实际上，就是把用户从第一天开始每天的留存率进行加和；简单说就是留存曲线下的面积，有一点积分的概念。
这个是一条甚至是无限延伸的曲线，那怎么求和？通常，我们选取的一个终止条件就是留存率降到 5% 以下就停止累加。从这里可以看出，用户平均生命周期是和留存率强正相关的数据。
经过一系列运算我们可以得出：
- 要提升每天用户创造的价值，就是要提升用户每日的使用时长。
- 要提升用户生命周期活跃天数，就是要提升留存（黏性）。
虽然结论简单，但这里只是给大家一个示例。在数据驱动时代，你面对着大量的数据，只有数学工具才是搞定数据的利器，请大家习惯用数学的方式分析问题。
1.2 找准产品定位
刚才上面的分析说到「广告展示量」是和「使用时长」（内容浏览量）正相关的。对于我们这类内容型产品。内容浏览量就是用户看多少个帖子、多少个视频。大致的，使用时长等于平均内容时长乘以内容浏览量。
抖音和 Youtube 这两个行业翘楚，他们在内容时长的选择上截然不同，最终会造就完全不同的产品形态和商业模式。
抖音的视频短、浏览量大，所以它可以选择每隔几个视频插入一条广告这样的信息流广告形式。Youtube 视频长、浏览量少，所以主要选择贴片广告形式，即先播放广告再播放视频。
这就是内容选择的差异最终导致商业模式的不同。数据驱动开始前，我们需要给自己的产品找准一个清晰的定位和发展方向，以免后续所谓的「数据驱动」驱动错了方向！
那么，如何找准产品定位呢？
来看下面这个坐标象限图：我们把内容的时间长短作为横轴，产品是偏社区还是偏阅读作为纵轴；我们把市面上的各类内容型产品放置其中，圆圈的大小代表产品体量。
可以看到：
- 左上角是偏社区的短内容，比如抖音、快手；
- 左下角是偏阅读的短内容，比如今日头条、西瓜视频；
- 右下角是偏长内容的阅读，比如腾讯视频、爱奇艺视频；
- 右上角是偏长视频的社区，这种就比较少，因为长视频天然不利于社区；但自从有了弹幕，长视频也多少可以有点社区的感觉，比如 B 站。
糗事百科位于上面的红色圆圈，是个强社区型的产品；自从视频开始成为主流之后，大概内容的长度是在 0~5 分钟范围。
糗事百科会始终定位于一个强社区型产品，但是在内容时长方面，我们需要根据具体的商业模式、整个内容生态以及市场环境进行调整。要学会利用象限图找准自己所处的位置，以及发展方向。
象限的横纵坐标可以依据情况选取：比如这里就可以改成视频的创作者更偏草根，还是专业制作；或者是专注于某个垂直领域，还是包罗万象。
2.数据驱动的基石-数据信心
找准产品定位、理清用户增长公式后，我们如何用数据来驱动产品增长？
2.1 常见数据问题
在进行数据驱动的过程中，大家是否碰到过下面类似的数据问题：
基本上，如果大家都对手头的数据抱有怀疑的心态，那数据驱动就无从谈起了。凡事都从怀疑数据开始的话，也大大降低了工作效率。所以，数据驱动的重中之重就是先把数据搞对了，把数据治理做好！
这里需要强调的是：数据正确不代表大家对数据有信心！希望大家理解这句话。信心这个东西培养起来很慢，摧毁起来那可是迅速。你的数据都对了，不代表大家信任。如果你的团队建立了对数据的信心和信任，我敢夸张的说：拿到想要的数据+数据正确+数据信心= 60% 的数据驱动。
2.2 常见出错原因
我们来理一下数据容易出错的原因：
- 对于传统的产品经理而言，数据往往被称为统计需求，没有功能重要，因此会被放到需求模板的最后面。实际需求开发的时候，如果时间不够用，往往首先牺牲的就是统计需求。
- 对于开发者而言，他们往往非常在意需求的技术含量，希望以此提升自己的能力。而数据埋点上报之类的都是极为繁琐而又缺乏技术含量的工作，不受开发者待见。
- 对于数据需求的测试而言，数据看不见摸不着，逻辑不清晰。如果没有好的工具，这对测试者的要求很高。
更重要的是，一旦放松警惕，数据在后续的开发中极易被改错，而测试者完全无法察觉。上述这些困难，会直接导致我们逐步陷入数据恶化的深渊。
3.如何建立数据信心
那么如何建立数据信心呢？
首先，你数据别总错是吧，错的多了谈何信任，这一点我们后面来说。如果有一些细节出错不可避免，那一定要找到问题解释清楚。
我和数据产品经理一再强调，一旦别人发现某个数据有问题，你查清楚问题之后一定要跟人家解释清楚。这个数据为什么错？错在哪里？能不能修复？能修复的话什么时候能好？不能修复的话要怎么办，有什么替代方案？
绝对不能说：哦，这个数据的确有问题，我们来修，后面就没有下文了，或者只是简单告知人家这个数已经修好了。要让别人非常清晰的认识到，即使数据有错，情况也完全是在我们掌控之中，态度决定信任！
下面我会从三个视角，技术+团队+业务，给大家介绍分享一下如何解决数据信心问题。
3.1 技术视角
关于数据采集，GrowingIO 提供了「埋点+无埋点」的双模式数据采集方案，能够极大地简化我们的数据采集工作量。这里插入讨论一个问题，关于埋点和无埋点；埋点和无埋点各自有自己的优缺点，我们在使用的时候需要特别注意。
对于核心数据最好一定要埋点，好处在于你可以清晰的知道你采集的到底是什么数据，开发的埋点代码也明确的出现在相关功能所处的代码段中，误操作的概率相对较低。当然埋点的缺点就在于要事先规划并开发，比较耗时耗力、无法快速看到结果、也无法回溯。
无埋点主要用于探索性的分析、数据的补充、数据相互印证、特定问题排查等场景。无埋点的数据一旦认定很有价值，最好就转为埋点数据，并增加更多的事件变量以便后续分析可以拆解更多的维度。
3.2 团队视角
我们再从团队的角度来看一下数据驱动这个问题。
互联网行业团队经常会有这么几个角色：产品，运营，开发，设计，测试，商务。实际上这些角色中很难有一个角色对数据完全负责。
举个例子，对于糗事百科而言，「用户观看视频时长」是一个重要的指标，所以我们需要埋点采集这个数据。开发完成开发，产品经理体验合格，依照用例完成测试，所有的流程都保障了这个数据 99.9% 都是正确的。但数据全量上线之后，我们发现了一个奇怪的问题。
这是一个用户观看单个视频平均时长的数据，之所以有这么多条曲线，是因为我把全量用户随机地平均分成了 16 组，这是 A/B 测试中经常用到的操作。可以发现总会有一些组突然比其它组高出一截。经过细致排查，我们发现采集的用户观看视频时长数据里面，有大概万分之一的错误数据。
通常这么少的脏数据不会对统计分析造成太大影响，但是这次情况有所不同。我们的用户观看一个视频的时长通常不会超过几百秒，而这些错误的数据每个都是几万、十万，甚至几十万秒。虽然数量极少，却能影响最终的平均数，对我们的数据分析产生严重干扰。右图是我们最终修复这个问题之后，用户观看单个视频平均时长的数据，这样看就正常多了，每个组的表现基本都是一致的了。
为了达成数据驱动这个目标，我们需要有一个能掌控数据并为之负责的团队。从最小可用的角度出发，我建议可以从增加一个数据产品经理开始，而不是一开始就搭建一整套数据团队。尤其不建议这个数据团队游离于产品研发团队以外，变成类似于运维这样的一个支撑团队。
这个角色需要完成以下工作：
- 数据规划（找到并拆解北极星指标）
- 数据实施（圈选或埋点）
- 数据维护（尽快发现、解决问题）
另外，在研发流程中也要相应加入数据相关的节点。比如数据需求测试时是否要加入大量数据上报之后的宏观数值测试，等等。
同时，这个角色需要对团队其他成员输出数据，对不善于利用数据的成员进行培训和监督。培训，指的是帮助成员筛选、解读想要的数据，成员碰到数据问题也可以来主动咨询。监督，是指促使产品或运营完善需求，需求需要强调需求目的，保障需求文档包含验证需求目标的实验环节。
3.3 业务视角
我们一直在思考：关于数据增长和数据分析，是否有一些行之有效的方法论，能让一个小白迅速成长为数据分析能手？
我的理解是：方法论的确可以总结归纳，但真正操作起来跟经验，跟对产品的理解有很大关系。甚至很多时候你所处的岗位无法做到对产品拥有全局掌控，你并不清楚每天发生在这个产品上的每件事情，都会严重干扰你对数据的分析。
有一次，我们在 GrowingIO 上的内容分享数据和后端统计平台上的数据有差异。原因是两者在统计逻辑上有差异，后端的统计逻辑是包含「图片分享」的，而 GrowingIO 上的统计只含「帖子分享」。虽然我们的数据产品经理具备了完整的数据分析方法论，但由于刚入职，不清楚分享实际包含「帖子分享」和「图片分享」，始终没把思路往正确的方向想，花费了大量的时间去分析这一问题。
所以可能数据分析方法论可以有，但是很多时候你会发现问题、解决问题的根本还在于你对的行业经验以及对产品本身深刻的理解。
4.基于 A/B 测试的数据驱动
不做 A/B 测试的时候，通常我们会通过数据前后对比来验证效果，那这样到底科不科学呢？
4.1 A/B 测试是科学的验证方法
举个极端的例子，下面这张图是我们没有做 A/B 测试，试图通过上线前后的数据对比，验证某一个功能是否会对数据产生积极影响。
上线之后几天内，前后数据没有出现明显变化，还无法验证到底效果如何，并且突然出现了一次数据故障，导致数据下滑，基本不再可能判断功能上线之后的效果。
那到底怎样的数据验证才是正确的验证方法呢？答案是采用 A/B 测试。
我们再来看另外一个极端的例子，用了 A/B 测试之后，即使数据出现故障，仍然可以看到 B 组的效果是要比 A 组好的。当然也需要强调，并不是所有的场景都适用 A/B 测试，比如涉及到产品核心理念和规则的东西。
在交流过程中，我发现很多同学虽然很认同 A/B 测试，但真正运用的并不多。大家都反馈做 A/B 测试太耗时耗力。这里就要纠正一个大家的认知误区：不要把做 A/B 测试当成需求之外的工作。
记住这句最重要的话：实验即需求本身。
怎么理解这句话呢？
需求在提出的时候就应当是一个实验方案，包含：需求目标，需求细节，目标的验证。需求上线，其实就是通过 A/B 测试控制流量的实验实施。很多团队版本上线会采用灰度发布的策略，主要目的是为了验证新版本，及时发现 Bug，避免 Bug 影响到更多的用户。那其实本质上已经是一种 A/B 测试的萌芽阶段了。
一旦你把需求当成实验来做，即使产品效果不好，那也只是说我们验证了一种假设，它不成立，从心理上就会好很多。相应的，由于是流量控制，开发和测试上线版本时的心理压力也会小很多，可以先小流量放开，一旦出现问题，还可以回滚。
4.2 如何设计 A/B 测试
本质上就是做两件事情：一是控制流量，二是对不同的实验组采集数据、分析数据。如果你用 GrowingIO，那「采集数据」、「分析数据」、「数据可视化」都是很容易实现的。
你需要做的就是在 GrowingIO 上面创建一个访问用户变量，可以叫做「 A/B 测试分组」。根据一些规则给每个用户设定一个分组，在后端控制流量的时候采用同样的规则进行流量切分即可。
例如：你根据用户 ID 的尾号进行分组，那么 ID 为 123 的这个用户它的 A/B 测试分组这个访问用户变量的值就是 3。那后端在控制流量的时候，如果选择 ID 尾号为 3 的用户进入实验，那么刚才那个 ID 为 123 的用户就被分进了实验组。你在 GrowingIO 上面观察数据的时候，就可以通过 A/B 测试分组这个访问用户变量进行维度拆分和可视化分析。
进行 A/B 测试的时候，需要注意这些问题：
- 控制好变量，保证实验组和对照组除了需要测试的变量以外尽可能一样。
- A/B 测试的效果衡量可能并不是单一指标的。通过多个指标衡量效果的话，各个指标的权重的分配需要根据产品的定位来决定。
- A/B 测试的周期时长有限，这注定了得出的结论是短视的、更注重眼前利益的。
4.3 A/B 测试的统计显著性
我特别想强调的是「统计显著性」的问题。可以简单理解为，你所做的实验是用一小部分用户的行为模拟总体用户。
如果在这一小部分人身上得出结论，说效果增长 10%，那是否真的意味着，在总体上就会上涨 10%？不一定，总会有一些波动，那波动的范围是多大呢？这就是「置信区间」的概念。
总体而言，参与实验的样本量越大，波动越小，得出的结论越可信。
而实际中，我们往往希望用最少量的用户得出是好是坏的结论，甚至在某些场景中我们没有条件增加实验的用户量。这种情况下，统计显著性的问题就显的更为重要。
为了提升实验效率，一些新的 A/B 测试方法也被提出来，比如 Netflix 的 Interleaving，就非常适用于我们信息流内容的场景，这里就不做深入介绍了。
5.糗事百科 A/B 测试案例
一开始我们介绍到，对于糗事百科而言，提升用户价值的重要方式是提升用户每天的活跃度和留存率。下面我和大家分享一个糗事百科推荐系统 A/B 测试的案例，来看看如何用数据驱动产品增长。
这是通过 GrowingIO 进行的数据采集、可视化和分析。我们把访问用户分为 16 个组，通过「A/B 测试分组」这个访问用户变量字段来区分；通过给实验组和对照组分发不同的内容，观察用户 App 平均使用时长的变化。
0 组（蓝色）是实验组，0 组实验组上线后，用户 App 平均使用时长具有很大的提升；但是过了一段时间，数据在不断减弱。那么 ，0 组数据下降是特殊情况还是全局原因呢？我们紧接着上线了 12 组和 10 组，发现数据也是有上涨，但是过了一段时间也慢慢下降了。
如果这个时候你只掌握了数据分析的能力，那你可能很难继续进行下去，除非你对推荐系统的实现有一定了解。我们分析的结论是，可能是我们给用户推荐的内容各个品类内容量不足，用户喜欢的内容看完后就没有更多的该品类的内容了，导致吸引力、活跃度就逐步下降了。
所以，后面我们增加了推荐内容的各品类内容的条数，发现 0 组、10 组、12 组三个实验组的数据的确又上去了。由此验证了我们的猜想。虽然经过一段时间的消耗，发现数据又会有所下降；但是，总体上实验组的数据远远高于对照组。
最后，说一下我们最近一年以来数据驱动的成效吧。总体而言，经过一年多的试验、迭代和优化，糗事百科 App 人均使用时长大概有 2.5 倍的增长，这是数据驱动给我们带来的切实可见的增长。
以上就是我本次分享的主要内容，谢谢大家的参与！
若有收获，就点个赞吧
0 人点赞
