开源社区运营经验分享（三）搭建用户体系之前的5个问题青山绿水下一句

回顾一下，开源社区运营经验分享已经完成了两篇。《开源社区运营经验分享（一）》讲了为什么要做开源社区，做社区的价值是什么。《开源社区运营经验分享（二）》讲了从0到1 运营开源社区的策略，包括梳理用户画像、完成社区定位、用户精细化运营（用户分层、用户分类、用户分阶段）。

其中，分阶段运营用户的本质就是用户生命周期管理。此前已经单独就「用户生命周期管理」写了一篇。

核心思想都浓缩在下面这张图↓

随着用户不断深入了解、使用和感受产品，加深与产品的关联度，用户身份也是在不断变化的，比如导入期对应新用户，成长对应普通用户。

之所以这么划分，是为了更加清楚用户在不同阶段的核心需求。在这个基础，运营利用已有的资源，引导用户进入或者更持久的停留在「运营期望的阶段和状态」，进一步提高LT和Value，完成产品从用户价值到商业价值的统一。

如《产品生命周期VS用户生命价值搞不清楚？6张图带你厘清基础概念》所提，为了达成这一目标，我们可用的手段包括但不限于「用户成长体系」和「用户激励体系」。

而不管是成长体系还是激励体系，都要先思考下面几个问题：

问题1：哪些用户行为是我们希望看到的？

问题2：判断用户行为是否值得被激励的标准是什么？

问题3：如何判断这些行为之间的权重？

问题4：用户为何会按照我们的预期行动？我们能提供什么价值？

问题5：这个价值要怎么给，给多少，多久给一次，给的形式……整个玩法要如何设计，才能更好地刺激用户完成既定行为？

答案1：

对于一个开源技术社区来说，我认为可以1）技术使用深度2）社区交互深度两个角度去思考。用户来到社区的初衷是技术互动，和同行交流并解决技术问题。一个人只要他提出的问题能够得到及时有效的回复，他就能留下来。如果他还能解决别人的问题，得到来自其他用户甚至是社区官方的认可，他就会更有动力在社区活跃。但如果只停留在技术交流，那么就低估了社区尤其是开源社区的价值空间。

PingCAP 联合创始人&CTO黄东旭在采访中说到，对于社区运营者来说，最关键的任务不是让沉默者更多或更深度地使用，而是让他们和网络中的其他用户建立更多的连接。将网络效应从使用者的网络效应转移到基于信仰的网络效应，将社区中心从开源公司内部转移到外部以获得更大的势能。

翻译过来就是，技术层面的交流，只能算是物理反应。当用户之间的连接程度超越技术转向共同信仰或者价值观的时候，社区才开始有了化学反应。这个时候社区的势能呈指数级增长，社区成员不仅可以自治，还能以共同体的身份对外发声与合作。

1）技术使用深度具体来说，包括但不限于使用技术产品、提bug、提issue、提PR等；

2）社区交互深度具体来说，包括但不限于参与官方内容转赞评，帮助社区其他用户解决技术问题，参与社区活动，在社区进行主题分享等。

答案2：

一个用户行为是否值得被激励的标准，一是用户行动以后会给社区好评吗，也就是说用户自己觉得舒服吗，有没有被满足；二是用户行动以后对社区有没有正外部性，也就是其他用户有没有因此受益。因为符合这两个标准的才能让用户玩得爽，以及社区健康可持续地发展。不能说，这个用户爽了，其他用户都跑了。虽然我们经常说运营用户就是伺候上帝，但问题是社区不只一个“上帝”，更何况上帝之间的行为是会相互影响的。

答案3：

还是上面两条标准，优先考虑社区整体的健康发展。

其余行为，要结合投入成本来看。一般来说，用户投入越重的行为，我们越鼓励。我们也很希望每个用户都能成为contributor，但很可惜达不到。对此大家也可以通过「官方投入」去观察产品和社区到底鼓励用户做什么。从某种程度来说，这也是一次交易。

答案4：

用户愿意听你的、按照你说的做，是因为他愿意这么做来交换你手中的资源。并不是因为你牛逼。

而我们能够提供的资源或者说价值一般包括以下四种：

1）物质：现金激励，购物卡，周边，苹果产品等硬通货；

2）内容：技术文档，经典QA，行业资讯，白皮书等；

3）服务：一对一技术专家答疑，与权威专家交流机会，企业参观；

4）荣誉：社区认证讲师、技术布道者等荣誉；

这里提醒一下，还是要学会通过荣誉激励用户去完成预期行为。

大多数时候，钱都是不够的，我还没有听过谁的预算是花不完的。同时，人为了物质激励去做事是会疲乏且滥竽充数来薅羊毛的，只有内在动机才会让一个人真正优质高量输出（比如我现在一毛钱都没有，但心甘情愿在这里写内容）。

答案5：

这个比较复杂，需要具体情况具体分析。由于工作内容暂时不便公开，所以细节也没法说。但是有些原则可以和大家分享。

首先是有多大金刚钻，揽多少瓷器活儿。

一定要结合现有资源去设计整个体系，不要空头支票。钱不够的时候，一定一定要取舍，做好重点，而不是均摊费用！

其次是设计用户行为时，要时刻考虑降低用户行动成本，不改变用户本来的行为路径，除非真的有必要。

比如说一个技术用户进来，在部署安装的过程中大概率会遇到问题，在他解决完以后，你引导他写一个注意事项文档，这是OK的。但你不要妄想一点点诱惑可以让用户专门为你创造一个东西。再比如，用户习惯了在GitHub上面提issue，用Markdown写作，你就不要非得要求别人和你一样用飞书文档交流。

最后要注意结合用户自然行为的特征（行动极限，行动频率等）去设计你的目标。

比如说，一般情况下一个用户每天也就是下午摸鱼的时候能够来给你当志愿者维护社区秩序，答上那么七八个问题，你就不要设计成每日答疑数量满50个可以获得XXX。人又不傻，放在面前的胡萝卜才去够，放太远了就直接放弃掉了。你设置奖励的目的是让用户完成从现状到理想的跃迁，不是「我不玩了」或者干脆「跳他个粉身碎骨」。

具体的用户激励体系和用户成长体系搭建，可以自行搜索。由于这方面的内容很多，所以不重复造轮子了。