美團掃碼付小程序的優化實踐

短短几年的時間，微信小程序已經從一顆小小的萌芽成長爲參天大樹，造成了較大規模的開發者生態系統，尤爲是在支付、線下垂直領域潛力巨大。

做爲領先的生活服務平臺，美團的技術團隊在小程序領域也進行了不少的探索和實踐。像mpvue就是一款使用Vue.js開發微信小程序的前端框架，並且已經在美團點評多個實際業務項目中獲得了驗證，詳細介紹你們能夠閱讀《用Vue.js開發微信小程序：開源框架mpvue解析》一文。目前，mpvue已經開源，項目地址是：https://github.com/Meituan-Dianping/mpvue。

本文將介紹掃碼付小程序的實踐，根據美團前端工程師陳瑤在美團第31期技術沙龍（點擊能夠查看此次沙龍四場演講的Slides和視頻）的演講《金融掃碼付H5遷移小程序拓荒之旅》整理而成。

圖片0

什麼是掃碼付小程序？

美團掃碼付是一款面向C端消費者推出的線下收單業務，相信你們已經在線下不少餐館和其餘生活服務商家體驗過了。這項業務主要就是經過小程序提供服務的，而在實際場景中，用戶先使用微信「掃一掃」功能，掃描商家二維碼，系統會自動調用掃碼付小程序，進入支付頁面，最後輸入金額完成商品的支付。

圖片1

目標及數據分析

支付服務最核心的指標，顯然就是用戶支付成功的佔比，咱們稱之爲支付轉化率。對掃碼付業務而言，支付轉化率的百分比越高，掃碼付業務的營業額也就越高，其帶來的收益是正相關的。所以提高掃碼付小程序的支付轉化率，就成爲咱們技術團隊的重要工做。通過數據分析，咱們發現轉化率流失主要存在於如下兩個環節：

• 掃碼到進入小程序環節（外部環節）
• 進入小程序到支付環節（內部環節）

從掃碼到進入小程序環節，微信會完成小程序基本信息獲取、資源準備（代碼下載或更新）等準備事項。在準備事項中，若是準備失敗或等待時間過長，就會致使用戶離開，這部分由微信控制的環節，咱們稱之爲外部環節。

在進入小程序到支付環節，頁面會進行渲染、數據請求等，若是渲染時間長、數據請求時間長也容易致使用戶離開，一樣，若是數據請求失敗也會形成用戶使用過程的終止，這部分由咱們美團掃碼付技術團隊控制的環節，稱之爲內部環節。

圖片2

如何提高外部環節轉化率？

對於小程序開發者而言，掃碼到小程序調起這個環節是黑盒的，咱們沒法得知其中的細節。而咱們在掃碼付小程序中嘗試和微信的同窗作了一次梳理，發現掃碼付小程序在外部環節的丟失率較高，查詢數據後，咱們發現其中大部分用戶手動點擊了右上角的退出。

從業務視角出發，用戶使用掃碼付小程序，可認爲他們有強需求進行支付，而形成用戶手動點擊退出的部分緣由多是等待時間過長。而在這個環節對時間形成影響更多的是資源準備，即小程序代碼下載或者更新的行爲。根據經驗，影響下載和更新時間可能的因素包括兩個方面：一個是網絡，另外一個是代碼包。

由於用戶的網絡是咱們沒法控制的，只能嘗試從代碼包開始下手。而在當時未使用分包的狀況下，咱們的主包大小約爲3M，這意味着新用戶和無緩存小程序用戶均須要在首次使用時等待下載3M左右的包。在這種狀況下，雖然用戶享受了小程序離線緩存包的福利，卻丟失了大部分新用戶的體驗。因而咱們嘗試從包代碼層面作一些優化：

• 增長分包加載機制。用戶在使用掃碼付業務時會按需進行加載，優化小程序首次啓動的下載時間。
• 減少主包和分包大小。按照空主包的概念進行優化。在進行分包加載機制後，主包由於沒法最小化而影響首次下載時間。一方面，原有的3M整包中，圖片大小佔用了50%大小，咱們將全部的內含二進制和Base64圖片分發到了CDN；另外一方面，部分可移出的業務分發到了其餘分包。

在作了這些事情後，掃碼付分包從原先的整包3M縮減到了361K（主包300K+分包61K），而外部環節的轉化率也提高了3%。雖然轉化率提高了，但前置環節的轉化率仍然有部分丟失，理論上繼續縮減300K的主包能有效提高，但因爲業務性質的緣由沒法再繼續縮減，因而咱們向微信小程序提出了獨立分包的概念：用戶在使用獨立分包時無需下載主包。

圖片3

經過獨立分包加載，程序使用期間下載更新階段，只須要加載61K的分包大小。目前這個功能還在灰度階段，掃碼付小程序團隊也在做爲第一批的內測用戶進行體驗，優化效果在以後的實踐中，咱們也會分享出來，你們可關注美團技術團隊公衆號，持續關注咱們。

如何提高內部環節轉化率？

在進入小程序到支付這個環節，屬於咱們的業務流程。在這個環節中的轉化率丟失雖然咱們可以掌控，可是必須有所依據，才能對症下藥。因此咱們作了一些數據監控：

• 業務核心流程監控。業務核心流程指用戶進入小程序後所涉及的影響最終支付的中間流程，中間流程的丟失會直接影響業務整個轉化率丟失，因此這裏必須進行監控。而業務核心流程監控須要可監控的具體指標，咱們對進入小程序和支付進行了關鍵動做拆解，從開始掃碼到用戶看到頁面，再到點擊支付、初始化訂單、支付成功。拆解完這些關鍵動做，再針對每一步可控環節，進行技術指標的拆解。從入口到出口的每一步制定關鍵指標（掃碼加載轉化率、點擊意願等，見下圖），造成一個至上而下的漏斗，產出多個可量化指標，來作業務流程的監控。對於這部分可量化指標，能夠經過長期的觀察分析來提高轉化率。

圖片4

• 異常監控。頁面的任何異常均可能致使支付頁面的渲染失敗，從而沒法正常支付。咱們對頁面的接口異常、微信API異常進行了監控。接口異常可在API（wx.request）的fail函數中直接捕獲，從而上報監控；對於接口超時，則只能經過全局的app.json進行全局設置（默認60s，時間過長，對用戶體驗較差），此前咱們曾嘗試在小程序中設置全局的5s請求超時，但實際應用中並不是全部場景須要設置統一的超時，最終咱們單獨封裝了接口請求超時。微信API的異常經過微信的一些fail中進行監控便可。

圖片5

• 性能監控。小程序內部轉化環節中關注進入小程序後的白屏時間和可交互時間。內部白屏時間從onLoad處打點，到頁面onReady處結束；內部可交互時間從onLoad處打點，到頁面數據請求結束後的可點擊支付時間截止。

• 平常監控中，咱們也發現了一些問題，例如接口調用超時、接口調用失敗，這些問題會致使頁面流程終止。針對這些問題咱們作了一些優化：

• 接口合併。支付頁面的外網鏈路接口請求數量較多，任意一個接口的失敗都會致使問題，合併接口則能夠減小問題出現機率，提高中間流程的轉化率。

• 增長重試機制。在出現接口異常的狀況下，會直接致使頁面阻塞，若是經過重試能成功，則能夠提高轉化率。整個流程中可重試的有兩類：自有的接口請求異常，小程序API調用異常。

對於這兩類異常，在接口超時、調用失敗時採起重試。而爲了不在極端狀況下服務端流量陡增、峯值倍數增長，頁面的可重試次數會在前置獲取全局配置時根據「可重試次數」進行控制，而且每次重試須要在一段時間後用戶手動觸發。超太重試次數時，則流程終止。

如何監控內部和外部環節？

前面咱們也提到，對於小程序開發者而言，掃碼到小程序調起這個環節是黑盒的，咱們開發者沒法得知此處的細節，因此說在監控外部環節這方面咱們開發者彷佛可作的事情屈指可數。可是，不知道細心的同窗有沒有發現，微信在每次掃碼後會給咱們在query參數上附帶一個scancode_time字段。其實這個字段表示的是用戶在使用掃一掃時微信服務端記錄的時間，因此基於這個字段的考量，咱們作了以下嘗試，針對如下兩個參數值分別作了實時監控：

• 支付頁面的白屏時間（用戶看到首屏的客戶端時間—用戶微信掃一掃服務端時間+服務端客戶端差額時間）。
• 支付頁面的用戶可交互時間（頁面Loading完畢時間—用戶微信掃一掃服務端時間+服務端客戶端差額時間）。

因爲客戶端的時間戳是獲取本地手機系統的時間，可能存在差別。因此爲了保證上報的準確性，咱們在每次onLoad的時候取了一次咱們服務端的時間，記錄了客戶端的時間與服務端的一個時間差額，而且在後續全部涉及到服務端的時間都參照這個時間差額作計算（網絡100-200ms級別的傳輸時延，暫可忽略）。

但因爲咱們掃碼付小程序的特殊應用場景就是爲了保障用戶進行快速可靠的支付，既然在外部環節可控度不高，那是否是能夠考慮在內部的業務流程方面把監控統計作的細粒度一點，作到能對每個可能影響到支付的環節有數據可循呢？咱們針對這個方向，區別於傳統的PV、UV統計，並對業務上報作了以下分類：

• 根據上報的場景劃分：實時性監控部分與統計部分。
• 根據上報的類型劃分：Error類型、Event類型（普通生命週期事件）、Metric類型（自定義Event類型，維度可自定義）、自定義測速類型（延時趨勢與分佈）。

基於上述方案的探索，咱們團隊基本上作到了對可能影響支付環節的不少業務指標，進行了總體的把控。從而在下一步，針對每一個潛在的可優化點作進一步思考與考量，而後做出及時的策略優化與更新。經過對掃碼付小程序的探索，咱們積累了不少優化經驗。美團的價值觀是追求卓越，對於能優化的方面，咱們還會進一步去探索，也歡迎更多的同窗跟咱們一塊兒討論。

做者簡介

陳瑤，2015年校招入職美團，此前參與過美團平臺移動端觸屏版的前端開發工做，從0到1參與了智能支付應用層的前端建設工做，現負責美團收單業務掃碼付小程序業務。

招聘

若是對咱們「智能支付大前端團隊」感興趣，可直接簡歷發送給陳小二同窗（chenyao05@meituan.com）。歡迎加入美團，跟咱們一塊兒探索將來。