什麼是push通知欄訊息？

我是3y，一年CRUD經驗用十年的markdown程式設計師??‍?常年被譽為職業八股文選手

今天繼續更新Austin，給Austin新增一個傳送渠道（PUSH通知欄推送）

Push通知欄訊息是非常常見的，幾乎每個APP都會做這個功能（沒有訊息推送的APP不是一個好的APP）

一般我們認為Push訊息能做以下的事情：

1、喚醒使用者，提高使用者的留存率，提高產品活躍度。我手機下載了APP，但我似乎把它已經忘記了(好久沒用了)，如果此時這個APP給我推送一條我有興趣的內容。我可能會繼續用這個APP，甚至從此活躍起來（購買消費)

2、告訴使用者我有新的產品上線了(帶動功能模組使用率)。本來APP是做商城的，現在做起直播來了。但好多使用者好像都不咋留意到，此時我推送一條直播的訊息給使用者，可能使用者就愛起直播了。

Push訊息能夠在你手機閉屏時(即便你沒有開啟APP)，透過通知來給你推送資訊，是一種能夠直接觸達使用者的訊息推送。相對簡訊而言：成本低、樣式多樣(支援標題/簡介/圖片)、連結跳轉直接到APP。

不過如果使用者收到不感興趣的推送可能會導致：使用者把通知訊息給關閉了甚至把APP給解除安裝了

01、技術上如何傳送通知欄訊息？

要給使用者下發訊息，我們得維護APP 客戶端和服務端的「長連線心跳」。這個長連線心跳如果由我們自行來維護，難度會很大，絕大部分的公司不會自建推送服務。目前我們流行手機的作業系統型別分為兩種：安卓和iOS。

1、iOS我們預設走的是官方推送的渠道APNS。iOS 在系統層面與蘋果 APNs（Apple Push Notification service）伺服器建立連線，系統收到 APNs 伺服器訊息後會幫我們轉發到相應的APP上。iOS端我們可以直接接入APNs伺服器下發推送訊息

2、安卓由於Google在國內訪問不穩定，在國內暫未統一掉推送服務（工信部牽頭成立的“安卓統一推送聯盟”還在期待中）。目前更多的是眾多的手機廠商在其定製的系統中也內建了推送功能，如小米、華為等。由於接入成本的問題，也出現了大量的第三方推送服務提供商，比如個推、極光、友盟、信鴿等等。第三方推送服務提供商也會接入對應的手機廠商來實現對訊息的下發

接入第三方服務商推送的流程大致下：

02、使用Demo SDK

正常傳送PUSH是需要客戶端開發的，Austin更多關注的是服務端推送，而非客戶端的內容，所以我直接用個推提供的SDK Demo做除錯。

文件如下：https://docs.getui.com/getui/start/product/

從文件裡以及我的實踐後發現要使用該SDK，可以分為以下步驟：

1、登入註冊個推賬號，得到appid、appkey、appsecret

2、下載Android版本的訊息推送Demo：https://docs.getui.com/download.html

3、下載Android Studio來開啟剛才下載的SDK：https://developer.android.com/studio

4、修改config.gradle檔案的賬號相關引數值：

5、編譯成功後，直接build出對應的apk

6、將apk檔案給安卓的手機下載，就完事了

03、服務端推送訊息

服務端文件： https://docs.getui.com/getui/server/rest_v2/introduction/

從文件可得知接入無非就是呼叫HTTP時帶有需要token（鑑權）引數。這個好辦，我們在接入釘釘工作訊息的時候有過類似的操作了，寫個定時任務重新整理下就完事了：

為了照顧部分還沒把xxl-job這個定時任務框架的部署起來的同學，我專門寫了個手動重新整理Token的介面。

至於服務端其他的貌似沒什麼好說，無非就增加了一點細節，直接看程式碼吧：com.java3y.austin.handler.handler.impl.PushHandler

專案程式碼完整地址：http://gitee.com/zhongfucheng...

04、瞭解些技術之外的訊息推送

推送的內容又可以簡單分為以下的幾類：

系統功能類(訊息提醒)：比如快遞簽收通知，發貨通知，關注的主播開播(上新)啦
營銷類（活動/優惠類）：比如某某時間開始大促，趕緊搶購
內容類：比如曉明哥經典語錄，穿搭風格教程
資訊類：新聞、時事內容推送

針對上面所說的Push推送好處以及壞處，這就非常考驗我們到底推送些什麼內容給使用者了

1、推的內容好：提高使用者留存率、提高產品活躍度、提高使用者對APP的粘度

2、推的內容差：使用者對你的內容變得麻木、直接關閉通知訊息、甚至解除安裝APP

那麼一般我們會考慮些什麼因素呢？有以下幾個：文案、推送頻率、推送時機、、推送的人群

關於文案，有一個叫做愛達法則（AUDA）公式：

愛達法則

相信大家都聽過UC標題，如果有一個好的文案內容那吸引使用者點選的機率就更高一些。目前一般的推送會用一些小技巧去提高使用者的

在文案末尾後加上引導話術：“點我揭曉”、“→”、“>>”
多多利用數字：眾多品牌3折起，更有10元的褲子，你還等什麼？
增加emoji表情
結合熱點：今天曉明哥又出新語錄！
更強的關聯性：比如除夕的時候，你微信收到N個祝福訊息，但一看就是群發的，沒啥意思。但此時，有個朋友給你發了條訊息：“3y 春節快樂”。你就覺得有點溫馨了，是不是！
....

關於推送頻率，推送的頻率要控制得當，假設我在一天裡：

9-10點給你推條：關注這些，你的Java水平一定能提高！
12-14點給你推條：三年大佬經驗總結，買了就是賺到！
18-19點給你推條：耗時一個月整理的英語資源！一次性全部分享給你！
21-22點給你推條：價值1999的大資料資源，免費送給你！

那顯然，你肯定會取關我，是不是。一般來說一天使用者不能收到3天以上的推送，訊息多了，算是騷擾了，甚至不能每天都給使用者推送（可能隔天推一次會好一些）。

關於推送時機，如果是資訊類的，推送的時機顯然是越早越好了，不然別人家的都推送完了，使用者都知道了。你才推送，那誰還點進去啊。

（同時作為是官方推送的，還應保持準確性）

一般推送內容，我們都是希望在大家相對空閒的時間去推送，比如：

上班路上及早餐時間（9-10點）、午休（12-14點）、下班路上（6-7點）、睡前（21-22點）
不同的使用者群體，時間可會有一定的調整。所以這就得尋找相對適宜的時間了。

我正寫著程式碼，正在煩躁著這個Bug怎麼這麼的無厘頭時，此時一個Push推送過來：“你有一張代金券即將到期！”，那此時我真的是XXX了。

關於推送人群，現在網際網路公司都有自己的使用者畫像系統，給同一類人推送合適的訊息是較合適的。比如說：

有一批使用者剛註冊平臺，給這批使用者推送個優惠券，促進他的購買慾
有一批使用者可能身高150+，給這批使用者推薦些矮小的搭配風格推薦
有一批使用者的地址位置在廣州，給這批使用者推薦一下：廣州就該這麼穿，你就是整條街最靚的仔！
…這兒可以跟文案關聯起來，這樣的推送會更加精準一些，使用者可能會點選的機率會更高一些。

我是一個學Java的，收到的通知訊息卻是：“Excel從入門到精通，只要30天！”(關鍵是我也沒關注過Excel的內容)，那此類的推送如果多了，我很可能就把這個APP刪了。

4.1 推送訊息容易產生事故

為什麼會經常出現類似的事故呢？我認為最主要的原因是：預發和線上的環境是同一套。

眾所周知，我們的系統都有幾套的環境（比如說本地/線下/預發/線上環境），其中大多數公司的預發和線上環境資料庫是同一套的，只是預發環境呼叫的是預發環境的介面，線上環境呼叫的是線上環境的介面而已。

推送這種系統的線上和預發環境其實沒多大的區別，因為在底層是呼叫外部的介面來實現傳送的，所以預發和線上環境其實調的都是同一個介面。

於是我們會在預發環境下配置了「白名單」，在白名單內的使用者才能收到訊息來儘可能避免環境的問題

其次，在大多數情況下，推送事故往往是「運營」的推送導致的。運營要推送訊息給使用者，首先需要圈選一個人群去推送。

人群量需要管控：我們在圈選的時候，如果運營圈定的人數大於一個閾值，我們會走郵箱讓主管確認是否需要圈選這麼一個大的人群去推送。這塊有兩個目的：

1、首先我們是認為推送的人群應該是精細化的，什麼標籤的人群應該收到什麼的推送。不應該圈定一個龐大的人群去推送同一條文案的訊息（新聞APP除外）。

2、即便出了事故，也只是一部分使用者能收到，而不是全體使用者。

對於很多系統其實都不需要全體使用者推送這個功能

在運營圈定人群后，我們會有單獨的測試功能去「測試單個使用者」是否能正常下發訊息，文案連結是否存在問題。這一個步驟是必須要做的，給使用者發出的訊息，首先要經過自己的校驗。

當確認連結和文案都無問題後，則提交任務，走工單審批後才能傳送。

如果在啟動之後發現文案/連結存在問題，還可以攔截剩餘未發甚至撤回部分的訊息。

線上上環境訊息應該有「平臺性去重」的邏輯：

1、在某段時間內，過濾掉重複訊息

2、運營類訊息推送（圈定人群的方式去下發訊息）同一個使用者需要相隔一段時間才能下發一次。

雖然說，我們制定了很多的規則去儘量避免事故的發生，但不得不說推送平臺還是一個容易出現事故的系統。