写点什么

美团扫码付小程序的优化实践

  • 2020-02-25
  • 本文字数:3646 字

    阅读完需:约 12 分钟

美团扫码付小程序的优化实践

短短几年的时间,微信小程序已经从一颗小小的萌芽成长为参天大树,形成了较大规模的开发者生态系统,尤其是在支付、线下垂直领域潜力巨大。


作为领先的生活服务平台,美团的技术团队在小程序领域也进行了很多的探索和实践。像 mpvue 就是一款使用 Vue.js 开发微信小程序的前端框架,而且已经在美团点评多个实际业务项目中得到了验证,详细介绍大家可以阅读《用Vue.js开发微信小程序:开源框架mpvue解析》一文。目前,mpvue 已经开源,项目地址是:https://github.com/Meituan-Dianping/mpvue。


本文将介绍扫码付小程序的实践,根据美团前端工程师陈瑶在美团第31期技术沙龙(点击可以查看这次沙龙四场演讲的 Slides 和视频)的演讲《金融扫码付 H5 迁移小程序拓荒之旅》整理而成。


什么是扫码付小程序?

美团扫码付是一款面向 C 端消费者推出的线下收单业务,相信大家已经在线下很多餐馆和其他生活服务商家体验过了。这项业务主要就是通过小程序提供服务的,而在实际场景中,用户先使用微信“扫一扫”功能,扫描商家二维码,系统会自动调用扫码付小程序,进入支付页面,最后输入金额完成商品的支付。


目标及数据分析

支付服务最核心的指标,显然就是用户支付成功的占比,我们称之为支付转化率。对扫码付业务而言,支付转化率的百分比越高,扫码付业务的营业额也就越高,其带来的收益是正相关的。因此提升扫码付小程序的支付转化率,就成为我们技术团队的重要工作。经过数据分析,我们发现转化率流失主要存在于以下两个环节:


  • 扫码到进入小程序环节(外部环节)

  • 进入小程序到支付环节(内部环节)


从扫码到进入小程序环节,微信会完成小程序基本信息获取、资源准备(代码下载或更新)等准备事项。在准备事项中,如果准备失败或等待时间过长,就会导致用户离开,这部分由微信控制的环节,我们称之为外部环节。


在进入小程序到支付环节,页面会进行渲染、数据请求等,如果渲染时间长、数据请求时间长也容易导致用户离开,同样,如果数据请求失败也会造成用户使用过程的终止,这部分由我们美团扫码付技术团队控制的环节,称之为内部环节。


如何提升外部环节转化率?

对于小程序开发者而言,扫码到小程序调起这个环节是黑盒的,我们无法得知其中的细节。而我们在扫码付小程序中尝试和微信的同学做了一次梳理,发现扫码付小程序在外部环节的丢失率较高,查询数据后,我们发现其中大部分用户手动点击了右上角的退出。


从业务视角出发,用户使用扫码付小程序,可认为他们有强需求进行支付,而造成用户手动点击退出的部分原因可能是等待时间过长。而在这个环节对时间造成影响更多的是资源准备,即小程序代码下载或者更新的行为。根据经验,影响下载和更新时间可能的因素包括两个方面:一个是网络,另一个是代码包。


因为用户的网络是我们无法控制的,只能尝试从代码包开始下手。而在当时未使用分包的情况下,我们的主包大小约为 3M,这意味着新用户和无缓存小程序用户均需要在首次使用时等待下载 3M 左右的包。在这种情况下,虽然用户享受了小程序离线缓存包的福利,却丢失了大部分新用户的体验。于是我们尝试从包代码层面做一些优化:


  • 增加分包加载机制。用户在使用扫码付业务时会按需进行加载,优化小程序首次启动的下载时间。

  • 减小主包和分包大小。按照空主包的概念进行优化。在进行分包加载机制后,主包因为无法最小化而影响首次下载时间。一方面,原有的 3M 整包中,图片大小占用了 50%大小,我们将所有的内含二进制和 Base64 图片分发到了 CDN;另一方面,部分可移出的业务分发到了其他分包。


在做了这些事情后,扫码付分包从原先的整包 3M 缩减到了 361K(主包 300K+分包 61K),而外部环节的转化率也提升了 3%。虽然转化率提升了,但前置环节的转化率仍然有部分丢失,理论上继续缩减 300K 的主包能有效提升,但由于业务性质的原因无法再继续缩减,于是我们向微信小程序提出了独立分包的概念:用户在使用独立分包时无需下载主包。



通过独立分包加载,程序使用期间下载更新阶段,只需要加载 61K 的分包大小。目前这个功能还在灰度阶段,扫码付小程序团队也在作为第一批的内测用户进行体验,优化效果在之后的实践中,我们也会分享出来,大家可关注美团技术团队公众号,持续关注我们。

如何提升内部环节转化率?

在进入小程序到支付这个环节,属于我们的业务流程。在这个环节中的转化率丢失虽然我们能够掌控,但是必须有所依据,才能对症下药。所以我们做了一些数据监控:


  • 业务核心流程监控。业务核心流程指用户进入小程序后所涉及的影响最终支付的中间流程,中间流程的丢失会直接影响业务整个转化率丢失,所以这里必须进行监控。而业务核心流程监控需要可监控的具体指标,我们对进入小程序和支付进行了关键动作拆解,从开始扫码到用户看到页面,再到点击支付、初始化订单、支付成功。拆解完这些关键动作,再针对每一步可控环节,进行技术指标的拆解。从入口到出口的每一步制定关键指标(扫码加载转化率、点击意愿等,见下图),形成一个至上而下的漏斗,产出多个可量化指标,来做业务流程的监控。对于这部分可量化指标,可以通过长期的观察分析来提升转化率。



  • 异常监控。页面的任何异常都可能导致支付页面的渲染失败,从而无法正常支付。我们对页面的接口异常、微信 API 异常进行了监控。接口异常可在 API(wx.request)的 fail 函数中直接捕获,从而上报监控;对于接口超时,则只能通过全局的 app.json 进行全局设置(默认 60s,时间过长,对用户体验较差),此前我们曾尝试在小程序中设置全局的 5s 请求超时,但实际应用中并非所有场景需要设置统一的超时,最终我们单独封装了接口请求超时。微信 API 的异常通过微信的一些 fail 中进行监控即可。



  • 性能监控。小程序内部转化环节中关注进入小程序后的白屏时间和可交互时间。内部白屏时间从 onLoad 处打点,到页面 onReady 处结束;内部可交互时间从 onLoad 处打点,到页面数据请求结束后的可点击支付时间截止。日常监控中,我们也发现了一些问题,例如接口调用超时、接口调用失败,这些问题会导致页面流程终止。针对这些问题我们做了一些优化:

  • 接口合并。支付页面的外网链路接口请求数量较多,任意一个接口的失败都会导致问题,合并接口则可以减少问题出现概率,提升中间流程的转化率。增加重试机制。在出现接口异常的情况下,会直接导致页面阻塞,如果通过重试能成功,则可以提升转化率。整个流程中可重试的有两类:自有的接口请求异常,小程序 API 调用异常。


对于这两类异常,在接口超时、调用失败时采取重试。而为了避免在极端情况下服务端流量陡增、峰值倍数增加,页面的可重试次数会在前置获取全局配置时根据“可重试次数”进行控制,并且每次重试需要在一段时间后用户手动触发。超过重试次数时,则流程终止。

如何监控内部和外部环节?

前面我们也提到,对于小程序开发者而言,扫码到小程序调起这个环节是黑盒的,我们开发者无法得知此处的细节,所以说在监控外部环节这方面我们开发者似乎可做的事情屈指可数。但是,不知道细心的同学有没有发现,微信在每次扫码后会给我们在 query 参数上附带一个 scancode_time 字段。其实这个字段表示的是用户在使用扫一扫时微信服务端记录的时间,所以基于这个字段的考量,我们做了如下尝试,针对以下两个参数值分别做了实时监控:


  • 支付页面的白屏时间(用户看到首屏的客户端时间—用户微信扫一扫服务端时间+服务端客户端差额时间)。

  • 支付页面的用户可交互时间(页面 Loading 完毕时间—用户微信扫一扫服务端时间+服务端客户端差额时间)。


由于客户端的时间戳是获取本地手机系统的时间,可能存在差异。所以为了保证上报的准确性,我们在每次 onLoad 的时候取了一次我们服务端的时间,记录了客户端的时间与服务端的一个时间差额,并且在后续所有涉及到服务端的时间都参照这个时间差额做计算(网络 100-200ms 级别的传输时延,暂可忽略)。


但由于我们扫码付小程序的特殊应用场景就是为了保障用户进行快速可靠的支付,既然在外部环节可控度不高,那是不是可以考虑在内部的业务流程方面把监控统计做的细粒度一点,做到能对每一个可能影响到支付的环节有数据可循呢?我们针对这个方向,区别于传统的 PV、UV 统计,并对业务上报做了如下分类:


  • 根据上报的场景划分:实时性监控部分与统计部分。

  • 根据上报的类型划分:Error 类型、Event 类型(普通生命周期事件)、Metric 类型(自定义 Event 类型,维度可自定义)、自定义测速类型(延时趋势与分布)。


基于上述方案的探索,我们团队基本上做到了对可能影响支付环节的很多业务指标,进行了整体的把控。从而在下一步,针对每个潜在的可优化点做进一步思考与考量,然后作出及时的策略优化与更新。通过对扫码付小程序的探索,我们积累了很多优化经验。美团的价值观是追求卓越,对于能优化的方面,我们还会进一步去探索,也欢迎更多的同学跟我们一起讨论。

作者简介

  • 陈瑶,2015 年校招入职美团,此前参与过美团平台移动端触屏版的前端开发工作,从 0 到 1 参与了智能支付应用层的前端建设工作,现负责美团收单业务扫码付小程序业务。


2020-02-25 20:32833

评论

发布
暂无评论
发现更多内容

人人能读懂redux原理剖析

夏天的味道123

前端 React

LeetCode题解:633. 平方数之和,双指针,JavaScript,详细注释

Lee Chen

JavaScript 算法 LeetCode

开发一款wordpress插件并发布到官方插件库完全指南,小白也可以

咖啡教室

网心科技以11.3%的市场份额跻身IDC中国边缘公有云市场前三

网心科技

边缘计算 IDC 边缘云 边缘云原生

2023前端二面手写面试题总结

helloworld1024fd

JavaScript 前端

金融与科技融合发展,将技术转化成生产力是重中之重

镜舟科技

数据库 数据库·

前端二面高频react面试题集锦

夏天的味道123

前端 React

2023-02-23:请用go语言调用ffmpeg,解码mp4文件并保存为YUV420P格式文件。

福大大架构师每日一题

golang ffmpeg 福大大

产品经理,项目经理,FTO

laofo

DevOps cicd 敏捷开发 研发效能 持续交付

Node.js实现大文件断点续传

coder2028

JavaScript 前端

JS继承有哪些,你能否手写其中一两种呢?

helloworld1024fd

JavaScript 前端

字节前端二面高频vue面试题整理

yyds2026

Vue 前端

StarRocks携手零洞科技,助力碧桂园物业企业微信数字化项目

StarRocks

数据库 开源 互联网

Window 的 PHP XAMPP 安装 mongodb 的扩展

HoneyMoose

用es6的class类单例模式封装canvas环形进度条

咖啡教室

使用一个文件集中管理你的 Nuget 依赖版本号

newbe36524

C# Docker Kubernetes

大模型时代的异构计算平台

Baidu AICLOUD

大模型训练 异构计算

一文读透react精髓

xiaofeng

前端 React

前端常见手写面试题集锦

helloworld1024fd

JavaScript 前端

Vue模板是怎样编译的

yyds2026

Vue 前端

那些高级前端是如何回答面试题的

Geek_02d948

JavaScript 前端

走进RocketMQ(一)整体架构与设计

白裤

Java RocketMQ RocketMQ整体架构 RocketMQ设计

设计模式第八讲:观察者模式和中介者模式详解

C++后台开发

数据结构 设计模式 后端开发 Linux服务器开发 C++开发

Continuous profiling 拯救了 Victoria Metrics

golang 性能优化 可观测性 Prometheus 性能分析

会声会影2023官方试用版更新下载功能详细介绍

茶色酒

会声会影2023

ChatGPT热潮背后,金融行业大模型应用路在何方?——金融行业大模型应用探索

易观分析

金融 科技

【AAAI 2023】针对视频分类的知识迁移

Zilliz

计算机视觉

会声会影2023简体中文试用版下载

茶色酒

会声会影2023

火山引擎推出一站式小程序监控方案

字节跳动终端技术

fastposter v2.12.0 ChatGPT都推荐的海报生成器

物有本末

fastposter 海报生成器 海报生成

高频js手写题之实现数组扁平化、深拷贝、总线模式

helloworld1024fd

JavaScript 前端

美团扫码付小程序的优化实践_文化 & 方法_美团技术团队_InfoQ精选文章