产品复盘:Synet2017秋招社群维系微网站
文章为作者对自己制作一个微网站的产品复盘,其中一些总结希望能够对你有所启发。
1.背景描述
1.1 社群运营
这次社群运营是当时在学校还在上课,于是决定找个线上运营实习来锻炼下自己对运营的感知力,于是做了Synet的实习生。
在运营秋招社群的同时做了一款内容型微网站,用来维系秋招社群,最后总的结果我感觉还是蛮好的吧,用户活跃和评价都是不错的,本文主要内容是复盘微网站,这款产品是我当时自己用于辅助社群运营做的,从0到1,本次主要复盘需求、设计等模块,并通过复盘展示自己过程中遇到的那些问题及之后的反思。
微网站主要设计更新模块是我们实习中间的时间,大概是1个月时间,数据等皆取自7月1日——8月10日。
微网站截图
1.2 运营方案及指标判断
1.2.1 运营方案
这里边的内容分为两块,第一块是日常运营需要的:每日早报、趣味一问、福利放送、深夜知识堂。第二块就是活动运营所需要的,包括直播网申、话题讨论等。
下图为日常运营群规则:
日常运营群规则
1.2.2 社群运营指标判断
- 总活跃用户及总发言数(用于总评)
- 周活跃用户及发言数(用于社群运营改进)
- Synet求职OPP用户数(欲购买课程的用户)
2.需求分析
2.1 社群用户需求分析
- 社群载体:微信
- 社群用户:2018届毕业生,求职目标:互联网行业、快消行业、四大等。
- 使用场景:当用户想获取有关秋招的信息时,我们日常的运营对应了四个用户情景。(待修改)
- 用户目的:获得秋招信息,增大自己秋招获得offer的概率。
- 用户秋招微信群数量的分析:我觉得这个问题可以先放在这里进行阐述,上述是用户对秋招求职社群的需求,那么最为理想的情况是1个用户使用Synet求职1个微信社群并且是消息可接受状态。但是实际上这种情况是不会发生的,一个用户往往会对应十数个秋招求职社群,而且是不同的公司并且还是处于消息不接受的状态。
我手机中的秋招群
2.2 微网站的需求建立来源
- 需求来源:用户提出由于群里交流信息过多,容易找不到曾经发过的每日一问和福利。
- 需求分析:用户需要一个快捷找群分享内容的工具。
- 附加需求:我们对这个解决方案同时也提加了 自己的需求,即能够通过该解决方案以后将活动内容同时附加在里边,并且通过该解决方案给Synet带来一定的用户转化。
拟解决方案:
①利用有道云笔记做个链接,把每天发的资料放进去,然后挂在群公告里边,让用户自取。
②制作一个多功能的微网站,然后把每天资料放进去,让用户点击领取。
两个方案都能满足上述的要求,但是第二个比第一个制作难度更大一些,但是可能整个界面会更加漂亮,于是我们进行了分析并参考KANO方法。
2.3 KANO模型判断做不做这个需求
同时参考KANO法则,我们做了判断:
KANO模型
我们的用户对这个功能一部分用户是没有会处于不开心的状态(公开表明自己需要这个内容),剩下的用户则是呈无所谓状态;那么考虑到如果有的话会给用户带来惊喜和期待,我们决定做这个功能,并且参考上述内容选择采用的功能模块。
KANO判断要做这个内容,接下来我们要分析如何去做,如何体现出我们社群的运营特色,如何在用户加入的那么多个社群中脱颖而出?
- 面临的一个重要问题:秋招社群众多,我们的不可替代性低。
- 群内容的缺陷:Synet撇给我们几个礼包然后还有一个华为网申内容,然后在我的记忆中整个秋招就没有别的内容了。(加的Utips秋招群那一段时间每天有HR、PM晚上做分享,我们的分享。。。我印象中只有一次四大的千聊分享,针对所有受众的。)
于是我们决定做点能够让用户(求职大学生)感觉我们比较专业、比较高大上的产品吧,让他们看到我们的产品第一眼会觉得这个秋招群很靠谱,会增加看秋招群的频率。(首先是看,然后才是进入活跃。)
选择方案:综上所述我们决定做一个微网站,来满足用户及我们的需求,并起到一定的用户维系的作用。
3.产品设计
3.1 核心功能是什么
提到核心功能,不得不重新探讨这个产品的诞生目的是什么?
产品是用户进行社群维系的,那么他所对应的功能就应该是社群资料的展现。
最初设计的核心功能很简单,就是:每日早报、趣味一问(行测题)等模块。
3.2 第一版demo上线
demo实际上是产品上线时候最简单的版本,直接用腾讯风铃进行开发,比较重要的就是页面布局,以及用户使用的流程,当时是一个banner然后加上4个icon做成了一个极简的页面,然后把社群运营的内容放上去,保证了整个使用流程没有问题,就邀请了一批用户进行了用户测试。
3.3 正式上线前的用户测试
产品上线之后先是小组内部进行了一次测试,测试一下基本的逻辑有没有问题,然后找了一些用户进行了一些测试,咨询了他们如何看待这个产品,产品是否能够满足他们的功能需求,其中一个用户给了一个非常赞的测试用例(一个学交互的小姐姐),然后我们根据这个测试用例及其他用户反馈继续做了这版demo的修改,仍然会准备上线在微信群里使用。
第一版测试后修改内容:
- 增加微网站功能模块,标记未暂未上线,告诉用户我们会随着活动上线而更新。
- 修改图标、文字样式,让整个微网站看起来更加整洁,使用更加高效。
- 追加功能模块区分标记,将模块分为日常信息、搞事情等模块,让用户使用更加简洁。
测试之后就是正式在社群运营中推出,每天在每日早报、趣味每日一问、福利放送、深夜知识堂这几个内容运营时附带上Synet微网站的链接。
正式发布第一天,人数UV在200+,之后几天人数维持在平均50+,呈不断下降趋势。
3.4 上线之后关于微网站利弊的深入讨论
- 讨论的原因:上线后虽然在群里边获得了用户的好评,也同时群活跃用户有所下降(第三周左右),然后组内开始讨论为什么群活跃会下降,我的两个组员他们说因为微网站所以群活跃下降,不禁引发了一场争论。
- 降低了社群活跃度:这方面她们提出的观点就是因为有了微网站,而群用户只需要每天进入微网站获取自己用的资料,而不用在群里说话了。
当然,我认为这个是一个十分荒谬的观点,之后会在反思里详细说明原因(关于社群生命周期的思考),这里先把这点列为微网站带来的缺点,这点是确实存在的,无可否认,但是造成这种现象的主要原因是社群运营内容没有任何变化,无法唤起用户来参加社群活动,这是运营端存在问题,而绝非一个微网站就会造成用户活跃大幅度下降。同时我认为微网站给我们带来的利大于弊。
有效的提升了用户的进入率:这个数字是在群绘后台观察到的,新用户发言数还是在增加,我觉得微网站主要是给用户带来一个惊喜感,然后让他们乐意来观看这个群的群内容,并且在以后来参加群活动。
结论:一方面是我们需要通过增加活动之类的内容来提升群的用户活跃度;另一方面是继续采用微网站更新一些优质内容,强化用户对群的信任感。
4.产品迭代
4.1 总的迭代思路:随着秋招时间进行迭代
4.2 迭代中踩的一些坑
在产品迭代里边可以说是踩了非常多的坑,这里总结起来应该有以下几点。
- 未咨询用户他们现阶段需求什么,并且每版产品迭代之后未做用户反馈调研。
- 功能是放上去比较简单,但是后期PGC内容更新没有跟上。
- 群里用户并不是全是互联网方向,而模块迭代总的还是很偏互联网方向更新。
4.3 迭代总结
我一共是迭代了4个版本,在这4个版本中可以看到内推和论坛都出现了两次,但是实际上第一次的内推并没有到达预期的效果,这点是因为Synet内推确实有点少,我们当时没有想把别的功能内容拿进来,然后造成了这个模块更新速度之慢,后来我感觉还不如放在首页banner职位效果好,于是把这个内容下架了;第二次上线内推是因为互联网校招已经开始了,于是将内推功能连线上牛客网等内推汇总内容,重做了内推功能,这次看相对大家满意一些,当时筛选各家公司的内推,最后发现牛客网的内推蛮不错的,就把网站链接了过去。
但是当时链接到牛客网的时候也就是说我们不在是以Synet为核心了,这点其实对微网站还是有影响的。
论坛功能尝试了两次,后来还是以失败告终,归其原因是因为用户群体体量小,目标不集中,而且很多人只是看,不会进行内容产生和回复,同时我们想聚焦秋招,第三方实际上这些功能也不是体验非常好,诸多原因叠加导致功能效果未达到预期。
总结了上边那些遇到的情况,我觉得判断一个功能该不该加需要进行以下几个判断:
- 你的用户是否对这个功能有强需求
就像我们的内推功能,我们的用户在8月份需要实习内推吗? - 你的用户体量是否能满足这个功能的需求
就好比想上一个互动功能,我们的几次论坛尝试失败主要原因是因为用户规模过少所导致的,很难够让这个功能真正的活跃起来。
5.最终效果
Synet微网站数据
Synet微网站数据
Synet秋招群数据对比
Synet秋招群数据对比
Synet秋招1群用户评价截图
6.不足与反思
6.1 摇摆不定的核心功能
- 产品的核心价值:我们这个产品的核心价值在于给用户提供秋招信息。
- 什么是核心功能:核心功能我觉得是贯串产品整个流程中都要存在的功能,并且是产品最基本、最重要的功能点,例如小睡眠的播放睡眠功能、实习僧简历投递功能。
在这个微网站中,我们的核心价值相对来说提现的比较明显,核心功能模块相对而言提现的较差,未能在几个模块中形成一个长期、高效吸引用户内容的关注模块,这是本次微网站中的缺点;前期准备用内推作为最核心的模块,但是发现内推信息不足、内推信息更新的一些问题,所以关闭了该模块,后来准备以论坛作为核心模块,但是面临UGC内容生产不足的问题。
如果再来一次,我会如何设定这个微网站的核心功能:如果在来一次的话,我会尝试以高PGC的模块(秋招求职内容的模块)来作为微网站的核心功能,在里边涉猎求职的全过程(网申—笔试—群面—单面—HR面),提供这些内容(每日更新)供大家阅读,从而提高用户的访问量,进而尝试转化OPP用户及提高用户对社群的忠诚度。
6.2 社群的生命周期曲线及维系社群活跃度的思考
社群生命周期曲线:社群的活跃度曲线和APP是不相同的,如果要做对比的话他们两个可能是完全相反的生命周期曲线。
社群是从非常活跃—比较活跃—非常不活跃的状态(在没有人进行维系的情况下),那么社群负责人要做的是让社群尽量处在一个比较活跃的状态。
附图:生命周期曲线
社群生命周期曲线
注:我们接受社群是在活跃互动期。
如何提升社群活跃度呢?
我理解中如果提高社团活跃度可以从以下几方面下手:
- 发觉部分优质用户形成KOL,让他们来进行话题引导。
- 给社群里边的用户一个统一的目标:秋招收获offer、学好一门技术。
- 发起社群的活动:比如一起讨论一个话题(面试中的那些坑)、搞笑PS是怎么练成的。发起的活动要锲合社群用户的统一目标。
6.3 数据是一个产品中必不可缺少的一点
这个产品中存在的数据不足的问题:
①没有固定的入口,所以每天的用户访问量实际上是会随着群日常内容进入的,我们没有办法来判断何时用户进入数量多少(9:00、15:00、19:00、21:00,共四次内容会携带链接,这是固定的次数。腾讯风铃的数据更新是1天1更新。)这一点没有办法根据用户进入人数区别来进行链接推送时间的更改。
②产品主页无埋点:因为没有埋点,数据只有整个微网站内部的UV、PV,没有具体的用户访问路径(进入微网站——论坛——产品——留言,这种路径无法形成)
③无法判断用户次日是否访问:在上线一些新模块的时候,连续两天用户访问人数都是100,但是无法判断这100个用户两天是否存在重复。
数据在产品中的作用:
①应用于判断1个功能在用户眼中的优先级:我们的微网站刚开始的第一版是由四个模块(每日早报、每日一问、深夜福利、知识课堂),用户对四个模块的需求肯定是不同的,同时我们人力维护每个模块的成本也不一样,所以如果有数据参考,可以简化用户访问最少的模块(比如每日早报),把用户访问最多的模块(比如知识课堂)做细化。
②做产品设计的参考:有的时候在做产品设计是时候会遇到一些问题:
你为什么这样设计整个流程,他符合我们用户的使用习惯吗?
b.这个功能有没有必要现在做出来,我们的用户需要这个功能吗?
当遇到这些问题的时候,就要用数据做出判断了。
在微网站中遇到的就是刚开始为什么要加内推模块,这点是因为刚开始的问卷调查来判断需要做,但是后来里边的内容与用户预期有所误差。
- 用户理解的内推:秋招求职内推,最好是top几企业
- 我们理解的内推:实习内推+秋招内推
所以在使用数据参考时候也要注意判断用户是需求到底和我们理解的是不是一样。
同时在暑期产品实习的时候,遇到过运营提新老客需求,当时需要判断到底做不做这个功能(后台人力有限),当时根
据运营往次的活动数据来看,涉及用户群体比较少(用户量的1%-3%,根据以往活动发券/领券人数及总用户数来进行计算,同时平台是人数的高速增长期),区分新老客的意义并不大,不如直接做代金券,所以把这个功能砍掉,提前了代金券功能。
7.关于团队的一些思考
社群运营我们一共是3个人,但是微网站实际的制作者只有我1个人,这次尝试更加让我感觉到一个好的团队的重要性。
闻道有先后,术业有专攻。每个人所选择的职位、涉猎的内容模块都不会完全相同,这也就是说明你的团队成员会有你所不了的内容,比如如何做好一个社群运营活动、如何提高用户活跃度、如何引流让用户进入。
一个好的团队往往能够事半功倍。这点应该是在整个过程中体会最深的,我们的团队成员不算bad,也不能算特别nice吧,在设计微网站考虑到如何跟用户沟通的时候,她们单纯的不考虑社群活跃周期而只考虑微网站可能存在降低活跃度的问题,就这个问题进行了非常复杂的争论,而不是去分析原因是为什么。
同时在实际的社群运营中,每个人分工的模块是不一样的,其中有一个女生负责了每日一问模块,每天就是单纯的发每日一问,然后还漏发答案,然后问我们为什么没有用户活跃度。
我们团队不算是好的团队,整个秋招群的运营也没有达到比较完美的状态;当时在北京一家公司实习,和boss聊过一个好的团队,好的团队更加有效率,做事更加靠谱。我们线上实习一个人负责写1周的复盘报告,她通常是在第二周周末写完第一周复盘报告,然后这个报告连参考价值都没有。
在大学里边,包括实习、社团、自组团伙,我经历过不少团队,我觉得好的团队都是拥有强的自驱力的,大家会对自己的问题负责,不断强化自己的技能、知识面。
最近在和千师百业的小伙伴一起做项目,感觉这个团队还是比较棒的,首先效率和质量都是非常不错的,大家自驱力比较强,都是想做事情的人,最近还在继续磨合之中,每个人都会定具体负责的每一块,这样整个团队办事的速度也能提升不少。
如何搭建一个不错的团队?
- 团队不在人数在于精
- 术业有专攻,每个人都有自己的强项
- 有着共同的一个目标
- 找准你自己在团队的定位
- 相互磨合,看团队是否合适
本文由 @一个神奇的逗比 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自PEXELS,基于CC0协议
想请教一个关于数据应用方面的问题:
6.3中的“①应用于判断1个功能在用户眼中的优先级”里面提到对于访问量小的模块简化,访问量大的模块细化,这个具体是如何细化如何简化呢?
我们的模块是内容型模块,我举两个模块的例子.
①日报:点击日报——选择日报日期——阅读 这是一个用户对日报的阅读流程
②深夜福利:点击深夜福利——阅读
因为日报与日期有关,所以我们阅读步骤多了一步,但是用户实际上对这项是不敢兴趣的,发现他们最多阅读当天日报,我们出人力来更新、维护这部分意义不大,所以就缩减为点击日报——阅读今日日报。
深夜福利用户点击比较多,里边内容包括各个行业(互联网、快消),因为用户点击多,所以我们准备细化这一项。
大概我对6.3的1是这样理解的。 😉
好滴 谢谢