在常规的产品线中，用户数量在百万内，根据产品的属性不同其日活跃可能在30%，也可能因为运营推广做的数据质量太差，活跃可能在1%，但存在高并发量UGC，也就是在用户的FEED产生能够在一时间轴的纬度下，会有上千、上百或更多的FEED产生，如何去踢去无效的FEED，将有效的FEED推荐给与用户，其业务流程如下：

FEED的出入流程

这里用户在拉去FEED的过程中，这里我们常有的是三种算法，第一种是PUSH、第二种是拉、第三种是推和拉集合。

其中推类似以FACEBOOK这样的，将FEED推给用户，用户将直接接受到其FEED。

推的模式

拉的模式恰恰相反，类似与新浪微博的形式每用户下拉其将其FEED存储区的FEED拉进来，而不是全部获得存储区的FEED。

FEED存储区

这里说到FEED存储区，就要引入未读池的概念，如何在高并发量以及高量FEED产生的情况下，保证用户能够索取到想要的内容？

FEED存储

这个就是FEED的存储方式，将其FEED存储在数据库中，我们以最近的FEED、近期FEED、比较长期的FEED，3个时间区进行存储。

刚才上面说的关于重力排序法中，时间段的区分，就是在这里进行时间区分，其中这个时间刷新我列举了3个小时、1天、7天，但这个时间段产品经理应该利用自己的数据分析能力，j2直播，将其UGC社区中的FEED量进行统计，预算出其可行的FEED时间划分段。

FEED随时间的发帖数

如以上FEED因每天产生的内容在100条FEED左右，因此建议用3小时、1天、7天作为时间点，太短了FEED也没有新的生成，太长了也没办法将FEED进行拿出。

但请注意的是，这里是的FEED并发量低的时候或量不多的时候。

那么回到刚才的问题，高并发量或高FEED量怎么办？

这个时候我们就要引入未读池的概念，这也是我猜测微博所采用的一套机制。在FEED产生高并发的情况下，用户下拉的FEED不可能把整个平台的FEED全部拉取（几千上万条，看都看不完），当然产生这么多的FEED原因是因为微博的定位并不是做好友间的社交关系链，而是以用户之间、人与人之间的社交关系。

对于微博的UGC模块中，FEED其核心的就在于未读池的算法处理（这里我猜测是以智能推荐，早期可能是重力排序法）。

未读池FEED

这样的FEED产生之后，其在未读池中，FEED可能会出现永远都不可能被用户阅读到，系统通过之前我说明智能推荐算法，将其认为的垃圾FEED或无效FEED永远不上传给予用户，因此这套机制就能够解决高并发量的情况下，给予用户有效的FEED。

但这里也会存在一个问题，因为FEED的产生有时间属性，因此用户在拉去FEED是的时候会发现有一些FEED因为不具备时间轴的顺序，本来昨天发生的事情，今天才拉去出来。让用户产生摸不着头脑的感觉。

总结

对于FEED，这是一个UGC的必备属性，产品经理需要不断的学习和思考根据自己的产品业务属性、产品定位来制定相应的算法，但市面上大部分的产品对于FEED的把控依旧不够。这里的原因有很多，其中最重要的就是FEED的高并发、用户数太少，比如微博、微信这样大体量的产品，不是每天都可能诞生。

但是对于FEED的过滤，PM至少应该知道其算法，在近期产品需求调研中工作中，我希望将学习到的FEED算法共享，第一是相关资料比较少；第二是目前FEED的算法相对来说其门槛较高。

#专栏作家#

kevin，微信公众号：Kevin改变世界的点滴，人人都是产品经理专栏作家。曾从事腾讯云产品设计与中兴通讯产品研发，现金融产品经理一枚。欢迎交流