本篇文章将围绕群组(社群)的管理和发展,说说楼主的一些体会和总结。
湿货:社群的那些事
One:什么是(社)群
社群,自古便有“人以类聚,物以群分”之说,更有“三个以上的禽兽相聚而成的集体”之释意。
社群,简单来说即是一群人的集合,他们有明显且共同的社交属性(共同爱好,共同偶像抑或共同的家乡等等)。
著名人类学家,英国牛津大学的罗宾·邓巴(Robin Dunbar)教授提出过“150定律”, 即著名的“邓巴数字”。邓巴根据猿猴的智力与社交网络推断出:人类智力将允许人类拥有稳定社交网络的人数是148人,四舍五入大约是150人。而精确交往深入跟踪交往的人数为20人左右。该定律认为,这是由人的大脑新皮层的应对能力决定的。
照这么说来,现在很多社群(特指基于IM产品)动辄数百人,岂不是造成信息过载?的确是的,楼主曾经对比过,一个二三十人的私密小群每天的信息量并不比一个两三百人的大群少多少,至少量级上面差不了太多。前者可以轻松每几百条,后者顶多就千来条。
再计算下来,人均信息量更是非常接近。参考下面曲线图
从上面的定性分析曲线图可以看出,社群活跃与邓巴数的关系。过量的人和信息,低效的传播,对于自己需求的信息获取成本会变得越来越高。
那是不是社群就一定要小为好?
No,肯定是越大越壮才给力呢(别想歪)。
上面说到的信息过载更多是体现在以IM为存在基础的社群中,各类微信群,QQ群,微博群等。同步交互便捷高效,副作用也是过于直接,用户对信息没有回避的地方。
对于异步交互的BBS、论坛等形式的社群,则没有太多这方面的烦恼。但是异步交互太慢了,不利已社群成员的日常交流。一个群一个论坛?似乎可以,但是操作繁琐,加重用户成本。
放眼现在的各种社群,普遍都是以IM群为基础,那好办,内嵌一个异步交互的插件,满足信息分流和扩展功能的需求,或者整个产品依旧是IM基础,只不过在群IM的基础上有更多集成功能,帮助用户分流和过滤信息,在不退群的前提下,有较好的社交体验,同步和异步结合。岂不美哉,于是脑补了一下场景原型图,以某信为素材,SDK的形式内嵌到IM产品。悬浮在IM场景中,H5web为基础,实现小范围的信息分类和异步交互,当然PC端也可以访问这个社群专属的H5,实现多端整合。
(毕竟天真,看官莫喷)
社群运营的一些总结
One:三观要端正!
任何群组都有一个基本的主题方向,群组的运营者要积极引导成员围绕该主题展开社交活动。当然这不是说百分比只能谈论一个方向的东西,而是这个主题一定要是这个群组一切社交活动的最重要部分,否则容易造成核心成员(往往输出价值较高的信息)流失,群组内容进一步走歪,渐渐整个群彻底变成吹水群或者死群。