「從模板消息改版訂閱消息」小程序推送

前言

只有光頭才能變強。前端

文本已收錄至個人GitHub精選文章,歡迎Starhttps://github.com/ZhongFuCheng3y/3ygit

若是近期有看我文章的同窗,會知道我最近在公司作的是推送系統。推送系統在我這也叫作消息管理平臺,其實很容易理解:提供一個支持多渠道發送消息的系統。程序員

推送系統支持的渠道

推送系統支持的渠道github

在前段時間,微信公佈:小程序模板消息接口將於2020年1月10日下線,開發者可以使用訂閱消息功能數據庫

底層接口的變更,對程序員來講意味着什麼,你懂的。小程序

人在家中坐,班從天上來後端

本篇文章主要來聊聊我這邊是怎麼發送小程序消息的,以及改版後的簡單介紹,但願對你們有幫助。微信小程序

  • 本文不涉及任何的高深知識,放心觀看。

1、前置知識

發送小程序消息其實很簡單,微信提供了微信官方文檔供咱們開發者去查閱相關的基礎知識,提供HTTP接口給咱們去方便調用:微信

微信文檔

微信文檔學習

對開發者來講,發送小程序消息總結來講就三步:

  • 在微信後臺建立模板
  • 獲取下發的權限
  • 調用發送接口,發送消息

不管是之前的模板消息,仍是如今新的訂閱消息,步驟都是同樣的。

2、模板消息和訂閱消息的區別

爲何微信要把模板消息下線,要上線訂閱消息呢?咱們從發送小程序的步驟來看,只有「獲取下發的權限」是可動的,其他的兩步都是相同的。

咱們開發者要藉助微信平臺向用戶發消息,須要一個理由(下發的權限)。由於微信仍是注重用戶體驗的。

2.1 模板消息

模板消息下發的理由是:用戶最近在小程序活躍過,有過交互的行爲(好比說表單提交)。那麼開發者能夠從這些交互行爲中收集formId

一條formId會保留7天,當咱們調用發送接口的時候須要消耗一條formId。若是該用戶沒有formId的話,那麼咱們則會發送失敗

  • 重點:發送模板消息必定要攜帶formId

說白了,這個formId就是用戶與小程序的交互憑證。微信認爲:用戶最近使用過你的小程序,你才能夠給他/她發送消息。

2.2 訂閱消息

模板消息的下發理由咱們能夠發現:下發的權利是掌握在咱們開發者手上的,只要咱們經過用戶的各類行爲收集到大量的formId,那咱們在7天內就能夠發送多條消息給到用戶。

訂閱消息的下發理由是:把消息是否推送的權利還給用戶。用戶來決定能不能收到推送,簡單來講就是:

  • 當用戶觸發某些場景時,給用戶彈框,讓用戶決定是否收到推送(並且只會收到一次)

示例

示例

2.3 讓用戶收到本身想要的消息

在最開始使用微信的時候,你可能還能收到一些營銷類的小程序通知,但近期你應該就收不到的。

  1. 不容許惡意誘導用戶進行觸發操做,以達到可向用戶下發模板目的
  2. 不容許惡意騷擾,下發對用戶形成騷擾的模板
  3. 不容許惡意營銷,下發營銷目的模板

標題不能涉及營銷相關內容,包括不限於:消費優惠類、購物返利類、商品更新類、優惠券類、代金券類、紅包類、會員卡類、積分類、活動類等營銷傾向通知

微信會檢測你的模板有無問題,若是有問題就會把你的模板給刪掉(固然了,也不讓你建立多是營銷類的模板)。沒有了模板,消費就發不出去了。

總的來講:微信會經過各類方式來限制你的消息下發,目的是想讓用戶收到他本身想要的消息。此次將模板消息改爲訂閱消息,更是把下發消息的權限交給用戶了。

至於這件是好事,仍是壞事。不一樣人有不一樣的見解。

有的人會以爲:讓用戶選擇是否收到消息,用戶所須要的操做就多了,彈窗也是對用戶的一種打擾。若是用戶不熟悉訂閱消息或者直接點了「取消」,小程序就無法通知到用戶了,用戶可能所以錯失服務,對商家和用戶都是損失。

有的人也會以爲:把推送消息的權利掌握在用戶手裏,能很大程度上避免商家的惡意騷擾

對於這次的改版,能夠在評論區下談談你的見解~

3、咱們是怎麼作的?

我這邊來簡單說一下我這邊是怎麼接入推送小程序消息的,但願對想要接入小程序消息的同窗有必定的幫助。

首先,針對在微信後臺建立的模板,咱們是先把微信後臺的模板拉取到本身的數據庫保存起來,而後再作一個管理頁面對模板進行管理。

後臺管理頁面

後臺管理頁面

若是某個消息使用到了該模板,咱們一樣也會作關聯起來(由於這樣能夠方便查閱哪些消息使用了這個模板)

  • 正由於有了這個功能,因此咱們此次遷移就能夠很方便整理出目前還在使用的模板有哪些,使用的場景在哪。後續只要將消息的模板ID改爲訂閱消息的模板ID就行了。

將模板同步到本身的數據庫

將模板同步到本身的數據庫

像我司不僅僅只有一個小程序,因此要對小程序進行分類,這裏就再也不贅述了。實際上就是封裝了一層,例如:蘑菇街女裝 標識爲88,蘑菇街直播購物臺標識爲 99

在設計和寫代碼的時候要考慮後續的可擴展性

模板消息的時候,前端會打formId的點,我這邊會在StormMQ的數據清洗放到Redis裏邊。而後我這邊在發送以前就判斷用戶有沒有對應的formId

formId流程

formId流程

如今微信將模板消息改成訂閱消息,formId的收集到我這邊的Storm解析進Redis的操做都免去了。微信貌似也沒有提供接口給我判斷用戶是否有受權過。因此我只能在調用下發接口時,根據返回值來判斷用戶是否受權。

若是新接入微信小程序消息的同窗,那整塊流程就簡單不少了。

  • 前端同窗只要在必要的場景下彈窗,讓用戶受權
  • 後端的同窗直接下發到用戶,根據返回值判斷下發的狀況。

因此,如今我這邊若是要下發一條消息主要有兩個步驟:

  1. 在推送後臺新建一條消息(選擇微信的模板、消息建立者的基本信息、消息相關的規則處理(是否去重等等)
  2. 業務方調用我暴露的接口

業務方調用我這邊的暴露接口,我主要作如下的事情:

  1. 對業務方的傳入參數進行簡單的校驗,拼接成完整的一個模板消息內容
  2. 若是業務方傳入的是userId,我這邊須要轉爲openId
  3. 對消息速度限流,調用微信的下發接口

流程

流程

除了消息下發之後,咱們還會考慮到消息下發是否成功以及效果的問題(有無實時數據供查看,有無離線報表分析),因此我這邊是這樣作的:

  • 在關鍵的鏈路上進行打點
  • 業務方調用我接口,我已經確認收到消息了
  • 這條消息因爲業務緣由被過濾掉了(多是userId轉openId失敗了)
  • 在下發時可能因爲模板/token/用戶無受權等等狀況
  • 將打點的信息寫到Kafka,再由Storm清洗,實時的查詢的進Redis,離線的落到Hive表

這裏的打點實際上就是咱們打日誌

報表or查詢消息發送狀態

報表or查詢消息發送狀態

好比下面是我實時推送後,根據userId查詢推送的狀況:

實時查看消息的發送狀況

實時查看消息的發送狀況

最後

總的來講,小程序推送消息並不難,也僅僅是幾個接口而已。如今改版爲訂閱消息後,那接入起來就更加方便了。再過一個月,大家使用小程序的時候可能就會收到各類的彈窗提醒大家是否要受權xxx模板消息。

不知道你們看完我這篇文章有什麼見解,歡迎在評論區留言。我會常常分享我在工做中遇到的問題以及學習後精心整理後的筆記,但願對你們有所幫助,以爲個人文章還有點東西,不妨關注我!

本已收錄至個人GitHub精選文章,歡迎Starhttps://github.com/ZhongFuCheng3y/3y

樂於輸出乾貨的Java技術公衆號:Java3y。公衆號內有300多篇原創技術文章、海量視頻資源、精美腦圖,關注便可獲取!

轉發到朋友圈是對我最大的支持!

轉發到朋友圈是對我最大的支持!

很是感謝人才們能看到這裏,若是這個文章寫得還不錯,以爲「三歪」我有點東西的話 求點贊 求關注️ 求分享👥 求留言💬 對暖男我來講真的 很是有用!!!

創做不易,各位的支持和承認,就是我創做的最大動力,咱們下篇文章見!

相關文章
相關標籤/搜索