过去几个月，我们团队一直在做一款关于互联网保险业务的小程序，这不仅是自己第一次从0到1负责一款新产品，也是第一次做微信小程序，在整个项目过程中积累了诸多经验和体悟，因此需要经过一次系统的复盘，才能真正内化到自己的产品思维体系中。
这里有两个重点：一是怎么去做一款新产品；二是怎么做一款微信小程序。
我将分三部分讲述从0到1做一款小程序的整个流程：定位、规划、落地。
定位，想做一款微信小程序，一定要先了解微信生态，明白服务号、订阅号和小程序之间的关系，并且基于自己公司的实际业务情况，将小程序嵌入到业务流程中去，所以我将分为微信生态和业务架构两部分进行分析。
规划，把产品做复杂了容易，但做简单了难。尤其是新产品第一个版本的设计，非常考验一个产品经理的功力。哪些该第一版做，哪些该后续迭代，这都要基于产品经理对整体业务的理解进行系统规划。
落地，从一个概念和框架落地为实际的产品是最难的，真正做小程序时会遇到很多的坑，不只是小程序自己的各种坑，也有与自己业务打通时的诸多问题，因此必须要对小程序的特点有所了解，我将把做小程序过程中需要注意的问题一一道来。
1. 定位
1.1 微信生态
为什么要用微信小程序这种载体？
做小程序前要先回答这个问题，否则选择了不适合自己业务的载体，只能是浪费资源。
而要回答这个问题，得先了解微信的生态，并结合自己的实际业务流程去权衡。
在微信生态中，通信功能+朋友圈所构建的社交关系是基本盘，并基于这个巨大的流量池，衍生出公众号和小程序两大子生态系统。
其中，公众号又分为订阅号和服务号，订阅号提供的是内容，以内容沉淀用户，个人和企业均可开通；服务号则专门提供给企业，给用户提供各种商家服务。
服务号和订阅号大概有三点不同：
（1）服务号在消息列表这个一级页面直接单独展示，订阅号则折叠在“订阅号消息”的二级页面中。这就导致了服务号的曝光能力优于订阅号。
（2）服务号每个月能推送4条消息，订阅号每天都可以推送1条消息。因此订阅号更适合做内容来吸引用户并运营用户，而服务号更聚焦于提供服务功能，并且尽量少地打扰用户。
（3）经过认证的服务号支持微信支付功能和高级开发，而订阅号不支持。这进一步强化了服务号的B端属性和服务能力。
从这三点区别可以看到，其实服务号和订阅号之间的差别其实非常模糊。
订阅号使用H5或者小程序同样可以提供商家服务，这样就兼具内容沉淀和企业服务能力了，但服务号依旧有不能做内容的短板，唯一的优势只剩可以更容易获得曝光。
因此，订阅号和服务号的定位可以概括为：订阅号偏向获客、服务号负责服务。
也就是说，在前期，订阅号可以起到吸引流量的作用，可以当做获客渠道，用内容教育和转化用户，当用户变成客户后，就可以引向服务号，专门提供售后的各种长期服务。
那又为什么会出现小程序呢？
没有小程序之前，公众号的各种功能是由H5网页提供的，在服务工具或者说服务媒介这一环节不由微信掌控，而且H5的体验也较差。
因此微信推出了小程序，自己制定了一套“H5”规范，这不但可以在技术层面与微信打通，可以提供更多服务接口，也能够把控工具载体的质量，为用户提供更好的服务体验。
更关键的是，这也打通了整个服务链条，公众号和小程序形成了业务闭环，企业在为用户提供某项服务时，全程都停留在微信的平台上，不用离开微信这个大生态系统。
打个比方，这就像微信是一个大商场，各个公众号是一个个店铺，在以前，当你进入某个商铺时，因为这是一个个H5，所以微信无法了解每个商铺的装修质量和服务能力，也不知道你在里面都做了什么，像一个个黑盒子。
但现在有了小程序，也就是说微信这个大商场为每个商铺统一装修，并且把控了他们的服务质量，也都安上了安全监控，不但提高了你的服务体验，还能获取你的全程数据。
其中，能收集并打通全程数据非常有意义，因为数据分析是一个系统化工程，碎片化的数据是没有价值的。
比如用户的购物行为，没有小程序时，微信只能知道你点击商家入口了多少次，进入商家自己提供的H5后，微信就不知道用户在H5中都有哪些行为了，比如浏览了哪些商品、把哪些商品放进了购物车。在最后，用户付款时使用了微信支付，微信才知道这个用户转化成功了，但是中间购买流程上的每一步转化率怎么样，微信一无所知。
也就是说，微信只能获取入口的流量数据和最后的支付数据，其他的数据则在商家自己手中，微信没有收集到全流程的数据，自然也无法对用户有深入的了解。
只有以人为中心，获取到其全流程数据，才有可能做出精准的用户画像。分析其属性和行为特征后，便可在后续为每个用户提供人性化服务以及精准化营销。
小程序不但对微信的意义重大，而且对开发者来说也非常友好。
由于手机操作系统是割裂的，分为iOS和Android两大阵营，所以要想开发一款APP，需要两套人马，开发两个APP，分别适配两套手机操作系统。而且Android的适配问题非常令人头疼，因为Android是开源的，很多手机厂商的系统也有很大差异，所以光处理适配问题又要花费大量的开发资源。
现在微信已经成为一款10亿量级的国民级应用，渗透率极高，基本是互联网行业的基础设施，像生活中的水电煤一样。
基于这个条件，在微信上搭载了各种服务后，其实微信本身就可以承担手机操作系统的角色。
手机上的一个个APP也就是一个个企业提供的服务，现在微信将自己生态系统中承载的服务统一化和标准化，最后呈现的载体便是小程序。
这是小程序的另一个优势：开发成本低，只需要一套代码就能适配所有机型。
背靠微信这个巨大的流量池，开发成本也不高，小程序这个子生态系统便开始迅速成长起来，如今已经成为首选的载体。
但是小程序也存在短板，因为小程序的定位是轻量、用完即走，更像是一个个小工具，具有很强的工具属性，虽然用户的体验很好，但是没有办法沉淀下来，最终还是要引向企业自己的APP或者是公众号。
这也就是现在经常说的私域流量。
只有变成了自己的私域流量，企业才能更直接地触达到用户，对这些用户进行运营和营销，最终实现转化。
至此，订阅号、服务号和小程序之间的关系和定位就非常清晰了：
在订阅号用内容沉淀用户、使用服务号在中后期服务用户、小程序则承担工具和媒介的作用。
1.2 业务架构
小程序也只是载体，不要跟风做小程序，不要把手段当做目的。
小程序一定是服务公司业务的，属于业务流程中的一环。
我最近在做互联网保险业务，因此所做的小程序也和保险相关：保单管理。
先谈谈保险业务，可能近半的互联网人不了解保险也不关心保险，因为互联网行业兴起也没多少年，互联网从业者好多是二十多岁的年轻人群体。
对于二十出头的年轻人，不关心保险很自然：一是觉得自己年轻力壮，人也常常有侥幸心理，不觉得自己会得什么病或者发生什么意外；二是因为没有家庭，所以也没有那么强的责任感，一人吃饱全家不饿。
但是一旦有了家庭，尤其是有了孩子，自己也步入中年时，就会有很强的风险意识，开始考虑买保险了。
毕竟就算不考虑自己，也要考虑自己的老婆孩子，比如得一场大病，不但很可能会掏空家底，而且也没有了收入来源，家里没有了经济支柱，上有老下有小的该咋办？
所以保险业务的目标客户群体一般是中年人，而且一旦买保险，一定是家庭为单位进行保障规划的，给自己的父母、伴侣、孩子都购置保险。
购买保险后，保险公司就会给你一张保单，也就是保险合同。
一个人一般会配置重疾险、医疗险、意外险、寿险，有的人还会为自己养老考虑，购买年金险，也叫商业养老保险，这些保险具体都有什么作用就不展开了。
也就是说，按照一个人平均有4张保单，那一个家庭，包括双方父母、先生太太、孩子，最少7个人计算，一家人就要有28张保单了。
这些还很可能不是一个保险公司买的，所以对保单的管理就是一个很大的问题了，也是一个痛点。
了解了保单管理的背景，那它在整个业务流程中处于什么节点呢？
对于一个卖保险的公司，底层商业逻辑和其他行业是一致的，核心是两点：获客和转化。
无论是电商平台，还是线下的商铺，都要解决流量从哪里来、又怎么转化客户以获取商业价值的问题。
关于获客，虽然现在已经有诸多平台和各种类型的获客方式，比如近几年比较火的今日头条的信息流广告、抖音的短视频广告，或者是传统的SEO/SEM，到最后才发现最有效的还是微信公众号平台。
在微信公众号投放广告的转化效果要明显优于其他平台。
首先是因为公众号具有聚集效应。
每个公众号定位不同，因此关注的用户也明显有分类，比如母婴号的关注用户大部分都是宝妈或者怀孕的准宝妈、军事类的公众号的关注用户比例最高的是中年男性。
因此只要找准自己业务的目标人群，再去目标人群聚集的地方投放广告，自然会有很好的转化率。比如卖体育用品的公司，可以将广告投放健身类的公众号，卖化妆的可以投放美妆类或情感类的公众号等等。
更关键的是，公众号文章不同于普通的硬广，可能不读到最后根本就不知道这是一篇广告，因此用户不会有天然的抗拒心理，而且代入感更强，不知不觉读完之后，会被文章丰富的图文和自洽的逻辑所教育，即使不能立即转化，也会对投放的广告产生品牌认知。
这也是为什么，经常会有一家公司会和某一个公众号长期签约，定期多次投放相同的广告。
重复，能起到固化认知的作用。
用户价值不会一次释放完，可能第一次没有转化成功的用户，经过多次教育后就能够转化，直至一个公众号的用户群体的价值被充分压榨，转化率下降，此时公司可以转战下一个公众号了，如此循环往复。
我们所做保险业务也正是采用了这样的获客方式，有了客户之后，转化环节就要靠保险销售了，把不同质量的用户分给不同转化能力的销售。
用户质量也就是购买能力，可根据年收入划分为不同层次。
年收入10万以下的客户，不但转化困难，而且成交后能获取的收益也很低，保险销售都不太愿意接这样的客户；
年收入10万到20万的客户群体则是中坚力量，这也是保险销售群体比较喜欢的客户群体；
年收入再高的话，超过50万以上，则属于高净值人群，很多对保险或者一些资产配置产品有比较深入的了解，普通的保险销售驾驭不了，适合分配给资深的销售。
转化环节，其实是一整条服务流程，对于保险业务，可以细分为投前、投中、投后。（即投保前、投保中和投保后）
投前的核心是做家庭财务规划，投中则是协助核保，投后需要的是保单管理和理赔协助。
基于整个业务架构，便可构建出相应的产品架构，即不同的产品所对应的业务环节和承载的功能。
（1）保险业务后台：主要分为产品、客户和交易三大模块。
产品管理，也就是我们公司所售卖的保险产品库，接入的是第三方渠道或者直接对接不同的保险公司。
客户管理，包括客户的标签数据和流转数据，也就是用户是从哪里来的（来源渠道）、现在在哪（所处的环节）、又将往哪里去（购买意愿）。
交易管理，则是连接了产品和客户，核心是订单的相关信息，包括订单的各类状态，比如未支付、已支付、已出单、退保、核保、理赔等全流程状态。
（2）家庭财务智能规划系统：将转化流程标准化，根据客户的财务状况，自动计算风险缺口，并给出保险配置方案。
不但可以体现出公司的专业性，还可以为保险销售节省大量的精力，让其更聚焦于为客户讲解保险知识和财务知识。
（3）保单管理小程序：则承担售后服务，客户不但可以查看自己家庭购置的保单，也可以使用申请退保或理赔、续期续保提醒、保单检视等功能。
2. 规划
2.1 用户路径
了解了保险业务的业务架构和产品架构后，也就知道保险管理小程序在业务流程中所处的位置和发挥的作用了。但这也只是保单管理小程序的完整态，真正实现时，需要分步迭代。
为什么说一款新产品的第一版一定要足够简单？
一方面讲，第一版足够简单是一种实验思维，一旦发现存在问题，可以快速调整。甚至发现产品不受用户认可、产品方向存在根本性问题时，即使迅速抛弃现有的产品，浪费的资源也不算非常大，沉没成本在可接受范围内。
另一方面，这也不只是为了开发资源考虑，更关键的是需要快速开发、快速进入市场、然后再快速迭代。
互联网行业常常讲究先发优势，目前互联网保险行业的入局者越来越多，竞争也是日益激烈，所以尽快地抢先市场并占领用户认知就非常重要了。
当然，产品的第一版足够简单是不够的，也要足够有用。
怎么才能有用呢？
一定要找到一个核心的业务节点，把这个产品嵌入到业务流程中，也就是用户必经路径上，才能真正发挥作用。
经常会出现的情况是，做了一款产品，然后没有在用户核心路径上，用户可用可不用，用了固然有帮助，不用也没有什么影响，那这款产品也就发挥不了什么价值了。
可以拿腾讯相册小程序举例，在初期，腾讯相册只是打通了小程序内的QQ账号体系，用户主要是查看自己在QQ的相册。
而在18年5月，做了从QQ微信的照片由小程序来承载这个功能后，数据量才开始爆发性增长。
也就是说，从QQ分享照片到微信这个核心使用场景中，用户原来的路径是直接分享照片即可，不会是进入小程序再去分享，这个路径反而变长。但是用小程序承载后，也就是把小程序这个载体嵌入到用户分享的必经路径中了，使用量比以前自然会有大幅上涨。
其负责人曾提到过，腾讯相册小程序的用户增量主要来自于QQ空间用户的分享，在小程序的新用户来源中，80%是分享进入的，也就是说每5个使用用户有4个是通过分享路径进来的。
由此可见，一款新产品想要“有用”，必须要嵌入到用户的核心使用路径中。
对于保单管理来说，客户在我们公司买完保险后，一定是想要直接能够看到保单的，而不是让保险销售手动发给客户一个文件或者让客户自己登录网站去查看自己的保单。
所以这也正是保单管理小程序在业务流程中出现的第一个节点：客户买完保险后，可以直接在微信小程序中查看自己购买的保单，并可以获得一系列的售后服务。
2.2 功能范围
查看保单功能是保单管理小程序最基础也是最核心的一个功能，但是客户的保单其实分为两部分：在我们自己公司购买的保险和在其他公司购买的保险。
在我们公司购买的保险，我们有相关的保险数据，所以可以直接在小程序中展示，那客户在其他公司买的保险，我们也没有相关数据，那该怎么办？
尤其是自然流量的用户，不是我们平台的客户，他们又怎样使用保单管理小程序呢？
这就是我们产品的另一个核心功能：上传保单。
有了上传功能后，不但小程序可以独立使用了，同时，自己平台的保单数据和客户自己上传的保单数据合在一起，构成了客户的完整保单信息。
当然，这个功能也应该在客户的核心路径上。
客户在做保障规划时，需要纳入客户的已购保险的，不但可以将家庭财务智能规划系统计算出的风险缺口减去客户已有的保额，也可以将客户的已购保险和我们推荐的保险进行对比，最终实现让客户买到性价比最高保险的目的。
也就是说，保单管理小程序在业务流程中的位置前置了，不但可以在购买保险后（投后）查看保单，也可以在投前的保障规划阶段起到录入已购保单的作用。
至此，可以看到，保单管理小程序需要两个核心功能：查看并分享在我们公司购买的保单和上传在其他地方已经购买的保单。
其实，这个也可以类比腾讯相册小程序。
对于腾讯来说，一个人的照片分为两部分：一部分是在QQ空间和微信朋友圈的照片，也就是用户在腾讯自己公司的数据；另一部分则是用户在其他平台的照片，可能大部分都是在用户自己的手机相册中。
那么腾讯相册小程序的核心功能也需要两个：用户可以查看并分享在QQ空间和微信的照片、用户可以上传手机相册中的照片。
这和保单管理小程序的功能逻辑基本相同。
明确了产品的核心功能后，再回到最初的问题：第一版要上哪些功能呢？哪些需要后续迭代呢？
我们选择了第一版先实现用户可以查看和分享在我们公司购买的保单，也就是将保险业务后台的保单数据同步至小程序。
已成交客户作为我们新产品的种子用户，可以先将小程序用起来，检验一下产品的使用效果，并优化使用过程中存在的一些问题。
上传保单功能则放在第二个大版本进行迭代，有了上传功能，就不仅是一个内部应用了，可以单独使用，成为一个独立的小程序应用。这样也就有机会去获取自然流量，成为获客的另一个渠道。
不过，小程序的核心定位还是形成公司的业务闭环，服务好自有客户，而所谓获客只是锦上添花，其实还是很困难的，只是提供了获客的可能。
3. 落地
3.1 交互设计
明确了业务架构和产品架构后，也确定了产品的迭代路径，接下来就要考虑产品的具体信息架构了。
信息架构，也就是界面层，即展现在用户面前的视觉效果，比如不同功能的组织，页面布局等等。
经常说小程序的特点是用完即走，那怎么才能达到这样的效果呢？
第一原则：使用路径清晰且单一。
这样用户一旦进入了小程序，就知道自己要怎么做、下一步点哪里。
因为小程序有很强的工具属性，用户在进入小程序前带有明确的目的和预期，那么，好的小程序一定要让用户进入小程序时，就能使他产生一种：“嗯，这就是我想要的。”的感觉，并且顺畅和快速地让用户解决要完成的事。
摩拜单车的小程序就是很好的例子：扫一扫、点击解锁、骑车即走，用户只需要三步动作即可完成任务，小程序在整个流程中的存在是完美连接线上和线下的，顺畅无阻塞，甚至是无感知的。
不好的做法是，堆砌很多偏离业务主线的功能，找半天才找到能解决自己问题的功能入口，也就是把小程序做成了一个很重的APP。
如果业务比较复杂，可以拆分为一个个独立业务或者功能点，做成小程序矩阵，典型如几个互联网巨头，美团、京东、百度等。
第二原则：交互方式简单且统一。
这里有两个关键词：简单和统一。
对于简单而言，最重要的就是不要用太多复杂的交互，更不要用太多页面跳转这么重的交互方式。不用复杂交互可以理解，因为用户打开小程序是为了快速解决问题，如果各种操作使用复杂交互效果，反而会造成使用不便。
这个和PPT类似，在做汇报时，如果加入各种动效，不仅会造成喧宾夺主，听众的注意力被动效吸引，而且动效过程也会浪费很多时间。简单直接，往往最有效。
那又为什么说页面跳转这种交互比较重，不推荐在小程序中使用呢？
原因有两个：
一是新页面加载需要等待；
尤其是生活中经常会有弱网或者无网的场景出现，比如地铁、电梯、地下停车场等，因此跳转新页面会出现长时间加载情况，所以操作能在现有页面完成就尽量不要跳转。
二是过多层级的页面路径会对用户认知造成混乱；
本身小程序就属于微信的子页面，至少是二级页面，如果在小程序内的页面也有很多层级或者是要经常跳转，就非常容易让用户产生疑惑或者焦虑感。同样，这也违背了第一原则。
反面案例就是京东APP，拿签到模块举例，其页面层级有非常多层。
关于交互的统一，本身就是一款合格的产品应该具备的。
虽然一款产品可能有很多模块、很多业务，可能是由多个产品经理分工负责，但是一定要注意交互一致性、布局一致性、设计一致性。
在同一款产品中，如果使用不同的功能或者模块时，发现视觉效果明显不同，那就很可能是不同产品经理做的，也说明没有一个产品负责人去整体把控这款产品。
关于小程序，微信本身提供了一套标准的小程序设计规范，比如启动页加载样式、页面下拉刷新样式等等，不但可以减少很多开发量，也提供了一套通用标准，但是依旧要注意交互的一致性问题。
建议先通读一下微信小程序关于设计部分的官方文档：
在实际的项目中，最好由产品经理和交互设计师或者UI设计师一起基于微信小程序的设计指南，制定好一套适用于自己产品的设计规范。
拿微信APP自己举例，对比其设置页的编辑态，会发现复杂的编辑操作或者重要的编辑操作，都会有“完成”按钮进行二次确认，而一般的编辑操作可直接操作。
虽然这只是一个简单交互，但是说明其对设计的规范性。
小程序中几个典型的交互方式总结一下：
能不跳转就不跳转（多用底部弹窗）
能不输入就不输入（多用自动填入、勾选等）
键盘自动调起（注意不同情况下的不同键盘类型）
第三原则：请严格遵守第一原则和第二原则。
3.2 数据支撑
做功能一定先要考虑到数据从哪里来，能不能支撑功能。
很多时候，把功能设计得非常好用，但是往往难以落地或者是实际使用时出现了各种问题，一个很重要的原因就是数据支持没跟上。
拿我之前想做的一个关于电商比价产品举例：因为现在电商平台比较多，商家也比较多，我想买一款电视，相同品牌或者相同型号的，在哪里买便宜呢？
所以我就会去不同的电商平台看看，比如天猫、京东、苏宁、唯品会、甚至拼多多，在这个过程中，我需要不断切换不同的应用去对比，花费大量的时间。这个场景在生活中经常会出现，我观察到很多人也都有过相似的经历。
要是从场景和需求来看，似乎电商比价这个功能非常有用，很多人肯定也非常想用，要是真的做出来了，万一大受欢迎，说不定我还可以去创个业、拿个融资，从此走向人生巅峰。
但是，等一下，既然这个功能既然这么有用，为什么没人做呢？
我从美好的幻想中被拉了出来，细想后发现，这里存在一个关键的问题几乎难以解决：数据从哪里来？每个电商平台都有自己的价格机制和调控平台，那商品数据和价格数据是否会开放出去呢？
显然是不可能的，这些数据是电商自己的数字资产，也是自己的优势，所以一个个电商平台之间树立起了数据壁垒。
从这个例子可以看到，不同公司之间的数据打通是极其困难的，不只是技术问题，更多是意愿问题。
除了不同公司间的数据壁垒问题，相同公司的不同部门的数据打通同样存在种种困难。
拿腾讯相册小程序举例，其功能其实也非常简单，但是难点一定是在数据上：QQ空间相册的数据、微信数据和从本地上传的数据的打通问题。
因此，技术不是问题，重点在于不同部门能否通力合作去解决问题。
对于腾讯这种巨头公司，经常会出现的大公司病就是“各立山头”，而QQ和微信就隶属于不同的事业群，这大大增加了数据整合、信息流通和资源共享的难度。
所以不要把一个公司当做一个整体，也不要觉得一个公司是铁板一块，大家都会优先考虑公司的整体利益，毕竟一个公司是由不同的人组成的，位置不同，利益自然也不同。
因此从下往上推动一个项目往往是很难的，只能从上往下去贯彻一个目标，由更高层的人去牵头才有可能成事。
说完公司管理层面的问题，回到数据打通本身，真正在落地时，很难处理的是数据格式问题。虽然对于保险业务，数据格式相对来说已经比较规范了，但是依旧存在一些细微的差别。
就拿我们公司叫的“保障期限”来说，也就是买一个保险能保障你多长时间，行业中不同公司的叫法有：保障期限、保险期限、保险期间、保障年限等，那么来自不同公司的保险产品数据在打通时就会存在问题。
因此，数据格式统一是数据打通的第一原则。
尤其是现在我们做的这个微信小程序，是一款新产品，需要使用保险业务后台的现有数据，那么在新产品中的数据字段名称和格式，一定要与原系统保持一致。
在实际的工作中，数据格式这一块儿就耗费了我们非常多的精力，因为原有业务后台也存在诸多问题，很多地方的数据格式也没有统一，或者现有的数据格式不规范，因此需要先梳理现有系统的数据格式，并纠正其中的一些数据问题。
数据格式问题解决之后，然后还要依照不同的维度解决接下来的一系列数据问题：
数据来源：数据都是由哪些人或者系统产生的，可以分为线上系统同步和线下人工录入，只有搭建起自动收集数据的自循环，才有对数据分析和应用的可能；
数据查看：不同的数据都是有哪些角色查看、不同角色的数据权限有哪些、查看的终端有哪些、目前查看数据的流程和方式是怎样的；
数据应用：数据可以用到哪些具体的功能中，比如数据异常预警机制、数据展板等；
数据更新：目前不同类型的数据是怎么更新的、更新频率是多久、有哪些数据长期未更新、未更新的原因是什么、未来建立的数据系统需要怎样支持数据更新（频次、实时性等）。
3.3 用户授权
在以前，进入一个APP时，需要输入账号和密码进行登录，即使是现在，主流的也是输入手机号，然后通过短信验证码登录，没有注册时还经常要先去注册，整个路径非常长。
但是在微信生态中就不一样了，进入小程序时是静默登录的，在小程序后台直接完成了登录操作，企业可以获取到用户在此应用中的唯一标识OpenID，用户不需要进行任何操作。
这个也好理解，用户进入微信APP时，已经进行过一次登录，那再使用微信内的应用时自然不需要登录。
那我们为什么还会在各种小程序中看到“登录”按钮呢？
其实，这里的“登录”本质是授权，是为了获取你的各种信息，因此是两回事。
可能许多应用为了延续用户在APP生态中的使用习惯，所以依旧使用“登录”这种叫法。
微信本身就有你的手机号、身份证、年龄、性别、地域等关键信息，但是不会直接开放给其他企业，需要用户手动授权。其中，手机号信息又从用户信息中抽离出来，需要用户单独授权，毕竟手机号是一个非常关键的用户信息，可谓是现在的互联网通行证。
所以，微信的信息授权分为两种：一种是手机号授权、另一种是用户其他信息授权。
这两种授权非常简单，只需要一步点击操作，即可触发微信登录底部弹窗，直接授权手机号或者用户基本信息，比传统的登录操作要便捷很多，这也正是微信生态的优势所在。
但是出于对用户信息保护的考虑，也为了避免打扰用户，微信对用户信息授权的触发方式做了各种限制。这不得不提微信的审核机制。
微信的小程序生态和苹果的应用生态非常类似，新开发的应用都需要审核通过，才能上架开放出去。
开发iOS版本的应用时，很多开发者经常会遇到审核不通过的情况，因为苹果制定了一套审核标准，必须符合苹果的设计规范和基本要求才能通过，否则要被打回修改。
微信沿用了苹果的审核机制，同样制定了一系列的标准。我们在这个项目中就遇到审核不通过的情况，被打回的原因就是：授权方式不规范。
“你好，小程序帐号登录功能暂未符合规范要求，请在用户了解体验小程序功能后，再要求用户进行帐号登录。请整改后再重新提交审核，具体登录规范及整改可参考：https://developers.weixin.qq.com/community/operate/doc/000640bb8441b82900e89f48351401请根据上述原因对小程序进行修改，并重新提交代码审核。若对上述原因无法理解，可前往反馈页面进行反馈。
我们原来的设计方案是：用户进入小程序后，会显示启动页，手机号和用户基本信息授权成功后才能进入小程序主页面。
但这是微信不允许的，简单说，就是不能一进入小程序就直接弹窗提示用户登录，必须要让用户看到小程序的主体内容后，并手动点击按钮去触发登录弹窗。
就连我们这种用启动页过渡的方式也是不允许的，必须要进入小程序并看到一级页面才行。
最后我们不得不临时改动产品方案，在首页和“我的”页中分别增加了授权手机号、授权用户信息两个触发按钮。
3.4 用户标识
用户授权的底层是和用户标识有关。
为什么我们需要用户标识呢？
有两方面作用：
一是微信用户数据与外部数据的打通，也就是与自己的已有业务数据打通，比如某个用户已经在我们的后台有了购买数据，那么我们只要确定了他的身份，然后和我们后台的客户标识进行对比，就可以知道他到底是不是我们的已有客户。
目前用户唯一性的通用标识是手机号，因为手机号是实名的，与身份证绑定在一起。确定了一个用户是我们后台的已有客户时，就可以直接把他的购买数据推到小程序端，这个用户也就可以看到自己的保单数据了。
二是微信内部不同应用数据之间的打通，确定了用户的唯一性后，其在不同微信应用的行为数据或业务数据就可以串在一起了，比如在订阅号的阅读数据、在小程序中的行为数据等。
每一个人都是一个数据源，无时无刻不在创造着各种数据，只不过这些数据要么没有被收集到、要么散落在不同的应用中，所以我们若能收集到这些在不同场景中的碎片化数据，并想办法归类到创造这些数据的同一个人身上，我们就能更加全面的和深刻地了解这个人。
这也就是所谓用户画像的由来，只不过现在大多数的用户画像还非常单薄，可能只有性别、年龄、地域、手机设备型号等属性数据，而没有更加深入的、更加细节的信息。
比如从一个人的外卖数据中可以了解到他的饮食习惯，也可以知道他的长住地，公司或者家庭地址等；从一个人的购物数据中可以获取到他的最近生活方式变化，像开始买纸尿布，推测其有了孩子，后来又买了童装，则说明他的孩子长大了；从一个人的聊天记录数据和通信录数据中可以抽离出更多的有效信息，这个人的说话方式、关系网、最近的心理状态等等。
唯一的问题就是这些不同场景的数据在不同的平台中，而且是非格式化的数据，包括文字、视音频等主动数据和点击查看等被动数据。
那么我们就需要每个用户都有唯一的标识，并将其在不同的应用中的不同唯一标识串起来。
在一个应用内，比如小程序、订阅号或服务号，每个用户都会打上唯一标识，这个就是OpenID，为什么叫Open呢？
因为这个ID会提供给应用所属的企业，但是为了保护用户隐私，也是为了保护自己的数据资产，微信肯定不会直接把手机号、微信号等重要信息给其他企业，所以这个公开的ID是经过特殊规则转换过的一个特殊字符串，不包含任何明文信息。
但此时也会出现问题，要是一个企业有多个小程序，还有订阅号或服务号，那一个用户在同时使用这些应用时，在每个应用内都有一个唯一标识，也就是会有多个OpenID，那到底有多少真实用户呢？而且单个用户在不同应用中的行为数据怎么串起来呢？
总不能一个用户在订阅号中标识为用户A，跳转到小程序后，就标识成用户B，然后数据也就被割裂开吧？
于是，便有了UnionID，就像字面上的意思，联合的标识。
有了UnionID，同一用户在不同应用中的不同OpenID就可以映射到唯一的UnionID上了。
简单总结：
OpenID是同一用户同一应用的唯一标识。
UnionID是同一用户不同应用的唯一标识。
OpenID是不需要授权的，在公众号中，关注公众号时企业可以获取用户的OpenID，在小程序中，进入小程序时即可直接获取。
但是UnionID则不同，在公众号中，不仅需要用户关注我们的公众号，还需要开发者去微信开放平台绑定公众号后，才可以获取UnionID；小程序获取UnionID的规则更复杂一些，用户进入小程序时，如果用户已经关注了与小程序同一主体的公众号，而且公众号已经获取了用户的UnionID，而不需再次授权，否则的话，需要在小程序中单独授权才能获取UnionID。
3.5 数据埋点
在项目完成到最后阶段时，数据指标一定不能忘，数据指标是量化评估你所做需求的实际效果的关键。
关于数据埋点，分两种情况：
一种公司和产品已经比较成熟，也比较稳定，也有现成的数据分析工具，有完善的数据埋点规范，埋点的成本比较低，那就可以全面埋点；
另一种是公司处于草莽时期，只是想赶紧迭代，赶紧推上线，关于数据埋点没有统一规范，但此时依旧不能没有数据支撑，因为没有设置好基本的监控数据就上线产品，就像飞机的盲飞，你可能飞起来了，却不知道还有多少油、数据情况怎么样、是变好还是变差，如果要改动，要改哪里。
事无巨细地追踪所有用户行为，需要全面铺上数据埋点，工作量巨大，对于正在快速迭代的初创企业确实不太现实，可能几个月后才能看到数据，所以建议采取分级分步的方法，优先定义出最重要的几个事件追踪，然后再做其次重要的事件。
不过好在微信小程序本身就提供了基本的数据统计，而且还有直接配置的埋点方式，无需代码，这样就简单很多了。
在微信小程序后台，整体可分为常规分析和自定义分析。
常规分析就是不需要自己数据埋点，微信直接就能收集到的数据，分为三类：
（1）新增、活跃、留存等概况数据，对应“使用分析”模块
（2）页面流量数据，又分成了实时和非实时，分别在“使用分析中的页面分析”和“实时分析”两个模块
（3）用户画像数据，包括性别、年龄、地区和终端机型
自定义分析也就是数据埋点，分了两种方式：直接配置和API上报。
1）直接配置
只需要填写事件名称、触发动作和页面元素的ID即可，不需要添加代码，也不需要上线，这种埋点方式适合统计功能的使用情况，比如多少人点击了签到按钮、多少人进入设置页面等。
2）API上报
适用于收集事件下的具体属性数据，比如点击商品这个事件，如果我们想要知道用户具体点击了什么商品、商品的价格是多少等信息，就需要这种添加代码的数据埋点方式了。
从另一个维度看，数据又可以分为两大类：用户数据和业务数据。
用户数据包括用户画像和行为数据，业务数据则是和业务直接相关的数据，比如购买金额、购买频率等。
对不同类型数据的分析要在不同平台处理，微信小程序提供的数据分析更多是集中在用户数据部分，业务数据则主要在公司自己的业务后台。
“如果你从头开始建立用户行为追踪计划，建议先找到3个最重要的一级事件，这3个一级事件，应该代表了用户从初次接触产品到最终成功使用产品的最重要的里程碑。”
这是我之前在书中看到的埋点理论，把这个理论用到我们的产品中，最关键的3个一级事件是：进入小程序（PV/UV）、关键功能1的按钮点击（PV/UV）、关键功能2的按钮点击（PV/UV）。
当我按照之前在书中看到的这套理论梳理了三个关键指标后，才发现实际情况没有这么简单。
先是leader直接就发现了问题：这不是关键指标，应该和业务结合，目前最重要的是要让保险销售知道自己名下哪个客户有没有使用小程序，然后推动客户去使用，如果用简单的PV、UV、按钮点击等等，对业务没有什么帮助，适合后期再去完善。
之后又深入思考了现状：我们现在有2个微信公众号和即将上线的2个小程序，已经构建起了一个微信生态服务矩阵，因此要考虑到4个应用之间的互联互通，而不只是我现在负责的这个小程序需要收集使用情况的数据，其他两个公众号和另一个小程序同样需要。
那我们怎么把这几个微信生态应用的数据使用情况集合到一起呢？
我们了解到另一个产品经理正在保险业务系统中做用户行为轨迹模块，即收集一个用户从接触到我们的品牌、到使用我们的服务、再到满足需求，整个业务流程的数据。
这两个小程序的使用数据也正是整个业务流程中的一部分，他现在已经收集了公众号的使用情况，因此可以把两个小程序的使用情况也放到这个模块中。
也就是说，我们把我们想要的数据需求提交给另一个负责用户行为轨迹的产品经理，把数据融合在他所做的模块中，然后我们这边再做一个用户是否使用小程序的提醒功能即可，这就实现了一个新小程序的初步数据统计需求，之后再按正常流程提数据埋点需求，把核心页面和关键流程都铺上点。
我们产品内部策划好这个需求后，再与程序员沟通时，又遇到了一个问题。
因为没有事前规划好，已经临近小程序上线，即使需求较小，现在再改代码会打乱发版节奏，所以开发建议在上线后一周内紧接着迭代一个小版本，把一些上线后暴露出来的问题和这个埋点需求整合在一版中。经过评估，这也在可接受的范围内，所以就按照这个节奏执行了。
这才是实际业务场景中遇到的真实情况，而不是书上讲的那么清晰和简单。
所以，并不是知道了一个方法论或者一个道理就可以直接套用，而是要结合实际的业务再次深入思考，并根据实际情况及时调整才能真正解决问题。
总结
从定位、到规划、再到落地，一款微信小程序历经打磨后终于上线了。
根据线上的数据和用户反馈，然后开始进行下一版的迭代，不但要解决线上的一些问题，还有可能要修正原来的规划方向，毕竟真实的效果和自己最初的设想常常会有非常大的出入。
目前这个项目已经迭代了两个大版本。
真实的项目不是闭门造车，在实操的过程中一定会有大量的细节问题和业务问题，所以我梳理了整个项目后，在这里写下的文字略去了诸多细节，只保留了整体的框架、核心的流程和关键的问题。
如果问我在这个项目中收获最大的是什么？
还是最开始时说的：
首先是从0到1做了一款新产品，这让我对整个产品的规划能力有了很大提升，也对公司内部不同系统之间的协同与配合有了更深的理解；
其次才是做了一款微信小程序，对微信生态有了更多的思考，对小程序的特点有了更多了解，只有先掌握好小程序这个工具，才能更好地服务实际业务。
做产品，和拍电影或写东西一样，形式与内容，两者不可偏废。