打碼指南-由貓眼線下掃碼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分購談起，分享了靠譜的線下掃碼活動須要技術團隊提供哪些⽀支撐，這就是此次活動的內容。