在上篇“”虽然没有申请认证，但还是可以拿到小程序ID和小程序密钥的。有了小程序ID和小程序密钥的，我们就可以在手机上查看调试微信小程序了。

要填写注册时拿到小程序ID

第二次创建项目，发现项目目录下不会以项目名称自动创建同名的目录，这一点很不好。

创建成功后，点击左侧的项目，右侧会发现，在“开发者工具下载安装及创建项目功能预览”中创建的项目没有AppID所以预览和上传都不可用，

而现在都变成可用的了。点击预览就会自动上传，然后显示一个二维码，就可以在手机上用微信扫描二维码查看调试微信小程序了。

扫描之后首先显示一个加载的动画，需要等待两三秒，感觉还不如打开网页快。

注意：右下角有个“vConsole”的按钮，是通过右上角的菜单，开户调试后才显示的。

点击“vConsole”按钮后，会看到下图的调试信息了。

感觉一个最基本的示例加载的速度还不如一个网页加载的速度快，可能是需要登录验证获取用户信息的原因？

等到真正上线再看体验如何吧。

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

　　口语学习和辅助教学任务；

　　辅助运营活动的报名和日常打卡；

　　这几个款小程序上线后，在我们的用户群体内还是取得了相当的好评，达到了最初项目的预想效果。

　　不过，最近因为一些个人原因最近准备换工作了；为了能让之前的工作成果持续发光发热，通过解决了一系列的实际问题后，设计出这套小程序的产品运营体系。

　　做过开发的同学都知道，好的架构直接设计出来的，而是迭代出来的。

　　同样的，这套产品运营体系也是在最近解决一系列的销售需求，参与并设计社群运营，结合当前小程序的特点所迭代出来的。

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

　　如何弥补小程序的短板？

　　如何持续为为销售人员提供合适的潜在用户？

　　如何提高用户的留存时长？

　　如何弥补小程序的短板？

　　做了近一年的小程序产品，虽然享受到了很多小程序带来的实惠，但它的缺点和限制也同样突出，主要集中在以下：

　　以上的缺点可能在相当长的一段时间内都不会解决，毕竟小程序从一开始就不是什么流量红利，微信将小程序是作为微信App丰富功能的手段罢了，而稍微多做一些对开发团队有利一点的事情都会有很多限制。

　　仅从开发与产品角度来说，很多时候会觉得宁愿继续做微信公众号的WebApp。

　　直到最近因为团队人手不足，由原来的运营观察，到设计运营活动，最后直接参与到实际的社群运营中。

　　经过一段时间，也对于社群运营也有了一些新的了解和体会。

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

　　社群中使用和推广小程序，能解决用户无法触达的问题；

　　小程序可以丰富社群体验，提高活动质量；

　　小程序可以记录下社群活动的关键部分，并对之后的持续展示露出有帮助；

　　社群可以通过小程序的持续内容更新来低成本维护；

　　在这之后，我调整了小程序的运营策略，将小程序的使用为主，推荐用户参加社群活动的运营为辅助，转变成活动社群为主，小程序在社群中的使用为辅助，这样才能更好的完成两者的互补与结合。

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

　　如何持续为为销售人员提供合适的潜在用户？

　　据我所了解：目前国内所有的在线教育公司，其获客成本会随着销售单位价上升而上升。

　　我们也不例外，所以最近给我制定的KPI就是要能够给销售同事提供足够多的Sales Leads（潜在用户）。

　　之前这些潜在用户仅来源于线上线下活动，长期社群运营，用户自己看了广告推文后联系我们。

　　之前团队做活动，会让用户在活动开始之前填写像户口调查一样的问卷，每次活动也只能说是做一次收割一次，跟品牌越做越大，获取例子省时省力不沾边。

　　而做长线社群本身就需要花很大的精力，而从大量的社群中获取用户，很多时候只能靠运气；就是几个用户刚好在运群里讨论到了你能够出售的产品时，恰好有销售人员出现又能解决。

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

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

　　很长一段时间，我们都没发现这个活动和用户有什么价值，运营也是是为了做而做，每次在打卡活动结束后，在群里打打自己的广告，最后在越来越多其它竞品的广告出现的时候，就把群解散了。

　　直到某天，新来的同事在看数据的时候，发现其实每期目标用户的身份就已经写在这些打卡的照片上了。

　　这一点其实怪我自己，当初做这个打卡小程序的主要目的就是为了筛选用户。

　　无论是用户在小程序中的参与行为，还是其在小程序内提交的各种数据，都可以很快的对新用户进行筛分。

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

　　如何提高用户的留存时长？

　　这里先举两个的例子：

　　要从街上找一群喜欢看电影的人容易，还是找喜欢看推理剧的容易？

　　同样，是找喜欢体育的人容易，还是找喜欢打台球的人容易？

　　假如，我们可以选择不浪费任何进来的流量，只要你喜欢体育，我可以组织各种各样的比赛来满足你，直到有一天你发现你喜欢的女孩也打桌球。

　　同样，我也可以让你喜欢上我们推荐的各种各样的电影，然后终有一天你会向你喜欢的推理剧的朋友推荐我们。

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

　　这里就继续说说最近的运营工作，我自己是有一个运营用的微信号的，主要是添加用户，解答他们在使用小程序中的问题。

　　在活动期间，用户会比较积极的把我们的活动分享到朋友圈。

　　但在活动结束之后，因为没有新的内容来填充，不出半个月，我的朋友圈经常就会变成下图的样子，全部都是竞品活动在刷屏，甚至有些会直接进入到这些社群当中。

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

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

　　下图将截取两次活动的部分数据：

　　第一次活动总共有177名付费用户，这些用户全部集中在社群A；

　　活动中每天都需要使用小程序来完成相应的学习，培养了良好的用户习惯；

　　活动结束后，小程序内的学习内容继续保持更新，且因为Bug还需要时间修正，所以只在社群A内进行内容更新的发布，除此之外并没有花费太多的人力。

　　在经过上述三周以上的社群运营，第二次活动时，给出了以下的数据：

　　原活动社群A，在小程序的内的活跃人数为70人（参加第二次活动的70加上未参加的10人），活跃比例在47%，完全填补之前社群运营的活跃人数数据的空缺；

　　没有参加第二次活动的用户，依旧有87人在原活动社群A中，且有相当一部分在继续使用小程序，这部分用户后续可以随时激活；

　　第一次活动中有60名用户通过第二次活动报名，进入到社群B，相当于第一次活动的续报率达到34%，对比之前没有小程序时，有近10个百分点的增长；

　　而只有30名用户从两个活动社群中消失，排除部分用户改昵称和昵称无法匹配，整体用户的流失率应该是低于15%的。

　　说实话，如果团队能在这个活动动上更用心，运营的流程更细致，小程序没有一开始人人都遇到Bug这样的开局，相信这个数据和结果还能更好。

　　但总得来说，这个数据对比过去也还是有了明显的增长，而这也将是用户能够长期停留在社群和产品运营体系中的保证。

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

　　根据它们之间的关系，整个小程序的产品运营体系如下图所示：

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

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

　　1. 短期活动让新用户的参与压力，团队的持续运营压力都比较小；

　　2. 短期活动每次结束后，能够及时复盘，也能不断改进活动形式，优化活动质量；

　　3. 持续的输出高价值的内容也不现实，需要在非活动期，给团队预留相应的储备时间；

　　4. 如果活动不能经常有新鲜内容，对老用户也会丧失吸引力，需要隔一段时间有新的活动来激活用户。

　　除此之外，通过宣传活动可以规避一些小程序的审核雷区，比如：常用的裂变机制、积赞砍价、提高用户参与度的激励机制，别看别人做得欢，但你做的时候未必让你审核通过。

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

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

　　一是让用户尽快的熟悉小程序的使用，培养他们的使用习惯；

　　二是从用户进入到这套体系开始起，尽量的使用小程序将会用户的行为有迹可寻。

　　对于社群运营而言，小程序丰富了社群运营内容，包括小程序内经常出现的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系列的吸引力度较大。

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

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

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

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

　　从奥数学习的社群中筛选出出错率比较高的学生；

　　再根据其是否在亲子阅读这种人人都能参加（假设）的活动中，判断用户的付费能力，对用户进行排序；

　　得出来的名单再交由销售和运营同学直接通过社群添加相应家长的微信来做进一步了解

　　如此，无论是新业务，还是旧业务，通过小程序构建的完整用户画像和用户始终在线的社群矩阵，都能够快速的完成目标。

　　最后想说的是：有同学可能会觉得这可能没什么了不起，就是小程序+社群运营而已，没有大数据分析，没有人工智能的自动应答，没有区块链。

　　但对于公司和团队来说，脚踏实地地选择最适合自己方案能够解决问题才是最重要的。

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

　　如何有效利用现有的团队资源和人力做出合理的方案，而不是去等待最优解；

　　最大化的整合团队的力量，将团队中不同项目组的特长发挥出来；

　　即要能满足当前需求，也要考虑未来的长远发展。

微信小程序从发布开始，可谓赚足了眼球，一度引发了开发界“全民学JavaScript”的梗。

为了跟上时代步伐，我们团队也在发布后第一时间尝鲜，本文就来扒一扒这几天试水小程序开发的那些事。

想要开发微信小程序，首先必须要有一个微信公众平台小程序的帐号（目前帐号只有内测邀请唯一途径），此帐号用于获取app id、secret id、添加开发者等管理后台操作。

然后你需要下载官方提供的微信web开发者工具，这是一个集成了编码、调试、预览、发布功能的一个IDE。

调试功能，集成了chrome开发者工具，可以实现样式预览、JS断点调试等：

发布、预览功能，可以在此上传你的程序，预览生成二维码，提供在手机微信上预览小程序的功能；另外，开发者工具还集成了ES6编译、代码压缩等基础代码构建功能：

对于哪怕是只有一点点web前端经验的开发者来说，微信小程序的入门门槛简直是低到不能再低了。

一个小程序的主要文件目录简洁到如下：

上述代码中，setData调用后，页面图片就变化了。setData与React中的setState真的是有相当的相似之处。

其实，微信小程序是完全不支持DOM操作的，千万不要想着手动去控制DOM结构。简单的说，HTML5开发中BOM的那一整套API都没法使用，包括window、document ......

WXML在近似于HTML外，吸收了很多其他模板标记语言的优点，例如支持:

前面已经提到过事件绑定，前端人对于事件还是非常熟悉的，事件是视图层到逻辑层的通讯方式。

小程序支持的事件类型包括有：

• touchcancel 手指触摸动作被打断，如来电提醒，弹窗
• tap 手指触摸后离开

和web事件类似，小程序也支持冒泡事件和非冒泡事件，在绑定过程中通过bind(冒泡)和catch(非冒泡)区分：

view及其子组件的tap冒泡事件都会在它这一层被截断。

WXML文件中，组件是视图的基本组成单元，类似HTML的提供的各种标签，小程序提供了非常全面的组件：

• 表单组件 （输入框、单/复选、滑动选择等等navtive表单组件），下图示例是一个在HTML环境中不好实现的picker组件，通过调用native，来实现丝般顺滑的体验：

关于样式，其实没有什么好说的，作为小程序的UI描述语言，几乎与CSS无异，写法、支持的属性也一样。不过，样式文件不是必需的，并且，页面级的样式会优先于全局样式，即index.wxss的样式声明优先级会高于app.wxss。

前面有说到，页面作为小程序的界面单元，那么肯定就有页面间的切换、跳转、后退等。

以下程序是一个简单的通过tap动作触发页面切换程序：

除了使用wx.navigateTo方法外，还可以使用wx. redirectTo，这两者的区别是，前者打开的页面中，可以直接返回原来页面切换前的状态；而后者则是完全关闭当前页面打开新页面，返回时，原来的页面只能“重新渲染”。

区别于HTML5应用，小程序为每个页面提供了一些更强大的生命周期和用户操作回调函数：

• onReady 监听页面初次渲染完成

为HTML5带来的惊喜

以往的产品开发中，如果选用HTML5来开发，性能上一般会比native要差一些，而选用native开发，则一般有比较长的版本发布周期。

微信小程序的出现，使得我们在开发native应用的同时，再也不用忍受漫长的版本发布，只要我们编写好了小程序上传，微信就可以通过后台实现客户端的热更新，在产品性能、发布体验上，都达到了质的提升。

虽然开发小程序非常接近于HTML5开发，但是本质上，它已经不再是web，它更像是React Native这样的native开发框架，通过JSBridge，串联起native底层和上层的JS、WXML逻辑。

它通过封装微信客户端提供的文件系统、网络通信、任务管理、数据安全等基础功能，对上层提供了一套完整的API，使得开发者能够非常方便的使用到微信客户端提供的各种基础功能，快速构建一个应用。

所以，在以前HTML5阶段无法实现或实现起来相当困难的一些功能，在小程序时代将会变得非常简单。

小程序为我们提供了丰富、简单的微信原生API，可以方便的调起微信提供的能力或一些系统原生能力：

• 本地图片、音频、视频的预览、播放
• 本地音频的暂停、进度等控制
• 视频、音频录制、预览、上传
• 系统信息（手机型号、设备像素比等）

小程序严格限定了代码的文件、目录结构，即同名依赖识别：

至少在应用、页面的核心代码这一块，开发者没有必要也不允许自定义自己的目录结构；

另外，结合官方提供的开发者工具，无需操心ES6的编译、代码压缩等构建问题。

微信小程序的出现，给我们带来了接近HTML5、跨平台的开发体验，带来了接近原生应用的产品体验，然而在我们的实践中，还是品尝到了一些不是那么完美的体验。

小程序确实提供了类似HTML5的video组件，用于视频播放，然而把它远远还没达到HTML5的video那么强大：

个人直播业务，基本所有的主播信息、点赞、评论、礼物等等展示都是覆盖于视频之上，如下图：

可是目前的小程序里提供的video组件，会强制所有其他元素必须在其之下，类似CSS中的z-index值，它永远是最高的，这样想通过absolute定位等方式实现漂浮礼物动效等业务需求，变得不可行。

小程序提供了一个HTTP请求接口wx.request({/*configs*/})，可以实现类似Ajax的功能，然而当我们使用现有的业务接口时，却遇到了困难。

在浏览器环境下，我们的后台接口作了很多安全限制，最基本的一项就是请求的referer限制，必须是本域请求才能通过。然而，微信小程序明确规定，wx.request这个方法中不允许设置Referer。所以，如果你们的业务有类似我们的这样的后台接口时，会面临一些接口改造。

我们正常的web业务，前后端通信中，对cookie的依赖是无处不在的，但是，小程序作为本质上的native应用，请求是没有cookie的，我们的程序中，也没有办法拿到cookie，所以，对于很多现有的业务接口，直接兼容微信小程序，恐怕没那么简单。

小程序提供的唯一鉴权方案需要通过小程序客户端、业务服务端、微信平台服务器三方沟通来实现，具体可以看微信官方文档架构图：

其实，以上就是目前大部分开发平台使用的OAuth 2.0标准鉴权方案。

可能是小程序出于战略考虑，设计上还是相对封闭的，想通过小程序打通现有的业务，包括APP、HTML5网站等等，甚至微信公众号，都会受到一些限制。

我们曾想过在小程序里提供常见的长按公众号二维码识别进入关注界面的功能，目前是无法实现的；另外，想通过小程序打开现有的web页面、调起系统现有的APP等，目前也是不支持的。