開發 | 教你突破小程序模板消息的推送限制

模板消息是微信為小程序提供的一種通知手段。

但由於模板消息的推送數量限制，使得許多開發者忽略了它對於小程序的重要意義。今天，知曉程序（微信號 zxcx0101）為大家帶來「

」開發者的一篇文章，

我們希望大家可以舉一反三，

。

模版消息推送，是微信小程序採用的通知形式。

用戶本人在小程序頁面有交互行為後，小程序可觸發下發通知，通過微信聊天列表中的服務通知可快捷進入查看消息。此外，

。但是為了避免這種通知被濫用，帶來不好的用戶體驗，

。為了更好的優化小打卡小程序的打卡通知功能，我在開發的過程中自行摸索了一套突破推送限制的解決方案，

消息通知是一個很重要的功能，如社交產品的狀態通知，郵箱的新郵件通知，支付應用的支付成功通知等。這種常規的服務跟蹤類消息，便於用戶掌握產品對自身服務的進度，方便客戶獲取必要的信息，提高效率；還能保證用戶的知情權，讓用戶有安全感。同時，對於產品本身來說，消息通知可以引導用戶進行下一步行為，增加了產品的曝光率，便於用戶留存，增強用戶粘性。

如上圖，呈現在微信聊天列表的服務通知，收納了各個小程序向用戶推送模板消息，

。用戶點擊「服務通知」后，可以查看到通知列表頁面。每條通知以卡片的形式呈現，包括小程序的 LOGO、名稱、通知時間、通知內容等信息。

首先，通知卡片形式樣子是固定的。卡片中的通知內容部分，可以看到每天通知的內容都具備日程描述、日程主題、日程時間等要素，通知之間不同的地方在於這些要素後面的文案。將這些通知要素製作成模板，每次針對不同的通知內容，

即可推送給用戶。上面圖中兩條模板消息的日程主題和時間不一樣，其他的信息要素保持一致，這就是模板消息。

提到模板消息的好處，不得不提它的「多、快、好、省」的特點。

由於在微信客戶端服務通知在聊天列表中，保留了用戶以往處理聊天通知的習慣，所以用戶可以很便捷地觸及服務通知，查看小程序推送的模板消息。「好」即效果好，小程序的模板消息具備跳轉直達小程序特定頁面的能力。用戶接收消息后，查看消息的通知就能便捷地回到小程序，進行相應的業務處理、信息查看等後續操作，一定程度上提升了用戶的活躍度。小打卡小程序的近 30 天訪問來源數據顯示，有 20% 左右的用戶通過模板消息這個入口進入小打卡，在各種來源中排名第三位。可見，模板消息是用戶進入小程序的重要入口。「省」就是省錢唄。有了模板推送，自然降低了消息通知的成本，節省費用。消息通知優先通過模板消息這種方式來推送給指定用戶，只有無法觸及用戶的情況下，才有必要使用傳統的付費簡訊推送等形式。「多」呢？上面提到「無法觸及用戶的情況」，其實是因為小程序不具備「多」的特點。模板消息雖好，但是微信小程序官方為了保證用戶體驗，平衡通知和騷擾，

。接下來，我們就要聊聊這個限制。

微信小程序允許下發模板消息的條件分為兩類：

• 通過 1 次支付，小程序可以向該用戶下發 3 條模板消息。

• 通過提交表單來下發模板消息的方式，限制在 7 天內可以向用戶推送一條模板消息。

這種消息的控制放的太寬的話，很容易對用戶的體驗造成很大衝擊，給用戶帶來騷擾。但是，用戶 1 次觸發、7 天內推送 1 條通知明顯是不夠用的。比如，小打卡小程序利用模板消息的推送來提醒用戶每天打卡，只能在用戶前一天打卡的情況下，獲取一次推送模板消息的機會，用於第二天向用戶發送打卡通知。但是，用戶如果某一天忘記打卡，小打卡便失去了提醒用戶的許可權，和用戶斷開了聯繫。在小打卡中，還有一個迫切需要多條模板消息推送的場景。比如打卡活動每次有新的成員進入，需要通知管理員進行審核。這種情況也需要及時地通知管理員，以便管理員快速響應，處理成員的審核請求、並通知成員審核結果。我們可以注意到，在下發條件中，每次觸發得到的推送碼可以在未來 7 天內使用，多次提交觸發下發的消息條數獨立，相互不影響

那能不能利用它，突破模板消息的發送限制，更好地優化打卡提醒功能呢？

微信小程序官方最近已經透露出，可能對模板消息進一步放寬限制的信號。不過在這之前，我們可以在遵守官方相關運營規範、保證用戶體驗的情況下，倒騰一個「讓用戶一次觸發、多次推送，甚至群發模板消息」的解決方案。其實仔細分析消息下發條件中的「每次觸發獲得 7 天有效推送碼」、「多次提交觸發下發的消息條數獨立」，突破口就明顯了。只需

，即每次提交表單時獲取到的

，就可以獲得我們所需的「推送許可權」。它是一次性的，代表著開發者有向當前用戶推送模板消息的許可權。為了打造這樣一個突破限制的模版消息推送功能，做到 7 天內「任性」推送，我們將小程序前後端的工作明確一下：

• 小程序前端，即運行在用戶微信上的小程序，負責收集推送碼。

• 小程序後端，即伺服器負責將推送碼存儲到資料庫中，並在需要推送時，從中取出推送碼 formId 來推送消息。

整個方案的前後端業務流程如下：

接下來我們設計一個能夠突破當前模板消息推送限制的方案。我們需要結合小程序前端界面、小程序邏輯層、伺服器程序、資料庫、非同步任務系統各自分工，實現將小程序模板消息推送所需的推送碼的全過程，最終做到 7 日內更好地推送模板消息、觸及用戶。

每次表單提交可以觸發一次下發模版消息的機會。前端代碼如下：

在組件中，當屬性

為

時，代表需要請求發模板消息的推送碼。此時，點擊按鈕提交表單可以獲取

，用於發送模板消息。接下來，只需要對原來的頁面進行改造，將用戶原來綁定了點擊事件的界面用表單組件中的 也就是說，我們把用戶的交互點擊的

事件，通過表單

來取代，從而捕獲用戶的點擊事件來產生更多的推送碼

。

這裡還需要對按鈕組件的樣式進行稍微的修改，以便更好地包裹原來界面的代碼。

上面的代碼，主要實現了用模擬表單提交事件，來取代原來的點擊事件。

我們將其保存到

的全局變數中。

的數組數據發送給伺服器。

上圖以小打卡的打卡詳情頁為例，用戶在這個頁面的點擊操作可以很快收集到多個

。將界面上用戶高頻點擊的事件用表單的形式重新封裝后，可以靜默、快速收集到所需的「模板消息推送許可權」。

在小程序的邏輯層中，全局變數收集到多個

當新頁面載入且

不為空時，可以把

數組格式化為字元串發送到伺服器，然後並清空當前的

，以便繼續獲取新的

。

這個保存是一個高頻 IO 的操作。我們後端以 PHP 為基礎，結合高性能的鍵值對資料庫 Redis 來實現推送碼的存儲。

相關關鍵代碼如下，簡單表達了思路。針對不同的後端環境和開發語言，你可能需要做相應的調整。

這一步，主要是構建伺服器程序，高效存儲用戶的推送碼。這下推送機會有了，接下來，我們考慮如何利用後端程序來想特定用戶發送模板消息，考慮怎樣去合理運用推送機會。

構建高性能的伺服器端非同步任務推送，可以滿足模板消息的群發和定時發送的需求。小打卡就採用了高性能分散式內存隊列系統 Beanstalkd，來實現模板消息的非同步定時推送。實現發送模板消息的群發、定時發送分為 2 個步驟：

• 設置任務執行時間並將該發送任務推送到非同步任務隊列；

• 通過任務發送服務輪詢執行任務，獲取 access_token、指定你需要推送消息的用戶的 openId；

• 根據 openId，獲取用戶的推送碼 formId，並結合模板 ID 拼裝模板上的通知內容，調用模板消息發送介面來非同步發送。

普通的模板消息的發送就不贅述了，可參考官方文檔中的模板消息功能一步步進行操作。我們重點來看高性能非同步任務推送的實現方法。

涉及到的關鍵代碼如下：

Beanstalkd 是一個高性能、輕量級的分散式內存隊列系統。通過 Beanstalkd，可以將模板消息推送任務的創建以及任務的執行分開進行。在創建推送任務時，我們可以設置任務的執行時間，以及定義推送消息的類型、通知內容等數據。在任務執行時，

。我們通過預先在創建任務時標記的數據，來確定模板消息的具體推送內容。比如用戶，通過用戶獲取一個可用的推送碼

，獲取推送內容等，最後在調用微信小程序模板消息下發介面完成推送。

函數主要實現每次取出一個未過期可用的推送碼

，並且刪除不可用的邀請碼和當前已選中的邀請碼，以保證一定數額的推送碼

在未來一周內可用。最後總結一下：整個方案涉及到的關鍵詞有表單、按鈕、

、模板消息、Redis、Beanstalkd 等。同時，

，包括前端開發、後端開發、資料庫技術等，且前後端分工明確，共同支撐整個方案地實現。

正如我之前文章里所說的，微信小程序開發的難點不在於小程序本身，小程序開發技術是前後端一系列的技術的組合。開發者需要持續學習，掌握、提升更多的相關開發技術，來更好地支撐產品的功能實現。最後，這個方案可以在用戶最後一次使用小程序后的 7 天內，對用戶發送多條模板消息，但是請一定要在

的前提下，合理使用這樣的模板消息推送功能。

文章授權轉載自螢火新媒

▽ 點擊「閱讀原文」，發現更多優質小程序。