练习作 · 一个动漫资讯app的雏形

1. 对内容推荐的一些看法

前几天发现B站移动端的首页-番剧好像改版了，番剧推荐被移到了外面（按以前的印象是放在索引里作为一个分类的，和其它番剧题材是同级），在番剧索引里也加入了追番排行榜的功能。趋势是，番剧的推荐变得越来越重要。

关于内容推荐的形式，就目前所接触的，可以概括为：编辑推荐、KOL推荐、好友推荐和个性化推荐。

B站的番剧推荐属于编辑推荐，这或许是最容易的推荐，但个人认为也是最没有效率的推荐。一个番剧推荐列表翻下来，题材五花八门，画风五花八门。但对于稍微资深一点的动漫爱好者来说，在一定程度上都是有各自的题材和画风喜好的。那么番这种推荐列表就跟买彩票一样，能不能碰上感兴趣的，得看运气。

KOL推荐和好友推荐，前者需要KOL资源和粉丝群体的积累（比如知乎），后者需要一度人脉的积累（比如网易云音乐和微信朋友圈），都不是一个新app在冷启动时期能够轻松完成的。况且对于好友推荐，也并非所有领域都能适用的，比如文化消费这样个体差异极大的，其实未必有效。只剩下个性化推荐，尽管后期对于算法的设计和服务器的性能要求高，仍然是目前所有领域的资讯产品都在逐步采纳的。全领域的个性化推荐大概是全民娱乐时代的必然产物吧。

而个性化推荐也有主动和被动两种。被动即依据用户在应内的各种行为，由机器严格按照算法进行推荐。我所认为的主动推荐，则是用户根据自己的爱好在前期主动关注标签或话题，后期由应用自动推送相关内容，无关其它的用户行为。

刚刚了解个性化推荐的时候，觉得像今日头条和网易云音乐这样坚持完全按照机器算法来实现的产品是十分牛逼的，当然现在也觉得牛逼。但是接触多了之后，也看到了其中的许多弊端，让自己对机器算法和被动推荐有了重新的思考。没有实际接触和参与过算法设计，却能感受到其设计过程有多艰难。比如，究竟什么样的用户行为能够代表这个用户对内容是真正感兴趣的，哪些行为又该判断为是误操作？用户的兴趣一定是缓慢演变的吗？如果其兴趣突然发生了重大转变，机器该如何调整才能避免用户失去耐心？一千个读者，就有一千个哈姆雷特。要以个体为单位精确识别每个用户的爱好几乎不可能，那么允许的差错范围又应该如何规定呢？

今日头条的推荐机制被人诟病已久，主要问题有：1. 在个性化信息流里，热门新闻、本地新闻和广告的比重太高了，这些都无关个人兴趣（没有机会拿到算法，这是个人的使用感受）；2. 只关注了内容分发环节，忽视了内容生产环节，导致标题党和低俗内容横行，这些都是机器无法识别的；尽管在头条号推出后对内容质量和互动有了要求，但目测收效甚微。作为网易云音乐的忠实粉丝，云音乐通过多种不同的算法并行的方式，更好地满足了个性化需求，但仍然时不时能看到用户吐槽同类型音乐推荐太多的情况。

所以说，在目前的情况下，机器了解人的需求仍然是有限的，最了解自己的人仍然是自己。这是标签化的主动推荐方式的优势所在。

2. 产品雏形（取了个很怂的名字叫ACG迷妹...）

关于这个产品雏形，就是采取了用户主动关注标签，并自动推荐相关资讯的方式。难点在于，获取的内容如何标签化，以及这些标签如何管理，才能在成本可接受的范围满足个性化。下图分别是app端的部分功能设计稿和后台业务逻辑。

移动端设计稿（Sketch制作）

移动端大概的逻辑为：看资讯为主，但考虑到单纯看动漫资讯需求比较弱，加入了追番工具作为辅助（追番的习惯主要针对日漫爱好者），在每季度新番刚更新的时候用处较大。而资讯的推荐一定是以标签为单位的，用户需主动关注标签后方可推荐。推荐的内容中可能还包含其它新标签，鼓励用户关注新标签，由此向外辐射形成源源不断的兴趣更新机制。

因为是深度垂直的动漫资讯产品，所以标签的创建也是为动漫量身打造的，维度包括作品（核心标签）、原作者、导演、制作公司、配乐、主要声优等。不过能否适用到其它领域与后台的设计息息相关，只要后台设计足够灵活、完全可配置，要活用到其它领域应该也是没有问题的。

后台与运营逻辑

没有设计过资讯产品的后台，可能显得业余了。想要突出的是标签库的管理和团队分工机制。给每篇文章都打上标签的工作量看上去很大，但是标签的管理是一个长期积累的过程，可以优先创建关注度可能较高的标签，也就是热门维度的，再慢慢向外发散。