今年夏天，“白居过隙”，大龄少女第一次接触中国粉丝文化，深感数据粉也许是最懂策略PM的人。数据粉参透了微博超级话题的排名计算规则、阅读量计算规则以后，会在明星超话发布数据扫盲贴会手把手教小粉丝草数据。各类粉丝社区app也纷纷开启各种粉丝群体任务，用明星资源置换产品DAU。
我观察了一些APP，如爱奇艺泡泡、腾讯doki、超级星饭团等。这些都是关注明星、娱乐话题的粉丝聚集社区类APP，提供明星动态追踪、粉丝社区、线下活动组织等核心功能。其中，泡泡、doki这类背靠影视产品的APP，做粉丝社区是有天然的优势的。因为粉丝关注的娱乐明星或者是话题，都依托于内容产品（书籍、影视剧、动漫、音乐作品、综艺节目等）的输出。除了社交讨论的需求，粉丝天然有关注内容产品的需求。在版权意识愈加强烈的背景下，内容平台和社区产品的联合出击，能够更好地形成生态闭环，让粉丝在产品矩阵中留存下来。
拆分了爱奇艺泡泡，用冰山模型做一个产品分析吧。由于不是从业人群，以下分析仅是根据《爱奇艺泡泡》C端iOS版APP展示的功能推测整个泡泡产品（以下简称泡泡），需求分析没有数据支持。
战略层
范围层
泡泡产品分为C端应用（移动端独立APP、web页面、桌面端版块）、运营管理后台、基础数据模块，和爱奇艺用户管理模块、视频数据库等有数据调用；不确定是否有2B后台，支持明星团队或者是粉丝后援会申请入驻和提供明星资料等功能。
参与业务角色包括运营（包括社区内容运营、明星入驻运营、活动运营等）、C端用户、明星用户。
一般来说，功能型产品需要考虑功能规格，包括以下三个问题：
产品有什么功能?
系统有什么要求？
数据有什么要求？
信息型产品需要考虑内容需求，可以用以下两个问题来帮助发散思维：
什么媒体形式？
内容的范围和主题？
泡泡作为服务于粉丝的资讯型产品，有鼓励用户间交流，提高社区活跃度的商业需求，属于综合性的产品。C端产品希望覆盖以下业务场景：
结构层
在信息产品中，C端业务的核心就是C端用户对承载信息的内容对象进行操作，操作包括增删改查四个方面。泡泡产品的定义了五类内容对象，包括：
这五个内容对象各有其数据表，表之间按照规则彼此关联。C端用户在C端对内容对象的数据表进行读写操作以后，表内数据按照产品规则展示在C端和运营端。内容对象会出现在C端的feed流、搜索结果页等位置，曝光策略除了产品算法以外，也会受到运营配置管理。
帖子是一般C端用户可以创建的基本对象，也是泡泡产品内最大的用户增量数据，它很好地支持起了用户的交流表达的载体作用。泡泡规定帖子必须从属于一个圈子；帖子可以自带话题。所以话题可能会和多个圈子有关系。这相当与按照两种维度来定义了帖子的主题，多渠道增加帖子被曝光的机会。
产品内定义了话题榜单、圈子榜单、动态广场等功能，都是用多个维度来定义和表现帖子、话题、圈子这三个内容对象，增加它们在产品内的曝光率，有效地满足目的性不是那么强烈的用户的“随意逛逛、随意看看”的需求。
圈子是粉丝聚集的基石，圈主题就是粉丝“fan”的主题，可能是明星，可能是影视剧，可能是运动员。不同圈子的粉丝诉求不同，所以泡泡产品设置了多种类型的圈子，不同主题的圈子内为粉丝提供的功能不同。
内容对象的功能设计是泡泡这个内容社区的基石。为了促进活跃，产品在圈子内设计了任务系统和等级系统。有两种形式：
1、单人在圈子内的任务系统。不同圈子的任务系统彼此独立，互不干扰。
2、多人完成一个应援任务。
结构层反思
我对泡泡的内容对象的边界划分没有异议。但是对于用户任务系统和等级系统的玩法，我有一点想法。
1、圈子的任务系统。集圈子粉丝之力，完成一个由运营发布的官方任务，完成后可能是圈子内的所有粉丝得利，可能是圈子代表的明星获利。这个有一点像是活动玩法的变形。
2、用户等级评定，除了在每个圈子内有单独的等级，也可以根据用户参与圈子的总体情况，设计跨越圈子的成就系统：
* 在一个圈子连续打卡三十天的用户，可以获称“真爱唯一”
* 连续五天在多个圈子打卡的用户，可以获称“墙头众多”
