工具类APP社区话题冷启动-以美的美居APP-场景知乎为例纷传付费社群工具链接会员社群经济

本文来自微信公众号 “ 场景阿侯 ”，作者：Homer，纷传经授权发布。

而对于一个产品经理来说，当你拿到一个项目，根据自己已有的方法论，苦思冥想终于得出项目推进方案时，会面临一个最具challenge的时刻-提需求。

很多产品人觉得，提需求就是输出一份足够详细、逻辑缜密的PRD：产品需求文档，来进行产品业务逻辑需要的描述。

其实不然，PRD只是对业务逻辑和推动思路描述的一个外在承载形式，更应该关注的是产品人本身对问题的思考。

怎么提需求？我认为所处的环节可以分为两个阶段：一是，要学会以理服人，也就是为什么要做？要说服你的需求承接方，为什么你的需求是合理的，凭什么要调用他们的资源；二是，要学会抓住重点，以法示人。这里的法是方法，也就是告知承接方，你想怎么做。

“理”和“法”均离不开数据的支持，当别人质疑你需求的时候请摆出数据，它是最具说服力的工具！

这篇文章分享的正是在一个业务推动的过程中，以来源入口和行为漏斗为例的数据指标体系的建立思考过程。用户的参与行为如何界定，行为漏斗如何设定以及用户来源入口怎么分类，都是这次会分享的观点。但因为实际业务的多样性，这里分享的只是我的思考过程，毕竟数是依托物而存在的，希望可以对大家有一定的启发。

前言

该选用什么样的数据反映给需求承接方，让对方知道你的需求是有价值的，实质上就是要呈现当前项目能取得的成果，或所处背景的发展前景。具体到一个社区话题冷启动成果的判断维度，可以是用户参与和转化的行为，也即是所谓的行为漏斗。

Part.1 话题参与

衡量社区话题冷启动后用户的参与度如何，本质上是要定义怎么样的行为后，用户算是参与了讨论。不同的社区功能设定，参与的标准可以采用不同的定义。而对当前美的美居APP的话题参与，我定义了两个标准：话题区页面曝光&话题相关的动态被点击详情。

	话题区页面曝光
	对于绝大多数的社区功能设定而言，某个话题的特定讨论区是作为内容模块设定存在的，必定可以找到相应界面的曝光，此时定义用户被引流落地
	如下图，左一为当前场景知乎的话题区，作为对比，图二、三分别为虎扑和微博关于某话题讨论的落地页面

	话题相关的动态被点击详情
	一个存在社区模块功能的APP，如若存在关于某个话题的讨论，和该话题相关的内容往往不仅在话题专区进行展示，大多数存在一个内容大杂烩的地方进行浏览，如“广场”，“圈子”等。
	如下图，分别是在美居APP的推荐tab和圈子tab中，某篇动态的瀑布流展示，以及点击后的动态详情跳转。从内容呈现的交互形式看，对属于某个话题的某篇动态，当其展示的位置不在话题专区时，往往会给该动态带上专属的话题标签。值得注意的是，这里所定义动态详情被点击查看，是指经左图点击后，跳转右图详情页被展示，单纯左图曝光没有意义，因为那可能只是用户被动推荐浏览时，设备终端呈现的页面，无法从该页面的曝光定义用户对该话题的内容感兴趣。
	此外，动态和动态详情的内容承载关系，是实质大于形式的判断。 1.如上图，分别是动态在某话题区的瀑布流展示，及点击后的详情跳转。它和推荐tab及圈子tab的动态内容，在交互形式上看，缺少了动态关联标签的呈现。因为在用户的角度，是在某个话题区里查看的动态，当然默认该动态属于某个话题，也就不用多此一举再给这条动态贴上标签。 2.单独列出这种现象的原因在于，我们在统计某个话题相关的动态被点击详情查看时，往往根据一定的规则来进行行为上报，如某篇动态详情的曝光页面中带有该话题的标签，则该动态详情在统计数量时＋1；倘若用户是在话题区打开某条动态，此时的动态详情是没有任何的标签关联呈现的，统计相应的行为则可采用在话题区对该动态进行点击的操作来代替，而不是页面的曝光（理想情况下，若点击A跳转到页面B，则对A的点击数量和B页面的曝光量应相同）。 ps.这部分行为的统计，和特定功能或行为的埋点如何定义，上报有哪些参数相关，在之后会有专门的文章进行分享。

Part.2行为漏斗

追踪用户参与话题后，主要做出什么样的操作行为，以及做出相应行为的频率，是在定义用户参与对某话题讨论后的下一步，我把它阐述为行为漏斗。

漏斗一词经常在互联网的黑话中出现，通俗的理解可以看成是一个比值，如A/B，即B中有多少个A。而当这个比值用于理解用户链路时，倘若加上行为前后的因果关系，则可称为行为漏斗。

如，有B个用户点击某个入口进入了话题区，或其话题区界面得到曝光后，有A名用户发布了带有该话题标签的动态，则比值A/B反映的是动态发帖的行为转化漏斗，代表当每B名用户浏览了某话题，就有A名用户继续选择发布该话题动态的操作。

当然，上述行为前后的因果关系有可能是主观上的，也可能是客观默认的。

还是同样的例子，如果在APP的动态发布环节，想要发布带有某个话题标签的动态，只能在该话题专区进行动态编辑时才能操作，此时，A和B是一一对应的关系，发布动态的A名用户必定属于进入话题区讨论的B名用户当中，这是客观默认的理解。

而如果发布带有某个话题标签的动态可以在APP内的一个通用动态编辑模块进行，此时用户想要发布带有某话题的动态，不一定需要进入该话题专区，或先进行对应的动态详情浏览，只需简单的为自己的动态贴上该话题标签。这样的A和B就不是一一对应的关系，做出A行为的用户不一定从B行为里面来，也即所谓的主观上的因果强加。此时的行为漏斗解释为：每B名用户参与了话题的讨论，有可能带来A名用户进行该话题相关的动态发布。

	漏斗体系
	阐述了如何定义一个用户参与了话题的讨论，来到了话题。现建立如下行为漏斗进行当前话题的承接效果分析。
	1一级行为分别是发动态、评论、点赞、收藏、关注、分享，具体定义如下：发动态：所发动态带场景知乎的标签，或该动态出现在场景知乎话题区中评论：对“发动态”中的动态去评论。（评论指的是一级评论，即不算某篇动态中所引起的评论之间的互动，用评论对象来说，一级评论的对象是某篇动态）点赞：对“发动态”定义中的动态，及其中一级评论的点赞操作收藏：对“发动态”中的动态去收藏关注：关注场景知乎话题，及通过“发动态”中的某篇动态详情页关注发帖用户分享：对“发动态”定义中的动态进行分享，对场景知乎这个话题进行分享关注点 1.行为漏斗的统计时，用户在动态详情页浏览时的关相关行为可理解成是被该话题相关的内容吸引而导致的，可作为评判话题效果的参考依据之一。 2.进一步，可以把该行为理解成是由话题引起的社交互动。如果在后续的数据统计时，发现有一定基数的用户选择了通过某话题相关的动态详情页来关注发帖者，反过来思考，此时对话题的引流，是否可以转成对某些积极参与该话题讨论的用户个人主页或所发动态的引流？ 3.一级行为漏斗的分享行为不区分分享平台，只关注该操作。后期若区分分享渠道效果，可以进行单独二级漏斗分析。 2二级行为二级评论：指对某篇“发动态”定义中的动态，进行其中的评论回复行为二级评论回复的对象是某篇动态当中的评论，如A关于话题发了动态A1，某名用户B对A1进行了评论B1，这为一级评论；而当某名用户C对B1进行C1回复时，C1即为二级评论。二级点赞：指对上述二级评论的点赞行为 3注意事项上述的一级和二级行为，只关注行为的实际发起，不关注行为发起后是否取消。如，用户进行评论后是否删除，用户进行点赞后是否取消，用户发布动态后是否删帖，不会因此对行为统计的数量-1。上述的一级和二级行为，只关注最终行为的操作，不关注行为经历的过程。如用户在发布评论时，点击评论按钮和点击评论发布是两个不同的行为，我们只关注点击评论发布后的反馈，不在乎点击评论的操作。上述例子中的点击评论及点击评论发布的操作，可以单独作为一个一维的行为漏斗分析，即点击评论编辑的用户当中，约有多少比例选择了最终的评论发布，这个比例一定程度上可衡量当前评论编辑的模板是否符合用户的使用习惯。 4统计维度上述定义的一级和二级行为漏斗，明确了我们关注的行为，下一步则要明确，该用数据的什么维度来进行行为的量化反馈。最为常见的维度有pv和uv、uid和hdid。 uid：user id，用户账号唯一标识码，是某一个用户在APP当中创建的某个账号的唯一标识 hdid：用户设备号，对于某台终端设备的唯一标识区别&联系：用户可在一台设备上登录某个APP的多个账号，只要切换登录即可，此时一个hdid对应多个uid；同时，用户可在不同的设备登录某个APP的同一个账号，此时一个uid对应多个hdid。 pv：page view，页面浏览量，指某个页面被曝光的次数 uv：user view，指有多少个用户进行了某个行为的操作，人数维度_区别&联系：pv≥uv。如，一个用户在某天，通过某些入口多次进入到场景知乎的话题专区页，此时在uv的维度，当天话题专区的页面浏览量只＋1，但从pv维度则增加了多次。本质上来说，uv就是对pv在次数统计时，按照uid或hdid进行去重。 5分析角度链路分析 1.按照用户某一条完整的行为路径去进行分析。如，某入口-进入话题专区-发动态；某入口-进入话题专区-打开动态详情-评论/点赞/收藏/分享。 2.不同用户行为看待的角度可以构建不同的路径分析。同样对用户的评论行为，如例子中的某入口-进入话题专区-打开动态详情-评论，也可是某入口-进入话题专区-滑动查看动态-评论，或推荐页-滑动查看动态-评论，只要根据当期业务进展选择合适的分析链路即可。层级分析 1.对比不同层级的行为漏斗，可以对引流策略做出一些判断性的分析。如对话题冷启动的行为漏斗，一级行为漏斗反映的是用户来到话题后的直接参与行为，而二级行为漏斗反映的则是话题的某动态所引起的内容互动。 2.如果二级行为统计的数据要比一级行为的数据要出色，如用户的二级评论次数或人数比一级评论的次数或人数要多，现象的解释可以是：引流具备一定的效果，但引流来的用户，选择参与话题的模式可能出现了偏差。 3.因为大多数情况下，我们希望用户来到话题区是多进行发帖，分享内容创作，而不是关注其他用户的动态进行互动。层级的对比分析可以更加深层地评判某次引流的效果，如果一级行为数据差，二级行为数据理想，这样的策略在某种程度上是值得肯定的，当改变某个引流环节时，有可能产生目标的效果。 4.具体到本次场景知乎的话题冷启动，一期引流活动的主题海报是引导用户在该篇官方动态下进行评论，同时官方人员会对用户的疑问进行评论回复的解答。活动的形式决定了二级行为漏斗反馈的数据不会比一级行为的漏斗要差，这是合理的，只要下期活动改变主题即可；如若其引流主题目标是提升用户的一级行为，但却是二级行为数据表现更佳，就要及时反思引流策略是否出现了方向性的问题。用户价值分析这里所说的用户价值指的是单个用户所能提供的浏览次数，这能反映一个模块对用户群体的吸引程度；用相对指标，日均人次来进行用户价值的衡量，即pv/uv，解释为平均每天每名用户能给某个行为提供多少次的操作。日均人次可以反映单个用户对于某个操作的裂变程度，结合业务背景，可以理解成是某个模块吸引用户进行单次操作行为的裂变程度如何。

	漏斗量化-数据报表监控
	如下为场景知乎话题冷启动的一、二级行为漏斗的数据报表需求-uid维度：报表取数关注了行为漏斗中最关键的绝对值指标，某些操作的uv和pv，具体的转化率如何，层级分析如何，用户价值分析如何，没必要做成报表字段进行需求上提，后续用一些数据统计软件进行简单的比值计算即可。
	ps.之所以没将一些转化率的比值指标也放到报表需求，是因为一个报表需求的提出有相应的需求承接方，所有合理的需求都要经过预审和排期。一些简单的分析如果能由pm自己处理最好，这样可以极大提升自己的工作效率，这也是我觉得一个合格的pm应该会sql和数据库的基本原理的原因，因为我们离不开数据。
	当然，即使一个pm自己有相应的数据分析技能，但如果自己分析的效率要低于提需求后解决的流程，这样的需求还是应该寻求需求承接方来处理，这是合理分工的问题，让专业的人干专业的事情，别逞能。

来源

第2部分明确了该如何向需求的承接方论证所提需求的合理性和价值性，而当需求承接方被说服，选择承接我们的需求时，接下来我们就到了下一个战场，争夺资源位，也就是需求想怎么做的问题。

对于大多数APP来说，存在资源位一说。在社区模块功能里，这有可能指的是某些动态的置顶位，有可能指的是一些banner广告位的宣传，也有可能是推送的push等等。

一个社区不会只有一个话题在冷启动，也不会只有一个话题在运营，当需求承接方选择承接了你的冷启动需求后，pm需要做的事情是指定需要进行曝光的资源位，来进行下一阶段的持续引流；而哪些资源位值得关注，这就涉及到对流量入口的监控，也就是所谓的来源。

来源的定义又会和目标行为的标准有关。如，场景知乎话题冷启动，定义参与的标准是：话题区界面曝光和话题相关的动态被点击详情查看。因此，我们需要关注的来源入口可以分为两类，一类是该入口的落地页为话题区界面；第二类是该入口的落地页为某篇话题相关的动态详情。

Part.1落地到话题区

当前，美居APP的用户想要落地到场景知乎话题区的界面，可以通过如下主要入口进行转化：

1.圈子tab置顶话题位

2.圈子tab置顶/非置顶动态标签

3.IoT/日常生活/提问求助圈子动态的关联标签

4.浏览他人主页时，某动态的关联标签

如下图：

	值得关注的来源入口区别
	圈子tab动态处于置顶/非置顶状态区别置顶位属于资源位，若动态置顶与否，不影响用户通过该动态关联标签进入话题专区，则该资源位优先级不高。
	圈子类型的细分当前美居APP的发现圈子主要有三个：直通IoT，日常生活，提问求助。统计用户通过不同圈子中的动态关联标签进入话题区的数量差异，若明显，后续的引流可有意识的往某圈子的置顶位靠拢。
	社交关系的依托一个社区模块功能必定会导致用户社交关系链的沉淀，留意用户在浏览他人主页时，通过某动态的关联标签点击进入话题区的数量，可以做出话题是否具备社交裂变性的判断。若具备，引流的对象可转移为对某话题活跃的用户的个人主页，这一点在行为漏斗的建立过程中也有提及。

Part.2落地话题相关的某动态详情

当前，美居APP的用户想要浏览场景知乎话题相关的动态详情，可以通过如下主要入口进行转化：

1.首页/个人主页/热门活动banner

2.圈子tab置顶/非置顶动态

3.IoT/日常生活/提问求助圈子动态

4.浏览他人主页时，对方所发动态

如下图：

值得关注的来源入口区别和“落地到话题区”中所描述的一致。

Part.3注意事项

入口来源不漏

进行入口来源的统计分析时，要做到对所有可能的入口进行遍历分类，前期分析时将其全部列出。

入口来源不重

指的是落地后的页面行为须本质上不一致。若一致，则不需要重复统计两个入口，将第1步的入口进行逻辑意义上的去重。如，下例：

用户可通过点击左图的动态进入右图的动态详情，再通过右图的动态详情页中的动态关联标签进入话题区。而我们对于用户参与话题的来源入口分为了两类，左图到右图的跳转已经可以归到第二类入口（落地话题相关的某动态详情）；在此前提下，右图中的关联标签有必要作为第一类入口：落地页为话题专区而存在吗？显然没必要，这是重复计算的思路。因为，用户在通过右图的关联标签进入话题区界面前，他已经通过第二类入口被定义成参与话题的对象。

入口来源细分

为了更好地监控用户进行某个行为操作的来源，入口来源颗粒度的细分是有必要的。如下例：

这是提问求助圈子中的动态瀑布流形式，按现有的埋点上报规则，只能把从提问求助圈子里的任一动态被点击详情查看归类成一个入口，无法进行置顶动态、最热、最新的区分，这是埋点规则设定导致颗粒度无法进行下一步细分的缺陷，是待改进的地方。

Part.4 入口来源监控-数据报表需求

入口监控和行为漏斗的设定维度一致，取uid维度：

思考与总结

对于场景知乎话题冷启动的效果判断，用下图进行总的框架概括：

总的来说，无论是行为漏斗的建立，还是用户参与行为的来源入口统计，本质上进行数据收集时依托的都是APP的埋点。埋点的定义和上报决定了整个APP的数据分析框架可以精准到如何的颗粒度。合理的埋点设计，是我接下来会尝试思考和分享的内容。

每次设定数据指标体系，sql取数的时候都有些许感触，是场景阿侯，同时也是一个学统计的PM。

	值得关注的来源入口区别
	圈子tab动态处于置顶/非置顶状态区别置顶位属于资源位，若动态置顶与否，不影响用户通过该动态关联标签进入话题专区，则该资源位优先级不高。
	圈子类型的细分当前美居APP的发现圈子主要有三个：直通IoT，日常生活，提问求助。统计用户通过不同圈子中的动态关联标签进入话题区的数量差异，若明显，后续的引流可有意识的往某圈子的置顶位靠拢。
	社交关系的依托一个社区模块功能必定会导致用户社交关系链的沉淀，留意用户在浏览他人主页时，通过某动态的关联标签点击进入话题区的数量，可以做出话题是否具备社交裂变性的判断。若具备，引流的对象可转移为对某话题活跃的用户的个人主页，这一点在行为漏斗的建立过程中也有提及。