打码指南-由猫眼线下扫码1分购谈起 | 掘金直播 小程序专场分享总结

本期分享背景：微信小程序在发布初期是没有什么入口的，以后的一段时间，才肯定了由线下扫二维码进入。今天的分享内容由猫眼前端技术团队-小程序业务组提供。团队在一次线下投放二维码进行促销活动的过程当中，经历了一些波折，这里总结并与你们分享一下！

本期主讲大咖：曹宇，2015年加入美团，以后随猫眼独⽴。⽬前负责猫眼电影选座交易业务的Web前端和小程序业务。属于准全栈工程师，习惯多角度思考业务和需求，关注工程质量、工程效率相关工具和理论的推⼴。

本期分享主要介绍一下4点：

• ⼩程序码和二维码的约束（纯技术分享）
• 产出物料后改需求
• 优惠券和用户触达通知
• 线上监控发现的问题

⼩程序码和二维码的约束

小程序码生成：

方案A：getWXACode

参数：path: 'pages/movie/index?arg=foo'

限制：长度128字节，数量10w个

方案A是，调用微信文档中的 getWXACode API 生成小程序码，参数path能够传入带query参数的路径，整个path的长度限制为128字节，生成小程序码的数量限制是10w个，超过10w后，微信会绝句接口请求，提示超量。使用时要注意场景是否适用。

小程序码生成：

方案B：getWXACodeUnlimit

参数：path: 'pages/movie/index' 和 scene: 'arg=foo'

限制：path不能加参数，scene参数32个字符，不限数量

方案B是，调用微信文档中的 getWXACodeUnlimit API 生成小程序码，这个二维码生成数量没有限制，可是path部分不能带参数，这就限制了不少业务场景，这个限制致使它只能在一个固定的落地页。不带参数，咱们无从知道用户是从哪里扫过来的，也就无从定制特定使用场景的特点。在大规模投放场景下，只能使用这个方法

（小程序）二维码生成：

方案C：createWXAQRCode

参数：path: 'pages/movie/index?arg=foo'

限制：长度128字节，数量10w个

方案C是，调用微信文档中的 createWXAQRCode API 生成（小程序）二维码，参数及限制和方案A基本同样，可是这个二维码能够用微信之外的通常扫码程序来扫，你会发现它的地址是https://mp.weixin.qq.com/a/~xxxxxxxxxxx~这种，这里应该是微信内部对path作了一个转换，有兴趣的能够查阅相关资料，这里就不作拓展了。

上面介绍了一些⼩程序码和二维码的形式以及它们支持的一些东西，它们自己存储了一些信息，本质上和url差很少，url自己也能够理解为一种输入，因此这些也须要咱们前端去控制，去处理⼩程序码和二维码背后的那个字符串，综上总结功能以下：

做为链接线上和线下的入口

页面路径 + 参数 ~= url

⼩程序的⼀种输入形式，相似点击 触控...

线下扫码1分购

业务流程

电影院扫码（经过易拉宝展现二维码）

支付1分钱领5元选座券 + 5元卖品券

线上⽀付，购买电影票、爆米花、甜品、饮料时使用

需求阶段1

单价约束: 优惠劵成本是和影院分摊的

总价约束: 每家影院可领取的数量有限

需求阶段1 —— 初步解决方案

活动落地页增长影院参数

⽣成二维码加上相关参数

每家影院二维码不同

例如：path: 'pages/onecent/index?cinema=15280'

需求阶段1 —— 遇到的问题

2000家影院的地推物料如何正确生产出来

并如期正确的送达

解析：这次活动，猫眼有2000家影院参与，预计至少打印4000份二维码，由于每家影院可能投放多个易拉宝。这种物料通常是由总部统一制做，多数公司很在乎本身的品牌，不会容许各个影院本身随便处理。总部制做好，须要邮寄到各个城市，因此必须保证正确的打印与正确的邮寄，而这种人工集中处理的方式，出错是必然的，由于二维码必须扫过以后，才能知道是哪家影院的二维码，很容易出错，假使出问题的几率按1%计算，也有20多家会出问题，因此总体印刷出来后在邮寄的方案确定是行不通的

需求阶段1 —— 新的解决方案

批量生产物料模板，寄送多份

二维码独立推送

影院自行印刷并粘贴二维码

提供设计素材，定制物料

解析：猫眼会统一印刷一些没有二维码的模板，由于总体物料除了二维码部分，其余部分是同样的，而后在批量邮寄二维码，若是某家影院的二维码出现问题，总部能够把设计素材的电子版发给影院，影院的后台能够推送二维码，并能够本身打印二维码，粘贴上便可，基本没有什么差别。

实际效果：

需求阶段2

领取优惠券后, 指望能点击后退

解析：通常二维码扫进来后，以后一个活动页，用户领取了优惠券后，返回就直接退出了，再次扫进来仍是活动页，这就致使了用户领取了优惠券，可是不知道去哪里消费。因此但愿载用户点击后退的时候，能去到一个能够消费优惠券的场景。

需求如图所示，须要在左上角出现一个返回按键：

需求阶段2 —— 初步解决方案

扫码后，先跳转到首⻚，再重定向到活动页

例子：path: 'pages/movie/index?go=pages/onecent/ index?cinema=15280'

或自定义导航栏

解析：第一种方案中'pages/movie/index'为首页，后面部分为跳转目标，这种方案致使二维码又变了，并且参数变长了，会有一些麻烦和风险。第二种方法是彻底自定义导航栏，至关于页面变成了全屏的，只是右上角浮出来小程序的关闭与菜单按钮，这是就能够本身控制屏幕左上角的操做布局了。这个方案有一些限制，好比使用了自定义导航栏，那整个小程序全部的页面，就都是自定义的了。最后猫眼采用了第一种方案。

需求阶段2 —— 遇到的问题

已经打印的二维码物料都没用了

须要从新生成⼆维码

从新让影院印刷二维码并粘贴

解析：由于路径改变了，因此二维码也变了，至关于以前全部电子版和打印版的二维码所有失效，这种走步一看一步的方式确定会出问题的。

需求阶段2 —— 问题的分析

指望能控制后退

指望能够后退到非⾸页的地址

⼀家影院在不同⼊口放置的二维码效果如何

参数愈来愈多，长度超限怎么办

解析：产出物料后改需求是常态。若是想后退到非首页，路径变动，又会致使二维码的更改；若是是同一家影院放在不一样的地方，想知道具体效果如何，仍是要在二维码上继续增长参数；这种需求越多，参数就会越多，最后可能就会达到参数长度的限制。频繁的变动二维码不只麻烦，最终还可能触及方案A的10w个数量限制。

需求阶段2 —— 新的解决方案

使用短网址服务，客户端：

⼊口 path: 'pages/jump?id=3a5fc8'

前端请求 wx.request()

后端响应结果 { path: 'pages/movie/index?go=pages/onecent/ index?cinema=15280&utm_source=foo' }

前端重定向 wx.redirectTo()

使用短网址服务，管理端：

建立短网址 API （响应给前端）

批量查询 修改 API（知足频繁更改二维码需求）

类别（对不一样活动进行区分）

附加信息 :Map 结构（好比影院id，后退页面地址，埋点等）

解析：猫眼提供了一个jump页面，这个页面提供了全部二维码的入口，并提供一个惟一id标识，此方案须要前端，后端及PM一块儿协商，后端去存储全部短网址的信息，前端使用id去后端请求返回一个长的path，这个path是不受二维码长度限制的，由于它不是二维码自己。拿到path后，前端就能够重定向到指定页面了，这样也解决了后退多样化的需求，埋点的需求能够经过，好比上面的 &utm_source=foo 参数，来进行控制。

综上即实现了扫描同一个二维码，返回不一样的路径（后端控制)。

使用短网址服务，更多：

体验问题

扫普通连接二维码打开小程序

连接http://m.maoyan.com/jump?id=3a5fc8

pages/jump?id=3a5fc8

解析：最终咱们生成的二维码短网址，后面的id是不变的，咱们只须要在后台更改对应id下的小程序行为，最终来控制小程序的行为。这个方案解决了需求，可是也产生了一个问题，它多了一个中间层jump页面，通常jump页面是空白的，最多加一个loading改善一下体验，中间层jump页面多了一次请求，可能会多消耗一点时间，进入页面相应的会慢一点。通常的解决办法是：首次进入就是这么慢，而后将响应数据保存起来，第二次扫进来就会更快一些，缓存方面的技巧这里不作扩展。此方案的一个进阶场景是生成普通的二维码，连接如http://m.maoyan.com/jump?id=3a5fc8，这个传统二维码使用任何扫码工具均可以扫描，小程序管理后台提供一个功能，支持扫普通连接打开小程序，只须要通过一些配置便可。

达成扫码，⼩结：

需求是多变的

物料产出后难以修改

短网址服务方案

优惠券和用户触达通知

用户扫码领取了优惠券后，不必定会马上使用，咱们不会等用户来购票，咱们指望能够通知领取了优惠券的用户。

微信支付及预充值代金券

首先，介绍一下微信支付的优惠券体系

曝光⼊口：消息列表 "微信支付" 服务号

时机：领取通知 和 到期通知（设置提早通知的时间很重要）

优惠形式：满减，商品限制，预算限制

提供服务：防刷，对帐，下载消耗记录

解析：咱们想投放微信支付的优惠券时，首先须要充值，好比5元的优惠券投放100个，至少须要充值500元，这对公司的现金会有要求，pm考虑到这一点。前端须要注意的主要是商品限制这一块，在调微信支付的时候，须要将商品的标记或分类传过去，不然不能使用优惠券。

⾃建优惠券系统

在使用微信的优惠券时，须要先垫付资金，可能会对公司的现金流产生影响，因此有的公司会考虑自建一套优惠券系统。猫眼使用的是微信提供的优惠券，可是也对自建优惠券系统作了调研分析以下

曝光⼊口：消息列表 "服务通知"

时机：⾃由，提早收集formId/prepayId，7天内通知

问题：客诉，合规性问题

优惠形式，防刷，对帐，消耗记录

解析：通知入口可使用微信的消息列表"服务通知"，这个通知通常是随时能够发送，可是使用时也有一些约束，咱们每发一个服务通知，必需要有一个凭证。这个凭证能够是用户点击一个按钮，提交一个表单产生的formId做为凭证，这个凭证只能使用1次；或者是用户支付成功，返回一个prepayId做为凭证，这个凭证可使用3次。这两个凭证的有效期都是7天，这是前端须要特别注意的。前端须要刻意的在一些地方去收集formId，不然可能遇到想通知用户领取优惠券，可是发不出去通知的场景。通常要尽可能多收集一些，由于需求比较多变，可能由以前的发送2个通知，到发送3个，4个，还有别的通知等等。当咱们发送多个通知的时候，可能会遇到客户的投诉，这就会致使消息发送不成功，若是一块儿工做的pm不了解这些，必定要即时告知有这个风险，若是业务流程特别依赖服务通知，那么必定不要作任何可能违规的事情。本身作优惠券，那么优惠形式，防刷，对帐，消耗记录都须要本身作，这对后端来讲，工做量是很大的。自建优惠券系统，要作的事情是比较多的，若是是初创公司，不想在这方面有额外的投入的话，最好是直接用微信支付提供的优惠券服务，这会省不少事。

线上监控发现的问题

没法完成登陆

猫眼优惠券项目上线后，一直在观察服务自己是否有意外状况。猫眼对多数的异步调用都作了监控，发现了一个没法完成登陆的问题，好比 wx.getUserInfo() 校验 signature 不一致时，微信认为可能存在通信问题，此次调用是失败的。实际的状况是，在某种场景下，校验永远是失败的，好比：微信 + android 5.x如下，用户昵称中含emoji时。这是这种场景下微信自己存在的一个问题，目前没有什么解决方案，只能等android 5.x版本消失就没问题了。当前的处理办法是，发现符合上述特征时，暂时忽略略签名检查，用户昵称的大概仍是能获取到的，做为展现没有太大问题。

全部微信接口调用可能失败

经过node调用微信的全部接口时，有时可能会超时，好比获取用户的昵称，头像这些东西，用户点击受权，⼩程序端可能会出现卡顿，等了很久后，提示网络错误。这种状况是偶发的，约 0.5%，猫眼的日活基本在百万以上，最高在300w左右或更高，这种场景下，0.5%就牵涉到了不少用户了，通常用户遇到卡顿，可能会认为小程序有问题，致使这个用户可能就会流失了。通过调研，肯定为网络线路稳定性问题，由于猫眼的机房在北京，小程序的机房在上海。目前有一个解决方案是，在使用api.weixin.qq.com这个域名出现问题时，可使用api2.weixin.qq.com在试一试，即作一个容灾方案。具体到猫眼自己是，作了一个延迟重试策略，这个功能上线后，使用成功率的变化为 99.5% => 99.99% 的提高。

监控工具推荐

Central Application Tracking

github.com/dianping/ca…

猫眼使用的是本身的监控工具，名为 cat。这个工具是在和大众点评合并以后，大众点评技术团队分享的一套监控系统，为开源项目。以前在使用其余监控系统时，遇到的问题是，咱们指望在遇到异常是，必定要对异常进行一个分类，须要知道异常的规模是什么样的，其余的监控系统，要么是在大规模报警的时候就崩溃了，要么就是只作日志，不作分类，致使了咱们"只见树木，不见森林"。使用 cat，能够精确的控制分类，吞吐量特别大，知足了咱们前端和node端的监控须要，有兴趣的能够去github上了解一下。

以上，由猫眼线下扫码1分购谈起，分享了靠谱的线下扫码活动须要技术团队提供哪些⽀支撑，这就是此次活动的内容。