美團(tuán)掃碼付小程序開(kāi)發(fā)實(shí)踐,美團(tuán)掃碼購(gòu)小程序開(kāi)發(fā)實(shí)例
短短幾年的時(shí)間,微信小程序已經(jīng)從一顆小小的萌芽成長(zhǎng)為參天大樹(shù),形成了較大規(guī)模的開(kāi)發(fā)者生態(tài)系統(tǒng),尤其是在支付、線(xiàn)下垂直領(lǐng)域潛力巨大。
作為領(lǐng)先的生活服務(wù)平臺(tái),美團(tuán)的技術(shù)團(tuán)隊(duì)在小程序領(lǐng)域也進(jìn)行了很多的探索和實(shí)踐。像mpvue就是一款使用Vue.js開(kāi)發(fā)微信小程序的前端框架,而且已經(jīng)在美團(tuán)點(diǎn)評(píng)多個(gè)實(shí)際業(yè)務(wù)項(xiàng)目中得到了驗(yàn)證,詳細(xì)介紹大家可以閱讀《 用Vue.js開(kāi)發(fā)微信小程序:開(kāi)源框架mpvue解析 》一文。目前,mpvue已經(jīng)開(kāi)源,項(xiàng)目地址是: https://github.com/Meituan-Dianping/mpvue。
本文將介紹掃碼付小程序的實(shí)踐,根據(jù)美團(tuán)前端工程師陳瑤在美團(tuán)第31期技術(shù)沙龍(點(diǎn)擊可以查看這次沙龍四場(chǎng)演講的Slides和視頻)的演講《金融掃碼付H5遷移小程序拓荒之旅》整理而成。
什么是美團(tuán)掃碼付小程序?美團(tuán)掃碼付是一款面向C端消費(fèi)者推出的線(xiàn)下收單業(yè)務(wù),相信大家已經(jīng)在線(xiàn)下很多餐館和其他生活服務(wù)商家體驗(yàn)過(guò)了。這項(xiàng)業(yè)務(wù)主要就是通過(guò)小程序提供服務(wù)的,而在實(shí)際場(chǎng)景中,用戶(hù)先使用微信“掃一掃”功能,掃描商家二維碼,系統(tǒng)會(huì)自動(dòng)調(diào)用掃碼付小程序,進(jìn)入支付頁(yè)面,最后輸入金額完成商品的支付。
目標(biāo)及數(shù)據(jù)分析支付服務(wù)最核心的指標(biāo),顯然就是用戶(hù)支付成功的占比,我們稱(chēng)之為支付轉(zhuǎn)化率。對(duì)掃碼付業(yè)務(wù)而言,支付轉(zhuǎn)化率的百分比越高,掃碼付業(yè)務(wù)的營(yíng)業(yè)額也就越高,其帶來(lái)的收益是正相關(guān)的。因此提升掃碼付小程序的支付轉(zhuǎn)化率,就成為我們技術(shù)團(tuán)隊(duì)的重要工作。經(jīng)過(guò)數(shù)據(jù)分析,我們發(fā)現(xiàn)轉(zhuǎn)化率流失主要存在于以下兩個(gè)環(huán)節(jié):
- 掃碼到進(jìn)入小程序環(huán)節(jié)(外部環(huán)節(jié))
- 進(jìn)入小程序到支付環(huán)節(jié)(內(nèi)部環(huán)節(jié))
從掃碼到進(jìn)入小程序環(huán)節(jié),微信會(huì)完成小程序基本信息獲取、資源準(zhǔn)備(代碼下載或更新)等準(zhǔn)備事項(xiàng)。在準(zhǔn)備事項(xiàng)中,如果準(zhǔn)備失敗或等待時(shí)間過(guò)長(zhǎng),就會(huì)導(dǎo)致用戶(hù)離開(kāi),這部分由微信控制的環(huán)節(jié),我們稱(chēng)之為外部環(huán)節(jié)。
在進(jìn)入小程序到支付環(huán)節(jié),頁(yè)面會(huì)進(jìn)行渲染、數(shù)據(jù)請(qǐng)求等,如果渲染時(shí)間長(zhǎng)、數(shù)據(jù)請(qǐng)求時(shí)間長(zhǎng)也容易導(dǎo)致用戶(hù)離開(kāi),同樣,如果數(shù)據(jù)請(qǐng)求失敗也會(huì)造成用戶(hù)使用過(guò)程的終止,這部分由我們美團(tuán)掃碼付技術(shù)團(tuán)隊(duì)控制的環(huán)節(jié),稱(chēng)之為內(nèi)部環(huán)節(jié)。
如何提升外部環(huán)節(jié)轉(zhuǎn)化率?對(duì)于小程序開(kāi)發(fā)者而言,掃碼到小程序調(diào)起這個(gè)環(huán)節(jié)是黑盒的,我們無(wú)法得知其中的細(xì)節(jié)。而我們?cè)趻叽a付小程序中嘗試和微信的同學(xué)做了一次梳理,發(fā)現(xiàn)掃碼付小程序在外部環(huán)節(jié)的丟失率較高,查詢(xún)數(shù)據(jù)后,我們發(fā)現(xiàn)其中大部分用戶(hù)手動(dòng)點(diǎn)擊了右上角的退出。
從業(yè)務(wù)視角出發(fā),用戶(hù)使用掃碼付小程序,可認(rèn)為他們有強(qiáng)需求進(jìn)行支付,而造成用戶(hù)手動(dòng)點(diǎn)擊退出的部分原因可能是等待時(shí)間過(guò)長(zhǎng)。而在這個(gè)環(huán)節(jié)對(duì)時(shí)間造成影響更多的是資源準(zhǔn)備,即小程序代碼下載或者更新的行為。根據(jù)經(jīng)驗(yàn),影響下載和更新時(shí)間可能的因素包括兩個(gè)方面:一個(gè)是網(wǎng)絡(luò),另一個(gè)是代碼包。
因?yàn)橛脩?hù)的網(wǎng)絡(luò)是我們無(wú)法控制的,只能?chē)L試從代碼包開(kāi)始下手。而在當(dāng)時(shí)未使用分包的情況下,我們的主包大小約為3M,這意味著新用戶(hù)和無(wú)緩存小程序用戶(hù)均需要在首次使用時(shí)等待下載3M左右的包。在這種情況下,雖然用戶(hù)享受了小程序離線(xiàn)緩存包的福利,卻丟失了大部分新用戶(hù)的體驗(yàn)。于是我們嘗試從包代碼層面做一些優(yōu)化:
- 增加分包加載機(jī)制。用戶(hù)在使用掃碼付業(yè)務(wù)時(shí)會(huì)按需進(jìn)行加載,優(yōu)化小程序首次啟動(dòng)的下載時(shí)間。
- 減小主包和分包大小。按照空主包的概念進(jìn)行優(yōu)化。在進(jìn)行分包加載機(jī)制后,主包因?yàn)闊o(wú)法最小化而影響首次下載時(shí)間。一方面,原有的3M整包中,圖片大小占用了50%大小,我們將所有的內(nèi)含二進(jìn)制和Base64圖片分發(fā)到了CDN;另一方面,部分可移出的業(yè)務(wù)分發(fā)到了其他分包。
在做了這些事情后,掃碼付分包從原先的整包3M縮減到了361K(主包300K+分包61K),而外部環(huán)節(jié)的轉(zhuǎn)化率也提升了3%。雖然轉(zhuǎn)化率提升了,但前置環(huán)節(jié)的轉(zhuǎn)化率仍然有部分丟失,理論上繼續(xù)縮減300K的主包能有效提升,但由于業(yè)務(wù)性質(zhì)的原因無(wú)法再繼續(xù)縮減,于是我們向微信小程序提出了獨(dú)立分包的概念:用戶(hù)在使用獨(dú)立分包時(shí)無(wú)需下載主包。
通過(guò)獨(dú)立分包加載,程序使用期間下載更新階段,只需要加載61K的分包大小。目前這個(gè)功能還在灰度階段,掃碼付小程序團(tuán)隊(duì)也在作為第一批的內(nèi)測(cè)用戶(hù)進(jìn)行體驗(yàn),優(yōu)化效果在之后的實(shí)踐中,我們也會(huì)分享出來(lái),大家可關(guān)注美團(tuán)技術(shù)團(tuán)隊(duì)公眾號(hào),持續(xù)關(guān)注我們。
如何提升內(nèi)部環(huán)節(jié)轉(zhuǎn)化率?在進(jìn)入小程序到支付這個(gè)環(huán)節(jié),屬于我們的業(yè)務(wù)流程。在這個(gè)環(huán)節(jié)中的轉(zhuǎn)化率丟失雖然我們能夠掌控,但是必須有所依據(jù),才能對(duì)癥下藥。所以我們做了一些數(shù)據(jù)監(jiān)控:
- 業(yè)務(wù)核心流程監(jiān)控。業(yè)務(wù)核心流程指用戶(hù)進(jìn)入小程序后所涉及的影響最終支付的中間流程,中間流程的丟失會(huì)直接影響業(yè)務(wù)整個(gè)轉(zhuǎn)化率丟失,所以這里必須進(jìn)行監(jiān)控。而業(yè)務(wù)核心流程監(jiān)控需要可監(jiān)控的具體指標(biāo),我們對(duì)進(jìn)入小程序和支付進(jìn)行了關(guān)鍵動(dòng)作拆解,從開(kāi)始掃碼到用戶(hù)看到頁(yè)面,再到點(diǎn)擊支付、初始化訂單、支付成功。拆解完這些關(guān)鍵動(dòng)作,再針對(duì)每一步可控環(huán)節(jié),進(jìn)行技術(shù)指標(biāo)的拆解。從入口到出口的每一步制定關(guān)鍵指標(biāo)(掃碼加載轉(zhuǎn)化率、點(diǎn)擊意愿等,見(jiàn)下圖),形成一個(gè)至上而下的漏斗,產(chǎn)出多個(gè)可量化指標(biāo),來(lái)做業(yè)務(wù)流程的監(jiān)控。對(duì)于這部分可量化指標(biāo),可以通過(guò)長(zhǎng)期的觀(guān)察分析來(lái)提升轉(zhuǎn)化率。
- 異常監(jiān)控。頁(yè)面的任何異常都可能導(dǎo)致支付頁(yè)面的渲染失敗,從而無(wú)法正常支付。我們對(duì)頁(yè)面的接口異常、微信API異常進(jìn)行了監(jiān)控。接口異??稍贏(yíng)PI(wx.request)的fail函數(shù)中直接捕獲,從而上報(bào)監(jiān)控;對(duì)于接口超時(shí),則只能通過(guò)全局的app.json進(jìn)行全局設(shè)置(默認(rèn)60s,時(shí)間過(guò)長(zhǎng),對(duì)用戶(hù)體驗(yàn)較差),此前我們?cè)鴩L試在小程序中設(shè)置全局的5s請(qǐng)求超時(shí),但實(shí)際應(yīng)用中并非所有場(chǎng)景需要設(shè)置統(tǒng)一的超時(shí),最終我們單獨(dú)封裝了接口請(qǐng)求超時(shí)。微信API的異常通過(guò)微信的一些fail中進(jìn)行監(jiān)控即可。
-
性能監(jiān)控。小程序內(nèi)部轉(zhuǎn)化環(huán)節(jié)中關(guān)注進(jìn)入小程序后的白屏?xí)r間和可交互時(shí)間。內(nèi)部白屏?xí)r間從onLoad處打點(diǎn),到頁(yè)面onReady處結(jié)束;內(nèi)部可交互時(shí)間從onLoad處打點(diǎn),到頁(yè)面數(shù)據(jù)請(qǐng)求結(jié)束后的可點(diǎn)擊支付時(shí)間截止。
-
日常監(jiān)控中,我們也發(fā)現(xiàn)了一些問(wèn)題,例如接口調(diào)用超時(shí)、接口調(diào)用失敗,這些問(wèn)題會(huì)導(dǎo)致頁(yè)面流程終止。針對(duì)這些問(wèn)題我們做了一些優(yōu)化:
-
接口合并。支付頁(yè)面的外網(wǎng)鏈路接口請(qǐng)求數(shù)量較多,任意一個(gè)接口的失敗都會(huì)導(dǎo)致問(wèn)題,合并接口則可以減少問(wèn)題出現(xiàn)概率,提升中間流程的轉(zhuǎn)化率。
-
增加重試機(jī)制。在出現(xiàn)接口異常的情況下,會(huì)直接導(dǎo)致頁(yè)面阻塞,如果通過(guò)重試能成功,則可以提升轉(zhuǎn)化率。整個(gè)流程中可重試的有兩類(lèi):自有的接口請(qǐng)求異常,小程序API調(diào)用異常。
對(duì)于這兩類(lèi)異常,在接口超時(shí)、調(diào)用失敗時(shí)采取重試。而為了避免在極端情況下服務(wù)端流量陡增、峰值倍數(shù)增加,頁(yè)面的可重試次數(shù)會(huì)在前置獲取全局配置時(shí)根據(jù)“可重試次數(shù)”進(jìn)行控制,并且每次重試需要在一段時(shí)間后用戶(hù)手動(dòng)觸發(fā)。超過(guò)重試次數(shù)時(shí),則流程終止。
如何監(jiān)控內(nèi)部和外部環(huán)節(jié)?前面我們也提到,對(duì)于小程序開(kāi)發(fā)者而言,掃碼到小程序調(diào)起這個(gè)環(huán)節(jié)是黑盒的,我們開(kāi)發(fā)者無(wú)法得知此處的細(xì)節(jié),所以說(shuō)在監(jiān)控外部環(huán)節(jié)這方面我們開(kāi)發(fā)者似乎可做的事情屈指可數(shù)。但是,不知道細(xì)心的同學(xué)有沒(méi)有發(fā)現(xiàn),微信在每次掃碼后會(huì)給我們?cè)趒uery參數(shù)上附帶一個(gè)scancode_time字段。其實(shí)這個(gè)字段表示的是用戶(hù)在使用掃一掃時(shí)微信服務(wù)端記錄的時(shí)間,所以基于這個(gè)字段的考量,我們做了如下嘗試,針對(duì)以下兩個(gè)參數(shù)值分別做了實(shí)時(shí)監(jiān)控:
- 支付頁(yè)面的白屏?xí)r間(用戶(hù)看到首屏的客戶(hù)端時(shí)間—用戶(hù)微信掃一掃服務(wù)端時(shí)間+服務(wù)端客戶(hù)端差額時(shí)間)。
- 支付頁(yè)面的用戶(hù)可交互時(shí)間(頁(yè)面Loading完畢時(shí)間—用戶(hù)微信掃一掃服務(wù)端時(shí)間+服務(wù)端客戶(hù)端差額時(shí)間)。
由于客戶(hù)端的時(shí)間戳是獲取本地手機(jī)系統(tǒng)的時(shí)間,可能存在差異。所以為了保證上報(bào)的準(zhǔn)確性,我們?cè)诿看蝟nLoad的時(shí)候取了一次我們服務(wù)端的時(shí)間,記錄了客戶(hù)端的時(shí)間與服務(wù)端的一個(gè)時(shí)間差額,并且在后續(xù)所有涉及到服務(wù)端的時(shí)間都參照這個(gè)時(shí)間差額做計(jì)算(網(wǎng)絡(luò)100-200ms級(jí)別的傳輸時(shí)延,暫可忽略)。
但由于我們掃碼付小程序的特殊應(yīng)用場(chǎng)景就是為了保障用戶(hù)進(jìn)行快速可靠的支付,既然在外部環(huán)節(jié)可控度不高,那是不是可以考慮在內(nèi)部的業(yè)務(wù)流程方面把監(jiān)控統(tǒng)計(jì)做的細(xì)粒度一點(diǎn),做到能對(duì)每一個(gè)可能影響到支付的環(huán)節(jié)有數(shù)據(jù)可循呢?我們針對(duì)這個(gè)方向,區(qū)別于傳統(tǒng)的PV、UV統(tǒng)計(jì),并對(duì)業(yè)務(wù)上報(bào)做了如下分類(lèi):
- 根據(jù)上報(bào)的場(chǎng)景劃分:實(shí)時(shí)性監(jiān)控部分與統(tǒng)計(jì)部分。
- 根據(jù)上報(bào)的類(lèi)型劃分:Error類(lèi)型、Event類(lèi)型(普通生命周期事件)、Metric類(lèi)型(自定義Event類(lèi)型,維度可自定義)、自定義測(cè)速類(lèi)型(延時(shí)趨勢(shì)與分布)。
基于上述方案的探索,我們團(tuán)隊(duì)基本上做到了對(duì)可能影響支付環(huán)節(jié)的很多業(yè)務(wù)指標(biāo),進(jìn)行了整體的把控。從而在下一步,針對(duì)每個(gè)潛在的可優(yōu)化點(diǎn)做進(jìn)一步思考與考量,然后作出及時(shí)的策略?xún)?yōu)化與更新。通過(guò)對(duì)掃碼付小程序的探索,我們積累了很多優(yōu)化經(jīng)驗(yàn)。美團(tuán)的價(jià)值觀(guān)是追求卓越,對(duì)于能優(yōu)化的方面,我們還會(huì)進(jìn)一步去探索,也歡迎更多的同學(xué)跟我們一起討論。
第二部分:如何開(kāi)通一個(gè)小商店