APP简易化搭建社区推荐

一个 " 好社区 " 的运营与成长需要耗费大量的成本，本文以作者所在团队打造社区模块的过程为例，梳理了他们是如何思考处理当前社区打造的，希望对你有所启发。

因自家产品业务规划需要，我们目前在搭建【社区】模块，并准备在一级菜单栏开放入口，这事看上去挺大动静；因为从事互联网行业的同学，多多少少知道，内容社区可以说是一个行业了，而且是一个比较成熟的行业市场。

例如往大了讲，有独立的小红书、知乎等社区型产品，往小了讲有 Keep、网易云等，在 APP 中嵌套社区的做法（我们目前就属于这类）。

其次，一个 " 好的 " 社区也不是一个小团队说做就做，立马能支撑起来的；成熟的社区离不开供需关系，也就是内容消耗者和创作者，以及复杂的推荐算法；并配套内容审核治理、成长等级、创作者激励等等一系列运营制度来运行。

令人遗憾的是，以上这些我们当前团队能力，都做不到；所以我想写这篇文章总结一下，看看我们是如何思考处理的。

一、思考 - 正向推荐

因为我所在的团队没有一个懂内容的运营和产品；只是老板想要，交代下来就开干了！（听起来，跟你们公司咋样，哈哈哈）

所以作为一个【非专业且不合格的】社区产品经理，我被指定负责社区模块时，只能抱着敬畏心边学习边思考边设计；中心思想是尽量先做小但保证对（合格），实际运行后根据实战经验再调优迭代。

在开始之前，我们先梳理一下功能流程，作为产品要记得，不管接到什么功能需求，都先自己理一下正流程和逆流程，然后在思考其中设计的关键点所在，最后输出原型时，才能妙笔生花。

例如社区的正向流程：

1）给谁推荐内容？

2）推荐什么内容？

3）推荐内容的数量构成？

…

首先给谁推荐：这里可以通过用户标签与内容标签，相结合进行关联推荐；简单举个例子，用户分享了某篇文章，该文章在创建时运营打上了 " 娱乐 " 标签，那么再次推荐时，就会给用户推荐含有 " 娱乐 " 标签的内容。

打标签有很多场景，这又属于另一个大类型了，网上有很多文章的，这里就不做赘述。

其次推荐什么内容：内容也有很多种形式，这里产品经理需要整理自家 APP 内有哪些内容向产出，比如 UGC 发帖、内部运营发帖、外部邀请合作或搬运的 PUGC、KOL 发帖、或创建的话题等等。

像我们 APP 还有商品的咨询问答，其实也属于内容产出，尽可能囊括全部，并非是说要在社区中一股脑推荐给用户，而是清楚后，以便于在合适的时机进行改造，比如我在社区推荐瀑布流中会随机插入一个商品咨询问答的卡片。

最后推荐数量构成：一般情况下，上拉刷新或下拉加载，推荐 9~12 篇内容；那这 12 篇内容如何构成呢？

最少需要考虑三种情况：一种是运营强推荐，比如运营推荐文章，属于首次进社区必现；一种是热门文章、新鲜度文章（发布时间近）的推荐、一种是标签关联推荐；

延伸处理：我们又把标签推荐分为分实时浏览标签和历史浏览标签两种状态，这样用来区分推荐结果，比如今日首次进社区，还没有浏览内容情况下，根据历史推荐；有过浏览后，就需要根据当前浏览结果进行推荐。

以上如此划分，是因为推荐算法逻辑我们不懂（没有算法工程师），但整体思路是要保证公平性，任何类型的内容都有机会露出，不可能全是标签推荐的内容、也不能全是热门推荐。

继续往下拆解：就是推荐内容数量分配问题；最粗暴的一种方案是配数，比如一次刷新推荐 9 篇内容，热门文章取 3 篇、新鲜度文章取 3 篇… .

另一种方案是给每一种内容属性设置分值，比如热门文章设置高中低三个段位、新鲜度文章按发布时间也设置高中低… .

然后每个段位都对应给默认分值，最终根据文章累加的总分，进行推荐。

延伸处理：不管是哪一种情况，都要考虑内容库是很大的，比如有 1000 篇文章，计算每篇文章分数再推荐出 9 篇文章，研发可能需要十几秒，但加载刷新一次仅需 2 秒；这中间就会存在问题了，需要与研发讨论是否根据历史标签先做一个默认的初始推荐库，随时往里面更新替换内容。

二、思考 - 逆向风险

社区的逆向流程：

1）内容不够怎么办？

2）如何验证推荐好坏？

3）新用户怎么推荐？

… ..

首先内容不够怎么办？作为一个从 0 到 1 的社区，如果没有庞大的用户基础和激励政策，内容产出是一个大问题，我们初始内容只有几千篇文章，就需要考虑这个消耗问题，如果初始内容库有几万篇文章，或许可以过渡一段时间。

有能力的话，产品可在会议过方案时提出风险，跟内容团队及领导约束，定期产出多少内容（不论自产、购买或用户发帖）来确保消耗；