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

NO IMAGE

前言

只有光頭才能變強。

文本已收錄至我的GitHub精選文章,歡迎Stargithub.com/ZhongFuChen…

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

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

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

底層接口的變動,對程序員來說意味著什麼,你懂的。

人在家中坐,班從天上來

本篇文章主要來聊聊我這邊是怎麼發送小程序消息的,以及改版後的簡單介紹,希望對大家有幫助。

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

一、前置知識

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

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

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

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

無論是以前的模板消息,還是現在新的訂閱消息,步驟都是一樣的。

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

為什麼微信要把模板消息下線,要上線訂閱消息呢?我們從發送小程序的步驟來看,只有“獲取下發的權限”是可動的,其餘的兩步都是相同的。

我們開發者要藉助微信平臺向用戶發消息,需要一個理由(下發的權限)。因為微信還是注重用戶體驗的。

2.1 模板消息

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

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

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

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

2.2 訂閱消息

模板消息的下發理由我們可以發現:下發的權利是掌握在我們開發者手上的,只要我們通過用戶的各種行為收集到大量的formId,那我們在7天內就可以發送多條消息給到用戶。

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

  • 當用戶觸發某些場景時,給用戶彈框,讓用戶決定是否收到推送(而且只會收到一次)
「從模板消息改版訂閱消息」小程序推送

2.3 讓用戶收到自己想要的消息

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

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

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

微信會檢測你的模板有無問題,如果有問題就會把你的模板給刪掉(當然了,也不讓你創建可能是營銷類的模板)。沒有了模板,消費就發不出去了。

總的來說:微信會通過各種方式來限制你的消息下發,目的是想讓用戶收到他自己想要的消息。這次將模板消息改成訂閱消息,更是把下發消息的權限交給用戶了。

至於這件是好事,還是壞事。不同人有不同的看法。

有的人會覺得:讓用戶選擇是否收到消息,用戶所需要的操作就多了,彈窗也是對用戶的一種打擾。如果用戶不熟悉訂閱消息或者直接點了“取消”,小程序就沒法通知到用戶了,用戶可能因此錯失服務,對商家和用戶都是損失。

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

對於此次的改版,可以在評論區下談談你的看法~

三、我們是怎麼做的?

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

首先,針對在微信後臺創建的模板,我們是先把微信後臺的模板拉取到自己的數據庫保存起來,然後再做一個管理頁面對模板進行管理。

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

如果某個消息使用到了該模板,我們同樣也會做關聯起來(因為這樣可以方便查閱哪些消息使用了這個模板)

  • 正因為有了這個功能,所以我們這次遷移就可以很方便整理出目前還在使用的模板有哪些,使用的場景在哪。後續只要將消息的模板ID改成訂閱消息的模板ID就好了。
「從模板消息改版訂閱消息」小程序推送

像我司不單單隻有一個小程序,所以要對小程序進行分類,這裡就不再贅述了。實際上就是封裝了一層,例如:蘑菇街女裝 標識為88,蘑菇街直播購物臺標識為 99

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

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

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

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

如果新接入微信小程序消息的同學,那整塊流程就簡單很多了。

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

所以,現在我這邊如果要下發一條消息主要有兩個步驟:

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

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

  1. 對業務方的傳入參數進行簡單的校驗,拼接成完整的一個模板消息內容
  2. 如果業務方傳入的是userId,我這邊需要轉為openId
  3. 對消息速度限流,調用微信的下發接口
「從模板消息改版訂閱消息」小程序推送

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

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

這裡的打點實際上就是我們打日誌

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

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

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

最後

總的來說,小程序推送消息並不難,也僅僅是幾個接口而已。現在改版為訂閱消息後,那接入起來就更加方便了。再過一個月,你們使用小程序的時候可能就會收到各種的彈窗提醒你們是否要授權xxx模板消息。

不知道大家看完我這篇文章有什麼看法,歡迎在評論區留言。我會經常分享我在工作中遇到的問題以及學習後精心整理後的筆記,希望對大家有所幫助,覺得我的文章還有點東西,不妨關注我!

本已收錄至我的GitHub精選文章,歡迎Stargithub.com/ZhongFuChen…

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

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

非常感謝人才們能看到這裡,如果這個文章寫得還不錯,覺得「三歪」我有點東西的話 求點贊 求關注️ 求分享👥 求留言💬 對暖男我來說真的 非常有用!!!

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

相關文章

npx:npm包執行工具

面試常問的PECS原則,到底是什麼鬼?

聊聊rocketmq的RemotingTooMuchRequestException

HTMLEmail的編寫