3

【0到1】APP简易化搭建社区推荐

 1 year ago
source link: https://www.yunyingpai.com/content/942961.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

【0到1】APP简易化搭建社区推荐

本文以作者所在团队打造社区模块的过程为例,梳理了社区推荐的具体思路。

GXaNYf8Oobukoj7IjwV0.png

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

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

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

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

一、思考-正向推荐

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

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

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

例如社区的正向流程:

1)给谁推荐内容?

2)推荐什么内容?

3)推荐内容的数量构成?

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

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

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

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

最后推荐数量构成:一般情况下,上拉刷新或下拉加载,推荐9~12篇内容;那这12篇内容如何构成呢?

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

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

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

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

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

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

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

二、思考-逆向风险

社区的逆向流程:

1)内容不够怎么办?

2)如何验证推荐好坏?

3)新用户怎么推荐?

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

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

其次是验证推荐好坏?不管是内容算法推荐还是简单的逻辑推荐,推荐出的结果不一定会让用户或自己都满意,这里产品要做好预期,有条件的产研团队可以做AB测试、分桶试验等等来调优。我目前所在团队做不到这块,我就不发挥了。

最后新用户怎么推荐?这里单独拿出来说一下,是因为考虑到社区氛围感问题,老用户我们可以通过上述的推荐逻辑进行推荐,如果新用户也按照如上方式,也是可以的。

但产品要思考当前文章整体质量如何,首先能不能让内部自己感受到社区的氛围以及社区想要引导及表达的内核;如果弱一点或不自信,可以支持运营对新用户进行单独内容配置,作为新用户初始内容,这样有引导性的让新用户看到我想让他看到的内容,用户感知理解可能会强一些。

以上算是理出了社区推荐的雏形思路,具体细化因产品而异;当然不可否认是很简陋的版本,这个说实话也因公司、项目及团队而定;大团队有大团队的算法工程,小团队有小团队的逻辑处理。

在整理学习过程中,像社区治理、创作激励、推荐干预、后台审核等大模块的思路及经验,我是插不上话的,但小的思考我还整理有如下几点,在我们社区目前阶段并未实现的很彻底,觉得值得做社区时思考,我列出部分,举一反三;

初始分:在内容刚发布时,可赋予一定初始分值,这个分值可根据用户账号权重值来计算得出;比如UGC、PUGC属性、用户在平台的粉丝、活跃情况等综合计算。推荐分:官方运营可以对优质内容或垃圾内容,进行正负权重加分,进行一定的人工干预影响。时间衰减:指的是文章发布后,由新鲜到历史的时间衰减函数公式(牛顿冷却定律),让内容逐渐降温。

上述部分初始可由简单计算公式逐渐过渡到复杂公式;但由于我司没有成型的内容产研团队,这些都还未实操过。

优质内容分发:根据推荐逻辑-优先推荐给固定范围兴趣人群-如果文章继续发酵,则按热度上升至首页-在首页推荐层如果文章继续发酵,则进入运营人工干预阶段,在后台控制是否助推或控量。

其次,这中间涉及到不同账号权重,可能会分发不同量级的流量进行验证;还有相对公平的流量分配机制,依托粉丝关系、兴趣推送的分发机制等,这块我们没有实现,我们用户量基础当前不是很大。

内容聚合显示:内容聚合功能,根据不同内容的划分维度,将同类内容放到一个页面进行展示。用户可以通过某一聚合功能,浏览到所有同类内容。常见的聚合功能有版块、圈子、频道、专题、话题、标签…等等,具体如何使用根据具体的业务形态来判断。我们文章基础数量也不是很大,所以这部分也未实现。

内容数据填充:在用户互动数据量级不够时,就需要通过填充一些“假”数据,提升社区热度观感,以及在用户发布内容后可以及时获得正向反馈。

比如阅读、点赞等等,可以在发布时,在一定范围内逐渐递增基础数值;评论的填充成本稍高一些,需要准备一套量级足够的、通用的评论库,在内容发布后自动填充到内容评论区。评论可以按场景进行分类,对应不同的内容标签;这部分我们也未实现,但值得冷启动社区思考。

作者:貓小力

公众号:运营增长(yunyingxq)

本文由 @貓小力 授权发布于运营派。未经许可,禁止转载

题图来自 Unsplash ,基于 CC0 协议


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK