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

背景

你们好, 今天给你们分享的是打码指南, 由猫眼线下扫码1分购谈起.

小程序在发布以后是没有入口的, 以后肯定是由线下扫二维码进入, 今天分享的是咱们本身尝试在下线投放二维码, 进行促销活动, 中间经历了一些波折. 这里给你们介绍一下中间经历的事情.

先作下自我介绍, 在2015年加入美团以前, 一个是去哪儿, 一个是CSDN, 再以前在西安, 主要是外包项目, 企业信息管理系统. 以前在作Java, 当时没有前端工程师的岗位, 但平常工做作前端比较多, 后面你们会看到有时有前端, 有时没有前端的介绍, 这是由于我我的准全栈的经历致使. 若是有志向作PM的话, 也建议关注下, 由于一个好的PM, 你应该知道这个东西是怎么工做起来, 都有哪些人参与, 每一个人负责什么东西, 这个也是颇有帮助的.

回到主题, 咱们今天大概介绍这4个点

• 小程序码和二维码的约束
• 产出物料后修改需求
• 优惠券和用户触达通知
• 线上监控发现的问题

第1点和业务无关, 纯技术的描述. 由于后面在介绍业务相关的场景的时候, 为了说的更流畅, 因此须要先介绍下小程序码和二维码的约束.

小程序码和二维码的约束

相似菊花那种, 官方名字叫小程序码, 咱们在平常沟通当中不会在乎这个细节, 反正都能扫, 都叫二维码.

方案A: getWXACode

这是微信文档有这个API, 用于生成这个二维码, 参数包括

path: 'pages/movie/index?arg=foo'
复制代码

限制:

• path参数限制128字节长度
• 调用总数量限制: 10w个, 若是超过微信会拒绝后续的接口请求, 直接出错, 提示超量

方案B: getWXACodeUnlimt

仍旧是菊花码, 参数包括

path: 'pages/movie/index'
scene: 'arg=foo'
复制代码

限制:

• path 不能加query参数
• scene 长度限制32个字符

在业务场景中不是很通用, 只能固定落地页, 可是咱们扫码的目的仍是须要有一些线下的特色可以传过来, 若是使用scene参数传递额外参数的话, 这个限制比上一个更苛刻, 可是它不限数量.

这个是在多数大规模投放二维码的方案, 小规模的, 好比咱们的今天要讲的这个案例, 咱们投放了大概2000多个影院, 其实这2个方案均可以.

方案C: createWXAQRCode

小程序官方叫小程序二维码, 看起来和普通二维码差很少, 因为二维码自己有必定容错能力, 因此LOGO放着是没问题, 参数

path: 'pages/movie/index?arg=foo'
复制代码

限制:

• path 128字节长度
• 调用总数量限制: 10w个, 和方案A公用配额

这个二维码能够用普通扫码程序扫描, 扫码以后能够发现地址是 mp.weixin.qq.com/a/xxxxxxxxxxx, 这是一个有意思的地方, 咱们明明给传的是上面的参数, 可是生成的是下面这个地址, 感受是作了转换.

前面介绍几种形式, 限制和支持的参数, 存储的信息, 本质上这些信息和URL差很少. 咱们用二维码链接线上线下, 二维码自己存储的信息是路径加参数.

传统web开发咱们须要关注URL上的输入信息, 好比query参数, 路径, 特别是单页应用的路由框架特别关注URL上的信息.

能够理解URL也是一种输入, 相似触控. 因此二维码也须要前端的同窗关注, 由于咱们要去处理二维码背后的参数, 和咱们的指望是否能匹配.

接下来看下实际案例, 和遇到的问题.

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

咱们在线下投放的业务, 经过易拉宝的形式, 扫上面的二维码, 进入活动落地页, 登陆支付1分钱, 领取两张优惠券, 分别用于支付电影和小吃如爆米花时抵扣. 投放位置是电影院, 咱们的主要合做方.

需求第1阶段

5块的优惠券不是凭空出来的, 是得有人承担的, 通常是平台和商家互相分摊的. 平台指望活动越多越好, 可是影院是有限度, 由于影院的规模, 活动成本有要求. 所以咱们必需要识别出来是那家电影院, 涉及到财务结算, 不能错.

咱们的方案:

• 活动页每家电影院带上影院参数, 每家影院生成不同的二维码
• 咱们还须要打印出来

问题来了, 咱们有2000家影院, 每家好比须要2份物料, 那么咱们须要打印4000份, 有2000种不同的二维码.

物料通常是总部生产, 由于多数公司比较在乎本身的品牌, 不会容许地下城市本身随便生产涉及品牌形象的物料. 总部制做好以后还须要邮寄到各个城市, 把它放到具体的影院中.

正确的打印和邮寄, 人工不出错才见鬼了. 快递还能够直接看单子, 二维码人不能直接识别, 打印错了也难以发现.

因此直接按照这个方案走是很容易出错的. 1%的出错比例影响也比较大, 出错的影院会直接找上门, 那就会是很大的麻烦.

为了不出错, 调整以后的方案, 咱们印刷一个模板, 不包含二维码, 由于物料只有二维码部分是变的, 别的都不变, 这样就能够批量的印刷, 批量的邮寄的问题. 若是邮寄出错了, 咱们能够把电子版素材发过去, 在当地印刷出来也来得及, 也容许电影院自行印刷更合适的介质.

二维码经过影院后台推送, 影院自行粘贴, 这也是你们看一些大型活动二维码和背后的物料是分离的缘由.

看起来没啥问题, 实际落地效果基本符合预期. 但接着就进入到一些更具体的业务场景

需求第2阶段

进入活动落地页, 完成简单任务或直接领取优惠券, 领取优惠券以后指望支持后退, 若是咱们什么额外的都不作, 左上角什么都没有, 没有后退, 只能点右上角关闭, 再进来又是活动页.

用户就会疑问, 我领了优惠券到哪里去花呢?

因此需求确定会要求支持回退, 跳转到能消费优惠券的地方. 以前在掘金小程序开发者大会当中有讲师也提到过, 左上角的后退按钮对用户体验和数据的提高很重要的, 前端就须要考虑怎么实现这个需求.

最笨的办法: 先到首页, 首页再作一次重定向到活动页, 通常咱们指望后退到首页.

另外一个方案是自定义导航, 至关于页面是全屏的, 只是在右上角浮出2个小程序自身的按钮, 关闭和菜单按钮. 但这个方案有一些限制, 咱们最后没有用这个方案.

使用第一个方案的话, 二维码变了, 虽然没超过128字节, 但已经印刷的二维码就不能用了, 这就麻烦了, 还得从新生成二维码, 从新印刷, 并粘贴上去.

若是真的是这样走一步看一步, 走到这确定出问题, 确定会吐槽.

更多需求

实际不只仅如此

• 指望能后退到别的页面
• 一家影院在不一样入口放置的二维码效果如何?
  • 指望知道影院入口的效果
• 参数愈来愈多, 长度超限怎么办?

相似的需求越多, 参数就会越多. 若是是方案B的二维码, 参数限制只有32位, 若是是方案A, 总长度128能稍好一些, 但反复生成二维码颇有可能超过10w个数量限制.

最终会发现产出物料后改需求是一个常态, 咱们如何才能支持这个常态.

短网址服务

这时就回到了咱们提到的那个有意思的方案C, 咱们提交的参数是一个地址, 但它生成的二维码实际存储的是另一个地址, 很像短网址服务有没有. 咱们是否是也能够作一个这样的服务, 客户端的方案以下

• 入口: path: 'pages/jump?id=3a5fc8', id参数表示一个短网址的id, 这个用于生成二维码
• pages/jump 页面
  • 请求后端 wx.request({ url: 'xxxx', data: '3a5fc8' })
    • 指望获取到 { path: 'pages/movie/index?go=pages/onecent/index?cinema=15280&utm_source=foo' }
  • wx.redirectTo({ url: path })

这个 path 就没什么长度限制, 这样就能够完美的控制后退导航行为, 以及增长相似 utm_source 的埋点参数, 用于跟踪放在影院的不一样入口扫码意愿的差别.

作这些须要前端 后端 PM总体协商合做.

接下来看看服务端咱们指望它有什么功能

• 建立短网址 API: 由于咱们会批量建立
• 批量查询和修改 API: 由于是批量建立的, 咱们又有产出物料后改需求的常态
• 短网址的额外信息
  • 类别: 同一活动属于同一类别
  • 附加信息: Map结构, 好比包含 影院ID, 后退的页面地址, 埋点信息等, 为了通用性

最终咱们生成的二维码包含的 path 信息是: pages/jump?id=3a5fc8, 咱们只须要到短网址服务后台修改就能够控制它的行为.

更多

这个方案需求是解决了, 但因为多了个中间页, 可能界面是白的, 最多加个loading态, 改善下体验, 但时间上可能会有点问题, 比原来要慢些.

通常的解决办法, 首次进入缓存, 第2次进入直接使用缓存数据, 但仍旧发一个请求出去, 响应了再更新缓存, 这样不管缓存过时仍是别的情况, 请求都不会阻塞.

更进一步, 咱们能够生成一个http的地址, 其它的程序也能扫码成功, 不限于微信.

http://m.maoyan.com/jump?id=3a5fc8
复制代码

好比咱们指望使用一个二维码, 任何终端扫码都能进入活动. 咱们指望微信扫码打开小程序, 这样体验更好, 其它程序扫码打开h5页面.

微信扫普通二维码能打开小程序, 这个能力来自小程序管理后台, 叫"扫普通连接二维码打开小程序", 只须要配置一个URL模式, 模式限制数量10个.

有些公司可能小程序公众号参与者权限互相有隔离, 因此实施这个会有一些沟通工做.

小结

• 需求是多变的: 基础需求, 后退, 埋点等诉求, 这是一种常态
• 物料产出后难以修改: 随着需求变动而从新生产物料是不现实的
• 短网址服务: 最终的方案

咱们如今已经能让用户扫码, 进入活动页, 领取优惠券, 后退回到首页, 完成购票流程.

但不是全部用户都会走购票流程, 好比用户如今想去吃饭, 就会关闭小程序走了, 这种状况咱们 就只能等用户来购票.

显然咱们不能等用户来购票, 这样在体验上仍是差点, 用户领取了优惠券, 可是没有消费是咱们不肯意看到的.

优惠券和用户触达通知

咱们指望用户领了优惠券以后能通知用户, 方案有两种

• 微信支付优惠券
• 自建优惠券

微信支付优惠券

微信支付 预充值代金券

• 入口: 消息列表 "微信支付" 服务号
• 时机: 领取时, 即将到期时
• 满减 商品限制 预算限制
• 防刷 对帐 消耗记录

须要先充值, 会占用一些现金, 有作PM的同窗须要注意这点

前端须要注意商品限制, 有这种限制的时候, 须要前端把商品标记传给微信支付API

自建优惠券

有些公司可能不太愿意提早垫付资金, 这样对现金流有要求, 那么就可能须要自建优惠券.

若是要作到相似微信支付优惠券的体验, 咱们须要作

• 入口: 消息列表 "服务通知"
• 时机: 自由
• 满减 限制商品 预算限制
• 防刷 对帐 消耗记录

限制

• 要使用服务通知, 全部消息都须要凭证, 凭证经过表单 form 标签 和支付能收集到, 也就是用户必须有点击行为, 7天有效期
• 前端须要刻意在小程序上尽可能收集这些凭证, 由于需求是多变的, 可能一开始说发2次就行, 后续又说须要发4次
• 客诉, 用户以为骚扰, 会给微信投诉, 微信会直接删除消息模板, 消息就发不出去, 投诉再多就可能触犯了小程序的规定, 有封号可能
  • 必定要告知给PM, 特别是业务流程须要这个通知, 必定不要作违规的试探行为
• 防刷 对帐对于后端来讲工做量仍是很大的

小结

自建优惠劵须要作的工做不少, 初创公司建议直接使用微信支付优惠券, 特别是合规 防刷 对帐

自建优惠券, 前端须要注意多收集凭证, 经过 form + button

线上监控发现的问题

至此, 咱们的活动上线, 用户领了优惠券后, 既能现场买票, 也能够过一段时间收到通知, 得知还有优惠券能够去买票.

上线后还须要观察服务自己有什么意外, 因为咱们对于多数的异步调用都作了监控, 因此...

没法完成登陆

wx.getUserInfo() 的返回中包含 signature: 签名参数, 正常流程是返回了用户昵称 头像信息后须要进行数字签名并比对是否一致, 不一致就表示有问题, 通常是认为获取用户信息失败.

但实际中发现Android 5.x系统下的微信客户端, 若是用户昵称中若是包含 emoji 字符, 那么 signature 确定不一致. 此时用户昵称中的 emoji 字符实际ASCII值为 0xFEFE 这样的字符, 通常看起来是乱码.

解决方案: 除了等android 5.x基本消失, 就是如何符合上述条件, 能够忽略这个数字签名比对, 昵称只能获取到个大概, 基本够看.

任何微信接口调用可能失败

咱们调用了不少微信的接口, 好比 wx.login 相关, 生成二维码. 有时会超时, 小程序端上的表现是卡顿, 隔了好久提示网络错误, 偶发, 很难复现, 大概0.5%.

对于百万以上日活用户的app来讲, 这个问题仍是挺严重的, 有些用户若是点击后发现没响应, 就停在这了, 用户会认为你的小程序有问题, 直接关闭退出了.

调研的结论是网络问题, 微信这边给的方案是尝试用 api2.weixin.qq.com, 也就是咱们须要实现一个容灾 重试策略.

咱们最终实现了一个延迟重试的策略, 上线后调用微信接口的可用性从 99.5% 上升到 99.99%+.

cat监控系统

咱们用过的一些异常收集系统, 或者在系统出问题的时候, 收集系统也挂掉了, 或者不够实时, 或者没有合适的分类, 只见树不见林, 没法知道整个问题的状况, 不容易抓住重点.

咱们发现上述问题主要依赖一个叫cat的系统

github.com/dianping/ca…

基于java, 吞吐量 负载能力超强, 分类聚合知足需求

总结

• 咱们介绍了小程序二维码的约束
• 需求变化致使咱们须要支持产出物料后改需求, 咱们经过短网址服务来支持这个业务
• 咱们指望促销活动能产生用户消费, 须要通知用户使用优惠券, 介绍了两种方案的利弊, 成熟的公司可能两种方案都要支持
• 上线的异步调用 远程调用监控, 发现的2个问题及其解决方案.

回顾下标题, 打码指南: 由猫眼线下扫码1分购谈起, 靠谱的线下扫码活动须要技术团队提供那些支撑.

咱们讨论了须要开发什么样的系统, 关注什么流程, 那些约束条件须要周知给各方. 由于前端全部的工做都是在一个宿主环境下, 都有不少的限制, 咱们须要在各类限制的条件下完成各类需求.

Q&A

1. 为何没有使用自定义导航栏的方案

自定义导航栏, navigationStyle: custom 1.9.5 开始支持, 但须要 整个小程序 全部页面都自定义导航栏才行, 这对于咱们的场景不太适用, 只能做为长远打算

2. 能讲下延迟重试策略么?

根据咱们的监控统计, 请求微信的接口95%的都会在650ms内响应, 大于这个时间最终请求超时的几率就很大了, 因此最终策略是

一旦请求在650ms内未完成, 当即发出后备请求, 直到任意一个得到响应, 而且是正确的响应内容

这个策略咱们开发成了一个superagent插件, 后续会考虑开源出来

3. 这么看作线下扫码活动成本 门槛仍是有点高, 有什么别的方法能减小这方面成本?

咱们最初还考虑过另外一种方案, 能够经过定位, 让用户选择附近商家, 会在体验 运营自由度上有折扣, 但能够规避各类二维码物料的问题.

不过最后仍是没有用这个方案, 若是可接受体验上的折扣, 仍是能够用这种方案的.

其次就是把上文提到的二维码相关功能作成服务开放出来, 我也有关注提供这方面支持的互联网产品, 目前看未有发现.

上面的文字版的总结，也推荐你们若有时间的话观看原版视频分享，如今已经上传到了 Bilibili，连接为：www.bilibili.com/video/av348… ，欢迎你们观看学习和收藏～