平台化思维——微信公众号研究

前言

很多年前读过一本书《重构-改善既有的代码》，里面有一个能快速提升编程水平的方式就是，代码中需要尽量减少重复的部分，1000行代码可以优化为800行，800行可以优化到500行，方法就是将其中重复的地方抽离成一个方法，然后不停的调用这个方法，这个就是我们所说的工具类的产生。

而后，更大一点，比如每个项目都会有自己的登录注册，但是并不可能每个项目都独立开发，所以便会有公共服务（公共页面产生），我们会做一个统一的登录注册页面，让每个项目共用，由此增加开发效率。

在发展中，会有一些巨头入BAT产生了，更会提出统一的登录、注册、支付等服务，这个就是一种赋能，这种便可称为一种平台，而公众号便是平台中最广为人知的产品。说起公众号，相信大家都不会陌生，可以毫不夸张的说，对于一些创业团队来说，公众号承载的实际业务工作，比他们的APP高得多。这里我们便来简单的梳理下公众号的功能，并且赞美下他的平台性特点。

PS：公众号本身文档已经十分完美了，这里就是加点自己的理解罢了，也有可能是曲解。

PS：终于更新了一篇博客，虽然自己不是很满意😆

概念解释

1、订阅号：主要偏于为用户传达资讯（类似报纸杂志），认证前后都是每天只可以群发一条消息；
2、服务号：主要偏于服务交互（类似银行，114，提供服务查询），认证前后都是每个月可群发4条消息；
3、企业号：主要用于公司内部通讯使用，需要先验证身份才可以关注成功企业号。

1）如果想简单的发送消息，达到宣传效果，建议可选择订阅号；
2）如果想用公众号获得更多的功能，例如开通微信支付，建议可以选择服务号；
3）如果想用来管理内部企业员工、团队，对内使用，可申请企业号；
4）订阅号可通过微信认证资质审核通过后有一次升级为服务号的入口，升级成功后类型不可再变；
5）服务号不可变更成订阅号。

所以对于公司来说，如果不是行政部门想提升凝聚力，我们会使用的只有订阅号以及服务号，其中订阅号还多见于个人博客，个人公众号。

服务号以及订阅号差别

首先，订阅号更利于传播，服务号其每月只能推送四条消息，想用服务号发推送新闻稿就要注意了，最好每周推送个一周要闻就不得了了，而订阅号这方面就灵活的多，每天可以推送一条信息，这个特性就十分适合做个人或者小型机构做自我宣传工具了。

然后，在功能上来说，服务号就丰富的多，对于我们来说最核心的功能应该是微信支付，只有服务号才支持微信支付。

最后，在接收消息上，服务号是单独占一行（与联系人同级别），订阅号是在一个订阅号文件夹里面，等级有差别。

这里盗一张非常不错图（吴亮弟）：

开放平台与公众号

我们这里以一个应用场景为例，来说明整个问题，首先思考以下场景：

小叶是一家做互联网连锁串串店的公司，在成都就有10家连锁店了，并且会想做到全国100家1000家，那么他该如何用互联网协助运营呢？

以上场景需要考虑几个客观因素：

① 公司总部也许就30-50个人，这批人是互联网出身，对互联网一切比较熟悉

② 各个门店的话，除了店长或者核心人员会参与到培训稍微了解一些互联网知识，多数是服务员大妈

③ 传统行业人员组成相对社会管理一般比较费力，遇到问题往往更喜欢丢锅

④ 每个店长都可能会很把自己当一回事，会提出很多运营想法

于是问题就出现了：

① 总部肯定是需要一个系统统一管理各个门店的收入以及用户

② 各个门店希望做出自己的特色，宣传管理自己的用户

对于这个诉求，似乎有一个方案是：

① 每个门店拥有一个自己的服务号，可以完成在线的各种流程

② 但是每个门店的服务号是挂在一个统一的大公众号之下的，总部能够看到每个服务号的一切数据

那么这个方案是不是存在呢？别说还真存在！

为了识别用户，每个用户针对每个公众号会产生一个安全的OpenID
如果需要在多公众号、移动应用之间做用户共通，则需前往微信开放平台,将这些公众号和应用绑定到一个开放平台账号下
绑定后，一个用户虽然对多个公众号和应用有多个不同的OpenID,但他对所有这些同一开放平台账号下的公众号和应用，只有一个UnionID
可以在用户管理-获取用户基本信息（UnionID机制）文档了解详情。

这里举个实际的例子说一下这个关联，比如我们公司有三大应用：

① 微信公众号-网页授权

② APP-唤起微信登录

③ PC网站-微信扫一扫登录

显然，我们三个应用都需要用到微信登录，但是我们需要保证我们的账号是统一的，这个时候就必须要微信开放平台去注册了

如图所示，这里可以将开放者平台与APP、PC网站、公众号全部绑定起来，由此将三个看似独立的应用关联在一起。

APP里面会包含iOS APP Store里面的标志，这里有个映射关系；而公众号绑定也不是毫无限制：

一个开放平台可以绑定的公众号是有限制的，所以我们如果想用一个开放平台管理所有的连锁店除非腾讯走后面，否则是有一定困难的。

所以我们如果真的需要总部管理各个分店的话，这里正儿八经方案依旧是用一个公众号绑定一个H5站，在H5站里面做各种接口控制，这里换个方式说是，将控制权掌握在自己手里也许流程复杂一点，也比放在第三方公司好得多。

从体系角度看公众号设计

我们这边最近也一直在做基础服务，这一切都是为了完善技术体系，从第三方应用接入来说，微信应该是做的最好的，百度这边有直达号等类似的产品，但是其体系化感觉还是有待提高的，阿里应该也有类似的技术产品诞生，从我们这层来说，都没有太多知晓，所以要么是运营的不好要么是做的不好。

PS：有所不同的是百度地图这边接口应用到比较多

微信APP本身量非常大，于是开始在平台上发力（我最近也在畅想，我们的APP量大了该怎么使用，结果看了下，好像还没上线，没有结果......），我们看看其应用核心组成部分：

① 订阅号

② 服务号

③ 平台号-APP

④ 平台号-PC

其实消息定制卡片话，很多聊天系统都做过，现在QQ做的特别好，一个可识别URL在QQ里面，就会被自动转换为卡片，我觉得最初微信做公众号的初衷可能就是想将URL这块应用好，于是出现了公众号体系，公众号体系出来后，变会思考如何让各种APP与微信产生交互，这样一步步的将自己由一个纯聊天工具变成了一个平台。

像之前令我们非常头疼的支付系统，现在就完全可以接入微信支付，流程一下就简单起来，这就称为一种“赋能”，就是因为登录体系、支付体系的完善，再加上微信本身的大流量，对应的开发者越来越多了，相辅相成便形成了如今微信的整个一套生态体系，在我们外行人看来真的是令人惊叹！

对于我们各个垂直领域来说，比如我们做医疗的，能不能将自己的家庭医生服务基础做好，然后好好包装一番，让各个平台获得医疗服务；假如我们做货运的，能不能提供比较好的API或者网页接入方式，帮助各个平台更好的接入我们的业务，只要具备平台思维，我相信一旦具有这种基础，后续会越走越远的。

现在平台化的产品&工具越来越多了，比如七牛，比如腾讯问卷这种小而美的产品，我相信这些东西是值得我们借鉴的。