如何通过小程序和微信社*来构建产品运营*？

本文详细阐述如何通过小程序和微信社*来构建一套比较轻型的产品运营*，用于稳定提升用户量，用户日活和用户转化。

背景介绍
目前在一个在线英语培训团队做产品经理去年在来这个团队之前，团队的线上只能做通过微信公众号发一些推文和社*活动来吸引流量，作为一个几百人的公司，这点和一些小团队和个人公众号没什么区别。

正逢小程序在2017年受到微信的大力扶持，也为了之前一起从前公司来的开发团队学习一些新东西。在来这个团队后不久，就制定了相应的小程序开发计划。希望借此能拉开身后竞争对手的，提升我们在用户心中的软实力。

经过这将近一年的开发，陆陆续续的上线了三款不同类型的小程序，分别用于：

口语学习和辅助教学任务；
辅助运营活动的报名和日常打卡；
听力学习。
这几个款小程序上线后，在我们的用户*体内还是取得了相当的好评，达到了初项目的预想效果。不过，近因为一些个人原因近准备换工作了。为了能让之前的工作成果持续发光发热，通过解决了一系列的实际问题后，设计出这套小程序的产品运营*。

解决问题
做过开发的同学都知道，好的架构直接设计出来的，而是迭代出来的。同样的，这套产品运营*也是在近解决一系列的*需求，参与并设计社*运营，结合当前小程序的特点所迭代出来的。

其中主要是依次解决了以下几个问题：

如何弥补小程序的短板？
如何持续为为*人员提供合适的潜在用户？
如何提高用户的留存时长？
第一个问题：如何弥补小程序的短板？
做了近一年的小程序产品，虽然享受到了很多小程序带来的实惠，但它的缺点和限制也同样突出，主要集中在以下：

以上的缺点可能在相当长的一段时间内都不会解决，毕竟小程序从一开始就不是什么流量红利，微信将小程序是作为微信App丰富功能的手段罢了，而稍微多做一些对开发团队有利一点的事情都会有很多限制。仅从开发与产品角度来说，很多时候会觉得宁愿继续做微信公众号的WebApp。

直到近因为团队人手不足，由原来的运营观察，到设计运营活动，后直接参与到实际的社*运营中。经过一段时间，也对于社*运营也有了一些新的了解和体会。

对比一下上下两表，两者之间的优点与缺点大多都能够互补，比如：

社*中使用和推广小程序，能解决用户无法触达的问题；
小程序可以丰富社*体验，提高活动质量；
小程序可以记录下社*活动的关键部分，并对之后的持续展示露出有帮助；
社*可以通过小程序的持续内容更新来低成本维护；
在这之后，我调整了小程序的运营策略，将小程序的使用为主，推荐用户参加社*活动的运营为辅助，转变成活动社*为主，小程序在社*中的使用为辅助，这样才能更好的完成两者的互补与结合。

虽然实际操作起来还是差不多的，但主要改变的是大家的思想方式，及对小程序的认识。

第二个问题：如何持续为为*人员提供合适的潜在用户？
据我所了解：目前国内所有的在线教育公司，其获客成本会随着*单位价上升而上升。我们也不例外，所以近给我制定的KPI就是要能够给*同事提供足够多的Sales Leads（潜在用户）。之前这些潜在用户仅来源于线上线下活动，长期社*运营，用户自己看了广告推文后联系我们。

之前团队做活动，会让用户在活动开始之前填写像户口调查一样的问卷，每次活动也只能说是做一次收割一次，跟品牌越做越大，获取例子省时省力不沾边。而做长线社*本身就需要花很大的精力，而从大量的社*中获取用户，很多时候只能靠运气，就是几个用户刚好在运*里讨论到了你能够*的产品时，恰好有*人员出现又能解决。

这些都都跟持续、高效、省力完成挂不上关系，至少离我的理想方案差得太远，但近就通过小程序将这个问题迎刃而解。

我们一直有个单词对赌的社*活动，每月能够举办两到三期，每期都有几百名新用户，没有限制用户背单词的形式和内容，但需要把当天背的单词打卡截图发送到我们的小卡小程序里，后会根据用户的打卡情况来报名费。

很长一段时间，我们都没发现这个活动和用户有什么价值，运营也是是为了做而做，每次在打卡活动结束后，在*里打打自己的广告，后在越来越多其它竞品的广告出现的时候，就把*解散了。直到某天，新来的同事在看数据的时候，发现其实每期目标用户的身份就已经写在这些打卡的照片上了。

这一点其实怪我自己，当初做这个打卡小程序的主要目的就是为了筛选用户。无论是用户在小程序中的参与行为，还是其在小程序内提交的各种数据，都可以很快的对新用户进行筛分。

所以在想到这点后，第二个问题其实也就不是问题了，只要做更多能够吸引所有人眼球的活动就好，然后在活动中，通过小程序逐步完成用户的筛分。

第三个问题：如何提高用户的留存时长？
这里先举两个的例子：

要从街上找一*喜欢看电影的人容易，还是找喜欢看推理剧的容易？
同样，是找喜欢体育的人容易，还是找喜欢打台球的人容易？
假如，我们可以选择不浪费任何进来的流量，只要你喜欢体育，我可以组织各种各样的比赛来满足你，直到有一天你发现你喜欢的女孩也打桌球。同样，我也可以让你喜欢上我们推荐的各种各样的电影，然后终有一天你会向你喜欢的推理剧的朋友推荐我们。

这一切，需要时间来浇灌等待用户发芽，需要肥料来给养让用户更喜欢我们的产品。

这里就继续说说近的运营工作，我自己是有一个运营用的微信号的，主要是添加用户，解答他们在使用小程序中的问题。在活动期间，用户会比较积极的把我们的活动朋友圈。但在活动结束之后，因为没有新的内容来填充，不出半个月，我的朋友圈经常就会变成下图的样子，全部都是竞品活动在刷屏，甚至有些会直接进入到这些社*当中。

为了避免用户口碑的进一步下滑，后多只能将*解散，白白浪费活动进来的流量，对于我们这种不太擅长做流量的团队来说，太可惜、太浪费。

随着新的小程序发布和之前运营方案的调整，所以完整的跟踪了一个系列活动，分析这两次活动数据的时候，也发现了答案。下图将截取两次活动的部分数据。

运营过程：

第一次活动总共有177名付费用户，这些用户全部集中在社*A；
活动中每天都需要使用小程序来完成相应的学习，培养了良好的用户习惯；
活动结束后，小程序内的学习内容继续保持更新，且因为Bug还需要时间修正，所以只在社*A内进行内容更新的发布，除此之外并没有花费太多的人力。
在经过上述三周以上的社*运营，第二次活动时，给出了以下的数据：

原活动社*A，在小程序的内的活跃人数为70人（参加第二次活动的70加上未参加的10人），活跃比例在47%，完全填补之前社*运营的活跃人数数据的空缺；
没有参加第二次活动的用户，依旧有87人在原活动社*A中，且有相当一部分在继续使用小程序，这部分用户后续可以随时激活；
第一次活动中有60名用户通过第二次活动报名，进入到社*B，相当于第一次活动的续报率达到34%，对比之前没有小程序时，有近10个百分点的增长；
而只有30名用户从两个活动社*中消失，排除部分用户改昵称和昵称无法匹配，整体用户的流失率应该是低于15%的。

说实话，如果团队能在这个活动动上更用心，运营的流程更细致，小程序没有一开始人人都遇到Bug这样的开局，相信这个数据和结果还能更好。但总得来说，这个数据对比过去也还是有了明显的增长，而这也将是用户能够长期停留在社*和产品运营*中的保证。

*搭建
分解和整理以上的思考内容，主要抽象出以下几个主要对象：

短期活动；
活动社*；
小程序；
社*矩阵；
用户管理；
运营指数。
根据它们之间的关系，整个小程序的产品运营*如下图所示：

短期活动
选择短期活动作为整个*的入口，是因为公司运营团队之前一直都在做的事情，如果需要推行这套*，原有的工作尽量保持不变。

而且短期活动本身也有很多的优点：

短期活动让新用户的参与压力，团队的持续运营压力都比较小；
短期活动每次结束后，能够及时复盘，也能不断改进活动形式，优化活动质量；
持续的输出高价值的内容也不现实，需要在非活动期，给团队预留相应的储备时间；
如果活动不能经常有新鲜内容，对老用户也会丧失吸引力，需要隔一段时间有新的活动来激活用户。
除此之外，通过宣传活动可以规避一些小程序的审核雷区，比如：常用的裂变机制、积赞砍价、提高用户参与度的激励机制，别看别人做得欢，但你做的时候未必让你审核通过。

活动社*
用户通过活动进入到活动社中之后，这是一个双方互相构建信任的阶段。优质的运营服务，活动内容，小程序体验都将会为之后的*打下良好的基本。

而在这一阶段，小程序对于社*的依赖比较大，需要持续的督促用户来使用小程序。

一是让用户尽快的熟悉小程序的使用，培养他们的使用习惯；
二是从用户进入到这套*开始起，尽量的使用小程序将会用户的行为有迹可寻。
对于社*运营而言，小程序丰富了社*运营内容，包括小程序内经常出现的Bug。

解决Bug比较比较有意思的是，团队因为没有QA人员，外加研发对于小程序的经验不足，我们的小程序即便是在发布时，也会有相当多的Bug。虽然在活动过程中这一点虽然非常让我不爽，但却变相创造了相当多的和用户沟通机会；并且能够及时为出现Bug的用户进行处理，处理得及时得当，用户的好感度和信任度UP。

小程序
小程序在整体*中扮演的是骨架作用，将*中的各个部分串联嫁接在一起。对于用户是提供服务，解决用户需求；对于团队而言，是个默默的记录仪，而不是个筛分工具。

作为筛选工具的小程序，简单粗爆的作法当然是下面左边这种，一上来就问用户的户口，迎面扑来了一种饥渴感。

上右边是我们其中一款学习型小程序的使用数据，截取的时候已经是长线运营时期，每天用户需要在十几页面中停留，总计从高峰的人均1400秒到现在的700秒左右。相信有经验的同学，会有足够的时间、空间、数据积累来完善用户画像，识别用户身份和价值。

具体如何做，前文已经给出了一个案例。

社*矩阵
前面的图中，由活动社*到社*矩阵我用沉淀这个词，主要有三层意思：

一层，活动用户沉淀，顾名思义；
二层，系列活动社*沉淀，是系列活动本身每次都会创建新的社*，形成一个同系列的主题矩阵；
三层，是不同的活动主题，本身会构成不同系列的社*矩阵。
这里就根据大家各自的团队实际情况，是做专一点还是做宽一点，选择做两层还是做三层了。

社*矩阵在有小程序的加持下，维持住用户并不困难：

社*因为有小程序的存在，给了社*一个继续运营的理由。用户会觉得你每天把更新的内容放在社*里是之前活动的一种理所应当的延续，也是非常认真负责的表现；
用户因为有小程序的存在，有留在社*的理由。只要用户初参与活动的目的还在，当用户遇到问题的时候，用户需要有个提问的出口。这时候，因为我们的持续运营，让这个社*看上去是个活的，有人冒泡的，往往将会成为用户的第一选择；
如果你有多个不同的主题社*，能够把握住用户的机会也会更大一些。
用户管理
在这套*之前，用户仅仅只是一个微信号，社*之间也是没有联系的，管理后台无法获取用户的微信，如果只能通过用户昵称来定位也会变得难以琢磨，具体可以看下图（我们粉丝自己建立的熟人小团体），以上种种都会带来大量统计上、管理上的困难。

所以为了构建相应的用户管理，主要在小程序的管理端，会有以下几个工作：

学号*，每一个进入到*内的用户，我们都生成一个由小到大的五位ID，跟用户在开发者平台下的UnionID一对一映射。这样我们可以从几十个社*，几万名用户当中，快速的找出我们需要的用户。
用户画像，通过在小程序中设计的各种标签系统（而不是简单粗爆的问卷表单），用户会打上越来越多的标记，这样无论流量多大，我们总能有序有效的对用户进行筛选
用户记录，服务一名用户经常需要多个同事来协同完成，在此基础上建立的用户服务记录也是很件很自然的事情。比如：查询用户的学习记录来提醒用户及时学习，之前的服务情况来判断用户价值等。
权限管理，社*中经常打广告的用户也会我们打上相应的标签，再也无法报名新活动，需要改学号的社*也会被及时清除。
这些都让整体社*的规模效应得到充分发挥。

运营指数
如果想不断提升品牌的口碑，不断的修正和调整活动是非常有必要的。问卷调查虽然可以了解一部分用户的想法，但更为真实的则是用户自己用户脚投票的行为。

之前文中也提到，活动需要不断的改进，那么在这套*下的活动将会提供更为强大的数据支持。这在一两年前是比较难做到的，但现在有了这套产品运营*，通过前面用户的数据积累，将给我们更多的社*运营和活动运营的观察维度。

新的渠道借给的流量精准度；
各期活动的报名具体人数；
用户在整体*内的停留时间，活跃周期，活跃的时间点；
活动之间的人员留存比，人员是由哪些之前的活动构成的；
整个*下每天的新增和日活；
…
通过观察和分析这些数据，对于整体*的调整都是非常有帮助的。

下图中再以一个系列社*活动做案例分析，其中的原始数据已经调整，X、Y、Z分别是三种不同的系列活动；X1、X2、X3分为这这个系列活动的第1期、第2期和第3期，其它的代玛依次类推。

首先我们看看左图，柱状图分别显示了当前报名的用户来自上一次的用户数量，按用户在本系列中第一次出现的时间进行统计分类。

先分析出以下现象和结论：

X系列对新用户的吸引力很强，对老用户吸引力不足。适合做拉新和对外宣传，对老用户吸引能力有限。

再看中间的图，分别显示了X3这次活动用户在整个*中的来源，即用户在*中早出现的活动。

简单分析可以观察到以下现象和结论：

160名新用户，170名在*内用户，且X3活动对Y系列的用户有相当吸引力。可以对之前的结论修正一下，有相当的拉新能力，活跃老用户的能力也不错。

再看后右边的图，分别显示了X3活动结束后，用户在*内后一次出现的活动。

综合上面的所有数据，得出以下几点：

对于参加过X系列的用户，Z系列比Y系列的吸引力度较大。

虽然这还只是其中的一小部分，但相信你已经能够发现对促进活动的安排，配置都已经具有相当的指导意义。更多具体的分析，有时间可以开另一篇文章专门讲解相应的数据。

举个例子
为了避免前面的内容太干或太水不便于大家理解，就临时想了一个以亲子教育为主的团队来做个案例做为补充。

团队预先构建以下小程序社*矩阵：

近团队想推广自己的大学生在线数学辅导，就可以通过以下分层步骤从中筛选：

从奥数学习的社*中筛选出出错率比较高的学生；
再根据其是否在亲子阅读这种人人都能参加（假设）的活动中，判断用户的付费能力，对用户进行排序；
得出来的名单再交由*和运营同学直接通过社*添加相应家长的微信来做进一步了解
如此，无论是新业务，还是旧业务，通过小程序构建的完整用户画像和用户始终在线的社*矩阵，都能够快速的完成目标。

结语
后想说的是，有同学可能会觉得这可能没什么了不起，就是小程序+社*运营而已，没有大数据分析，没有人工智能的自动应答，没有区块链。但对于公司和团队来说，脚踏实地地选择适合自己方案能够解决问题才是重要的。

这种脚踏实地的难点就在于：

如何有效利用现有的团队资源和人力做出合理的方案，而不是去等待优解；
大化的整合团队的力量，将团队中不同项目组的特长发挥出来；
即要能满足当前需求，也要考虑未来的长远发展。
为了能够保证这一*能够让团队能够稳定和持续的使用一段时间，就把这次的整体方案总结发上来和大家分享讨论，希望有人能批评指正。