糗事百科网络不可用(8小时糗事百科)

糗事百科是一家以分享搞笑段子和趣闻为主的网站，但最近一段时间网站出现了网络不可用的情况，无法正常访问。对于爱好者来说，这无疑是一个令人沮丧的消息。据推测，可能是由于服务器故障或网站运营方的维护更新等原因造成的。希望网站能尽快恢复正常，让用户们能够继续享受其中的乐趣。

本文主要围绕笔者构建推荐系统过程中的思考，以及碰到的一些数据问题，分析了我们需要注意以及掌握的事项与要点。

大家好，我是李威，来自糗事百科。

今天主要跟大家分享：在糗事百科我们构建推荐系统的事情。因为是增长大会数据专场，所以我不会介绍推荐系统算法细节，而是讲在构建推荐系统过程中我自己的一些思考，以及碰到的一些数据问题。

我在糗事百科主要负责数据、推荐系统，或者说跟数据打交道的一些工作。我本身是算法工程师出身，但由于接触的产品策略非常多，需要了解更多产品相关的知识，慢慢就变成了一个产品人。

简单来说，不懂算法的“开发”不是好“产品”。

糗事百科创始于 2005 年，是国内首个专注搞笑内容的社区。现在我们主要以视频内容为主，所以大家可以把我们理解成一个短视频社区。这个产品的时间线很长，所以涵盖的产品线也很广，包括 App、网页端、小程序、公众号以及微博、新媒体等。

我今天主要讲的是 App 本身，先给大家建立概念，这就是一个视频社区，一部分用户在发视频，一部分用户在看视频。以下是我今天的分享，enjoy！

1. 认识推荐系统

1.1 推荐系统的定义

我先简单介绍一下，推荐系统就是说，某个用户在应用内产生了足够多的用户行为，我们对这些数据进行分析，就能发现到他用户的一些偏好。

由于我们是内容社区，我们就会根据他的偏好，推荐一些他喜欢的视频内容。拿电商来举例，假设一个用户喜欢入耳式耳塞，而头戴式的耳塞也包含“耳塞”这个关键词，那电商就会推荐头戴式耳塞产品，这就是基于内容的推荐。

又比如说，一个用户喜欢电脑、喜欢摄影，另外一群用户有同样爱好，但他们不仅喜欢电脑和摄影，还喜欢游戏，那我们就猜测，这个用户可能也会喜欢游戏，所以我们就给他推荐一些游戏相关的产品或者内容，这就是推荐系统在做的事情。

1.2 推荐系统的价值

为什么要做推荐系统？其实是基于这样的一个假设：如果我们给用户推荐了他喜欢的内容，那么他可能就会在我们的平台上看更多的内容，看了更多的内容会怎样呢？

下图显示的是用户在我们平台上每天看的帖子数，以及跟他的留存相关的一些数据。

可以看最底下这条红线，如果他一周只看 200 个以内帖子，那他次日留存以及之后的留存其实是相对较差的；但如果他一周看 2000 个以上帖子，最上面这条紫线，你会发现他的留存会极高，从坐标轴也可以看出来，已经是 90% 以上的留存状况了。我们给用户推荐了他喜欢的内容，他可能就会在我们平台看更多，就会导致他的留存愈加提升，其实这是一个 Product Market Fit（产品-市场匹配） 的过程。我们提供的内容满足了用户的需求和喜好，那我们的产品就给他提供了足够的价值，做到了 Product Market Fit，这就是做推荐系统的原因所在。我看过一句话：

“一个推荐系统来到这个世界上，它只有一个使命，就是要在用户和物品之间建立连接，数据的挖掘和分析就是为了更好地识物断人，从而更高效的完成用户与物品之间的对接”。

这句话让我想起 GrowingIO 的创始人 Simon 说什么是增长，“Growth is connecting the existing core value of a product with more people”，这两句话讲的基本上是同一件事情。

连接（connecting）什么呢？

Existing core value，也就是一个产品提供的价值。对于我们的产品来说，就是短视频的内容，对于电商产品来说，就是你要购买的商品，这就是产品的核心价值。

总之，当我看到下面这句话时，我突然联想到，推荐系统所做的，就是增长定义的最核心的事情，所以它是不是可以泛化成一个增长的 *** 论呢？

2. 推荐系统与精细化运营的关系

增长策略的发展阶段是这样的：

最开始，我们没有特别清晰的增长概念，依靠经验或对用户的了解来决策产品要怎么做。后来，我们会统计一些宏观数据，比如 DAU 或者留存。我们发布一个版本，可能知道这个版本数据涨了，但是没有办法具体到是哪一个环节、哪一个策略导致了产品的增长。在现阶段，大家开始做精细化数据运营，会针对不同的用户做分群，然后给出具体的策略。但我觉得这样可能还是不够细致，我们要利用推荐系统这样的个性化 *** ，做到让数据自动决策。

举一个例子，假设我们现在要做一场运营活动，需要一些 banner 或者是入口，设计师会设计几套具体的方案和样式。如果是一位非常懂数据的产品运营，他肯定会同时上线这几个不同的 banner，然后去做 A/B Test，若发现 A 方案比 B 方案好，就会采用 A 方案。

我们公司现阶段也是这样操作的。

但在推荐系统的思路里，每个人千人千面，是十分个性化的。设计师辛辛苦苦做出来 A、B、C 三套方案，其实都是可以用的。虽然 A 方案受绝大多数人喜欢，但这并不代表 B、C 方案是没有人喜欢的。如果我们能够利用推荐系统这样的一种思想，采集足够多的用户行为，对其进行分析，就会发现不同用户对不同的封面有不同的喜好，那么 A、B、C 方案就都可以用，只不过针对不同的用户，我们会采用不同的方案。

运营同学可以通过分析将用户分群，给他们 A、B、C 三套不同的方案，但实际上用户的分群远不止 A、B、C 三组，可能存在千千万万个分组。运营同学没有办法手动做更细致的分群，这时候推荐系统就派上用场了。

2.1 推荐系统的适用场景

我们通常会把用户分成几个阶段，比如说新用户、老用户或者是非常资深的用户，还有一些即将流失的用户。但实际上，我觉得每一个用户可能都处在他的整个产品生命周期中独一无二的阶段，简单的把他们分成四块是不够的，我们需要用推荐系统的思想去分析具体的数据。

比如说，我们要做召回策略，每一个用户可能都有他非常个性的一个召回方案，这就是我认为整个增长接下来会逐渐进入的、更加细致的一个领域。我们给系统提供数据，系统通过一些策略自动给出决策。后面我来说几个这种泛化的可能实施的领域和方案，当然只是我的设想，实际上还没有完全落地。

个性化的活动运营、视觉设计

左边这张图是淘宝的首页，下面有一些子栏目，比如说聚划算、淘宝直播、官方补贴、每日红包，配了很多个性化的图片，但没有单独用文字。

比如说，最近我们家小朋友过生日，我看了很多与玩具相关的内容，再打开淘宝的时候，我发现那里仍然是官方补贴、每日红包等，但配图已经变成了与游戏相关的。因为淘宝本身是做电商的，它的配图可以直接用商品的图片。在做运营的活动封面时，每个用户可能喜欢不一样的图片风格，或冷色调，或鲜艳，或柔和。

那么设计师在出不同设计方案的时候，可能需要给封面增加一些关键词，比如说这个是鲜艳的，那个是冷色调的，诸如此类。随着多次做活动运营的设计，以及采集了足够多用户的数据，你可以知道每一个用户的颜色偏好。

精细化的用户运营召回方案

右图是手机上的短信页面，每日优鲜经常给我发这种召回短信，它的每一句话都不一样，但实际上并不是个性化的，没有特别打动我。像这种，同样可以通过学习用户的数据来掌握其语言偏好，给每个用户发不一样的召回短信。比如对于直男来说，一个软妹风的话术会更好。

注册转化流程的优化

甚至在极端的注册转化流程当中，也可以尝试利用推荐系统的思想给每个用户生成不同的注册转化流程。

当然这里面涉及一些问题，转化适用于全新的用户，你不太能获知这些用户之前的数据。但是如果你公司很大，或者是用户量非常大，比如说腾讯，你可能会提前知道这个用户大致的画像，那注册转化流程其实是可以提前设计好的，等用户来注册这个新应用的时候，就可以个性化的给他展示这一注册转化流程了。

2.2 推荐系统的困境

在不同场景和领域实施推荐系统的时候可能会碰到一些阻碍：

系统本身比较复杂，成本较高，可能造成投入产出不合理

之前我们把用户分成新用户、老用户、即将流失的用户，可能以很简单的工作就可以完成 80%的任务。而如果我们要利用推荐系统，那可能要投入 80% 的精力才能获得 20% 的提升。

推荐系统毕竟是基于大数据的分析，如果你不具备生产大量数据的条件，就很难做到在不同的运营、产品或者设计领域去泛化推荐系统的能力

所谓推荐系统，就是利用了机器善于计算的事实。我们人类非常善于联想、善于洞察事物之间关系的，可以发现一些用户同时喜欢摄影和游戏，但如果要真正做到个性化，最终还是要利用机器的计算能力。

以上就是我在做推荐系统的过程中，关于后续增长、发展方向的一点点想法，我们已经处于精细化运营的产品阶段，可能需要再往前走一步，让机器来帮助我们实现自动化运营，做得更加精细。

3. 推荐系统的增长实践

接下来是我在做推荐系统过程中，跟数据有关的一些案例，可能对大家有所帮助。

3.1 数据选取阶段

这一阶段需要考虑两点：

1）数据需要更形象

例1：发现更适合推荐系统的数据

做推荐系统最开始肯定是要分析，要利用哪些数据来发现用户的偏好，显然，点赞是一个能够明确知道用户偏好的行为，肯定是可以被利用的一个数据。但是否是最好的数据呢？

我们来看下面这两张图。左边这张图是用户相应行为的人数，包括视频观看、点赞成功、评论成功。我们可以发现，虽然点赞这个事情非常清晰的预示着这个用户的喜好，但是真正有点赞行为的用户并没有那么多。

哪个数据用户行为最多呢？明显是视频观看。因为用户来这里，就是为了观看视频。

右边这张图是人均相应行为个数。同样的，你可以发现，虽然点赞成功这件事情非常明确的标志着用户的偏好，但是他的行为量还是相对比较少，真正行为量最多的是视频观看行为。那视频观看行为能否预示用户的偏好呢？其实是可以的。一个用户去看这个视频，如果他不喜欢，他肯定只看两三秒就离开了。如果他把这个视频看完了，就可以预示他对这个视频有偏好。所以我们在做数据分析，或者所有的这些增长之前，要对手头的数据有一个更形象的认知，从不同的维度，平均数、方差、中位数等把这个数据图表化，这样才能选取合适的数据来做我们希望的分析。

例 2：内容曝光量分析

另外一个例子是视频曝光的数据。当这个视频出现在用户的屏幕上，就算一次曝光。下图代表视频曝光的平均数、中位数、以及最上面的 75 分位。我们可以发现一个问题，中位数是远远低于平均数的，平均数甚至接近 75 分位。

通过这个数据，我们能感知到一个什么问题呢？这个平均数其实是被一群极为活跃的用户硬生生提高了的。不管我们推荐什么样的内容，这批用户都会去看。假设我们要衡量这个推荐系统的效果，那肯定会去选择中位数，而不是平均数，因为中位数会更敏感。这就是为什么我们要做 EDA（Exploratory Data Analysis，探索性数据分析） 这件事情，即在真正开始处理数据之前，对这个数据有一个形象的理解，感性的认知。

2）产品特性是否对数据友好？

这里拿抖音举例，抖音的推荐系统做得非常好，仔细分析它的产品，它的产品特性对数据是非常友好的。

第一，产品特性决定了数据采集的难易程度。比如说抖音，这个产品刚出来很长一段时间里，它是没有暂停的。你看这个视频要么看完，要么就跳过，但是你不能暂停，也不能拖动进度条。为什么说这对推荐系统非常友好呢？因为一个用户看视频的时长代表着他对这个视频的偏好。一旦你可以暂停，又可以拖动进度条，那我就很难区分你到底是在看视频，还是处于暂停状态，或者你只是在拖动进度条。

而抖音把这件事情做得非常简单。如果你停留在这个页面上，那你一定是在看这个视频。所以，这个产品特性对数据的采集是非常友好的。

第二，产品特性决定了数据的可信赖程度。

右图是我们自己的产品，是信息流的状态，在滑动的过程当中会出现多个视频。而抖音是沉浸式的，一个视频会占满一整个屏幕。

抖音沉浸式体验的好处就是，你在当下这个屏幕上产生的所有数据全部是针对同一个视频的，这个数据是极为可信的。并且，抖音还不能自动播放下一条，只要保证你不手动滑，它就会一直维持在这个页面上。

而在我们自己的产品中，有时候你可能无法分辨，用户行为到底是针对上面这个视频，还是针对下面这个视频的。

第三，产品特性可能决定数据分析和使用的难易程度。

你的视频时长 15 秒，或者 1 分钟，或者 5 分钟，用户的观看行为所产生的后果是完全不一样的。

15 秒的视频，用户很容易就看完。如果是 1 分钟的话，他完全看完的可能性就会极大的降低。如果是 3 分钟，基本上就没有用户可以真正把这个视频完全看完。

如果你直接拿用户观看时长或者比例来评判用户的偏好的话，就会产品很大的偏差。短的视频非常容易看完，完播率很高，长的视频完播率很低。意味着用户就不喜欢长的视频吗？

抖音在产品很长的一段时间内，会把视频时长限制到15秒，这样 15 秒以下的视频，基本上就不存在刚才说的长短视频完播率不可比的情况，需要考虑的问题就简单许多。

如果你这个产品设计得对数据非常友好的话，产品特性对真正分析数据、后续使用数据是有极大的促进作用的。

总之，在数据采集之前，你对这个数据要有一个全面的 EDA 的掌控。同时从产品层面上讲，产品特性需要对这个数据友好。

3.2 数据采集阶段

对于我来说，这是最为困难的阶段，非常容易出错。一旦出错，你的产品、运营，甚至你的老板都会对这个数据不再信任，那整个增长就无从谈起了。

所以，数据采集阶段就是整个数据增长的基石。首先你要建立一个非常良好的数据采集机制，保证这个数据是准确无误的，最终你才能产生正确的结论，让大家相信数据，能够利用数据做最终的决策。

这里举一个我们自己在数据采集中出现的错误，一个非常极端的例子。这个图是用户观看单个视频的平均时长。我们把用户随机分成了 16 个组，所以有这么多曲线。

按理说，这 16 个组的曲线趋势应该完全一致。但刚开始采集这个数据的时候，我们总会发现，有些组会突然产生尖峰，组与组之间曲线行为不一致，对后续的 A/B Test 等会产生严重的干扰。

按理说，平均数很难受到脏数据的影响，但是这次我们发现的脏数据比较极端。

比如，我们的视频一般都是 5 分钟（300 秒）以内，但是有些用户上报的观看单个视频时长达到了几万，或者是几十万秒这样的极端情况。虽然概率非常低，但是它就是极端的影响了我们的平均数。

我们后来发现，原因可能是，用户有时候看着看着就退出了，直接把 App 隐藏在了后台，而内部的计时器没有停止计时，会延续到这个用户再次打开 App 时才结束。如果用户几天之后再打开 App，他观看视频的时长就会变得极长，以此类推。

最终我们把这个问题修复了，大家就可以看到用户观看视频的平均时长，16 个组的曲线就都一致了。

所以说，大家在做数据采集的时候，一定要找到一个非常合理的产品研发流程，一定要建立好数据信心，一旦你在产品或运营那里丧失了对数据的信心，数据增长这件事情就无从谈起了。

3.3 数据使用阶段

数据很多时候是自带欺骗性的，我们使用数据的时候要注意以下 2 点：

1）数据是否表意明晰？

用户数据进入推荐系统后，本质上形成了一个非常大的矩阵，纵坐标是用户 A、B、C、D、E，横坐标是视频 1、2、3、4、5、6、7、8、9，对应的值为某个用户观看某个视频时长的比例。这是一个极大的稀疏矩阵，观看比例绝大多数都是 0。0 代表他没看过这个视频，因为用户能够看到的视频相比我们视频库里的内容量是很小的。

如图，用户 A 观看视频 1，100% 表示看完了；用户 B 看视频 1，看了 80.1%。

数据处理阶段，我们会把数据做截断，只保留 3 位小数。那么问题来了，例如图上标红的地方，用户 C 看视频 5 只看了 0.001，那我们理解为他可能不喜欢这个视频；而对于视频 9，真实情况他只看了 0.003，由于我们在做数据处理的时候会保留 3 位小数，这里就变成了 0。根据 0 在这个矩阵中的含义来看，这个数据表达的意义是不准确的，从他不喜欢这个视频变成了他没看过这个视频。所以说，数据本身自带欺骗性，如果你做了这样的处理，那它就表达了错误的意思。

2）数据是否自带倾向？

我们做推荐系统，该怎么衡量用户喜好呢？

假设用户看一个视频的时长为 50 秒，看另外一个视频的时长为 30 秒，那我们会天然地觉得他更喜欢前者。同样的，如果一个视频他看了 100%，另外一个视频看了 50%，那我们也会认为他更喜欢前者。所以，视频观看比例和视频观看时长这 2 个指标都可以作为衡量用户偏好的标准。

看上面两个图表，横坐标都是视频时长（0~300 秒），左图是用户平均视频观看比例，右图是用户平均视频观看时长。举个例子，如果一个视频大概是 50 秒，那么平均观看比例大概是 60%；如果一个视频大概是 300 秒，那么它平均观看比例就只有 30%；但是 50 秒的视频平均观看时长是 30 秒， 300 秒的视频平均观看时长可能就是 100 秒左右。那么，如果你用平均观看比例来衡量用户偏好，50 秒的视频有先天优势；如果拿观看时长来衡量用户偏好，那么 300 秒的视频就天然有优势。

根据这个例子可以看出这两个指标各自带有倾向，如果拿用户观看比例来衡量用户偏好，则倾向于推荐短视频；如果拿用户视频观看时长来衡量用户偏好，则倾向于推荐长视频。

再联想到，抖音把视频时长限制在了 15 秒，这就把大家都拉到了同一条起跑线上，无论是用比例还是用时长衡量，结论都是一样的。如果你的视频时长分布非常广，比如从 0 秒 到 300 秒，那就很难决策，到底要拿哪一个指标来衡量用户的偏好，因为任意一个指标都有自己的倾向性。

3.4 数据分析阶段

在数据分析阶段，我推荐用 A/B Test 来做评估效果。

1）正确认知 A/B Test

实验即需求本身；需求文档就应该是一份实验方案。

很多同学会觉得做 A/B Test 是一件耗时耗力的事情，但换一个角度想，你在写产品需求文档的时候，写的实质上是一个实验方案，实验和需求本身是无法剥离开来的。实验结果往往需要关注多个指标。真正做 A/B Test 的时候，我们需要关注很多的指标，一些指标增长的同时，另外一些指标可能会下降。

实验需要足够的样本，关注实验的统计显著性。

A/B Test 的样本量如果不够，可能得出的效果就不那么真实了。

实验时长有限，往往反映短期效果，具有短视性。

做实验的时间是有限的，你不可能永远都在做这个实验，这就天然的导致了 A/B Test 往往反映的是一个短期效果。比如说刚才那个实验，只做一天，数据增长了，但在长期来看，它可能会慢慢趋于与其他组同样的效果。

2）A/B Test 实例

下图是我们推荐系统刚上线时候的一个例子，数据是用户平均观看时长。蓝色的 0 组是测试组，刚上线时效果要比其他组好很多。但是在第二天、第三天，我们就发现效果在减退，是什么原因导致的呢？

我们的第一反应很简单，再上线两个组，看是不是会产生同样的效果，于是就上线了 12 组和 10 组。在上线前两天，它们和 0 组一样，数据增长的效果很好，但是到了第三天，效果同样在减退。由于对自身的推荐系统有足够了解，我们推测，用户消耗完了他们偏好的数据，而我们没有补充上足够多的这类数据，就导致效果减退。于是我们做了第三个测试，增大了数据库里数据的量，给用户推荐更多他偏好的内容，数据就增长了，而一旦消耗完，则又减退。通过这样的手段，我们把数据增减的原因分析得很透彻。大家要学会利用好 A/B Test ，同时配合对这个业务的理解，才能做好数据分析。

3）数据分析能力与业务理解能力的关系

最后需要强调的是，数据分析能力是建立在对业务的理解基础之上的，两者息息相关、齐头并进。正如我刚刚说的 A/B Test，如果你对推荐系统本身不够了解，就很难分析出来数据减退的原因是用户偏好的数据量不够。

大家一定要同时增长自己的业务理解能力和数据能力，才能最终做到数据驱动。以上是我这次分享的主要内容，希望能够帮助到大家，谢谢！

作者：李威，糗事百科产品总监

来源：GrowingIO 2019 增长大会（北京）演讲

本文由 @GrowingIO 授权发布于人人都是产品经理。未经许可，禁止转载

题图来自 unsplash，基于 CC0 协议。