拉新、促活最有效的方式，在目前除了有效的活動運營外，訊息反饋機制也是必不可少的。以訊息推送為例，藉助第三方的推送工具，可以有效的提升產品的打卡率與使用者活躍度。

但第三方工具只能在產品外部幫助提醒使用者，系統內的提醒邏輯與文案還是需要產品經理落地。一個網際網路產品經理的基本功，訊息推送設計就成了必選之一。

近期在網上調研中，來自lisa002分享的這一篇訊息推送機制，包含從push形式與後臺資料統計都有羅列，分享給大家。

以下為原文： 訊息推送是召回使用者、保持留存和內容推廣常用的辦法。使用者一旦安裝APP後，就有可能收到各種各樣的訊息推送，即使沉浸在APP使用中，也有可能收到通知需中止當前的操作。最近正好跟一位朋友一起探討推送相關的知識，故收集、整理了一些關於推送的知識，現整理成筆記，若有不足之處，希望得到各位的指出與建議，謝謝！

一、Push推送

不管APP是否正在前臺執行，伺服器通過第三方通道下發一條訊息觸達APP。若APP在前臺進行，則不做任何提示；若APP不在前臺執行，則會在手機鎖屏螢幕上展示訊息內容，同時會會在圖示上展示訊息個數，有些還可能會有一個訊息提示音

截圖為私人手機，為了隱私，塗掉了一些應用

Push推送受推送許可權影響，若使用者關閉推送允許，則該訊息無法觸達使用者。所以，在第一次開啟某個APP時，會彈出請求推送允許的彈框。若使用者不允許推送許可權，在後續的使用中，有些不服輸的產品依然會再次觸發提醒使用者開啟推送允許。

要深入理解Push推送，就要知道Push的推送原理，以及Android和iOS各有不一致的地方。

在啟用iOS推送通知之前，需要為伺服器建立配置檔案和SSL證書（是一種伺服器證書，類似人的營業執照等，此處是技術哥哥需要關注的問題，省略）。

1. 名詞解釋

Provider：伺服器；

APNs：蘋果推送通知服務(英文全稱：Apple Push Notification service）；

Decvice：使用者的裝置；

Token：是裝置的唯一識別符號，令牌，類似一個人的指紋；

瞭解以上資訊後，我們來看iOS推送的過程：

第1步：裝置從APNs請求裝置令牌；

第2步：APP接收到令牌，並且把該令牌作為傳送推送通知的地址；

第3步：APP將該裝置的令牌傳送到伺服器；

第4步：伺服器收到後，把帶有裝置令牌的推送通知，打包發給APNs；

第5步：APNs將收到的推送通知，推送到使用者的裝置。

可以上可以總結為：伺服器 —> 第三方伺服器 —>裝置。

2. android推送機制

Google有自己完整的推送系統，但由於Google在國內被禁，所以各個系統也都想盡了辦法，在此介紹下一個簡單的原理（不懂技術，故專門請教了安卓開發哥哥並整理。若有不對之處，請指正）。

Android如下要將訊息推送到手機，就要自己做一個類似APNs的東西，還要考慮及時性、穩定性、抵達率等，開發成本比較高，所以很多APP會採用第三方通道，比如友盟等。第三方SDK會拿到使用者的Token，當要進行Push推送時，伺服器將訊息推送給第三方伺服器，第三方將訊息推送到裝置上。

第三方推送會有不同程度的抵達率，有些APP為了達到推送的最優，會同時對接多個推送通道並預設好哪些某些通過採用按特定的通道推送。如華為手機對華為通道會有優先特權等，所以標記所有使用華為手機的使用者都使用華為通道。當首選通道推送不成功，則依次採取其他推送通道。

3. 應用內通知

與Push推送不同，當用戶正在使用APP時，頁面上可能會突出彈出一條通知，請求使用者進行某項操作或者提示某些內容。該通知可能展示在頁面的上方、中部或底部，這種通知稱作應用內通知（以下簡稱“通知”） 通知是APP內的推送，僅用到了第三方作為訊息下發的通道，並且可支援圖文並茂內容展示形式，也更可控。如上文，請求使用者允許推送許可權，也是一種通知。

通知與Push推送不同的點主要有：

• 該推送型別不受限於使用者的推送許可權，使用者無法拒絕接受此類訊息（除非解除安裝APP）；
• 訊息覆蓋的使用者人群比Push少，僅可觸達到開啟APP的使用者；（當然，為了觸達更多的使用者，可為通知設定時效，在時效生效內，只要使用者開啟APP即可收到。例如，向全量使用者推送一條通知，推送時間為上午10點，有效時間為2小時，則只要使用者在上午10至12點之間開啟APP，都可收到該通知。）
• 推送的內容形式更豐富，可支援自定義的圖文排版；
• 觸發更平滑。因為通知往往在使用者使用相關的流程中觸發，能更有效地轉化使用者。

二、推送注意要點

推送的目換在於提高使用者活躍或召回使用者，通過Push推送與通知相結合可以很發地為運營助力，甚至可以作為營銷的手段（推廣告）。但如果使用不當，可能會讓使用者反感而關閉應用甚至解除安裝。我通過個人經驗整理了推送需要注意的幾個關鍵點，與大家分享。

1. 明確推送目的，選擇適合的內容

盲目地推送會遭到使用者的反感。推送前，要明確推送目的，是要引導使用者進行某項操作還是僅做資訊公示？基於此目的，判斷推送是否是最好的手段？是否可以通過郵件、簡訊等替代？只有推送使用者感興趣的內容，才有可能激發使用者與你的互動。推送的內容可以有以下幾種：

• 與使用者相關的主核心功能，如收到新私信、評論、點贊、收藏等；
• 新功能新於法的推送，如應用推出新功能，引導使用者去升級等；
• 結合APP的定位，推送相對使用者價值高的內容：如對於資訊APP，推送地震、海嘯、宋慧喬宋鍾基結婚等；
• 福利資訊，如優惠券、紅包、福利活動、秒殺開始等資訊；
• 有時間截止的資訊內容，如訂單即將過期請支付等資訊。

2. 選擇觸發時機

考慮用什麼觸點撬動使用者，想在什麼時候喚起使用者，當觸發點和時間更合理時，推送的效果才有可能更好。

觸發時間：

結合使用者的使用情況進行推送。如訂餐APP會在考慮在上午10時給使用者推送午餐優惠券；電商APP會在支付未成功的訂單快過期時，提醒使用者趕緊付費。（這種情況，往往更多是使用簡訊，觸達率更高，更及時）我也曾逆天收到過有些APP在晚上1點推送訊息讓我去配音，試想下當時我收到這條訊息的心情。

觸發時機：

在使用者提交外賣訂單時，通知提醒使用者購買會員免配送費，可能會比進入APP就引導使用者去購買會員的轉化的效果更好。

3. 結合業務考慮使用者體驗

除其他推送條件外，也結合業務的情況，考慮使用者的其他體驗，比如以下場景：

場景1：

之前我們做APP，允許用一個賬號在不同的裝置中登入，推送會同時推給所有的裝置，但只要點選其中一個裝置的訊息，則另一個裝置的訊息會自動消失，免去使用者被重複打擾的情況；

場景2：

對於應用內通知，我在設計功能時，雖然設定了有效時長，但仍不會在使用者開啟APP時立即進行應用內通知。我會考慮使用者的平均使用使長，若使用者剛找開APP，會在某個時間內隨機下發通知，不會造成使用者一啟動APP就看到一大堆推送的困擾。

場景3：

該場景不算考慮使用者體驗。在商業中，有時候會採取應用通知來補其他點位的量，我也設計過此類功能。當時，為防止第三方查出在補量，曾跟開發討論過，模擬APP日活曲線下發推送，不致於讓資料在某個時刻點暴漲。

4. 個性化推送

APP的眾多使用使用者除共性外，依然有很多個性的喜好，根據外部自然情況與使用者的實際使用情況給使用者推送內容，會讓使用者更喜歡，主要表現以以下幾個方面：

（1）推送條件細分

通過對使用者進行地域、年紀、性別或者興趣維度等，進行推送使用者細分。比如以前我在做教育APP，內容會通過地區、學校、教材版本、年級、使用者角色（家長、老師）等分發，推送時也會將適合的內容推送給最適合的使用者。同時還會提取更細的資料型別，如通過使用者的登入行為、付費行為、功能使用情況等將使用者區分為XX型使用者，推送時定向針對該型別使用者推送，既可增加推送的準確性，又能降低其他型別使用者的反感度。

（2）推送頻率個性化

根據使用者的使用場景和現實生活場景，進行推送頻率控制。如之前我在做K12教育產品，暑假時使用者活躍度較高，推送的頻率也會更高；而臨近期末考試，使用者的活躍頻率低，推送的頻率也會相對降低。有些APP也會針對使用者每天使用APP的次數和對推送的反饋結果，對不同使用者進行不同的推送頻率，如今日頭條，點選推送訊息越多的使用者，收到的推送頻率越大。

（3）推送介面個性化

推送行為會受使用者影響，有些聰明的APP會通過改變推送的樣式（面板），來增加使用者的新奇感，但我並不認為這種方式時時湊效。

三、關注推送後的資料指標

（1）關注推送過程每個環節的資料量

訊息通過第三方推送，每一步都有可能折損訊息數量。首先要關注推送的漏斗，根據漏斗每一個階段資料的變化率採取相應的措施。

• 若觸太率太低，則要考慮是否需要更換第三方伺服器，或者檢視使用者的禁推比例，引導使用者開啟推送允許，或者採取其他運營手段；
• 若開啟量相對少，則考慮推送的內容是否符合使用者口味，或是否與推送時間有關係等；

（2）關注召回率

對於Push推送，除要關注訊息的到達數，也要考慮通過推送，使用者的召回率。可通過A/Btest，對比受推送使用者與其他非推送使用者的召比率情況，分析推送是否有效。

（3）關注推送後用戶禁推和解除安裝應用的資料

推送有可能會受到使用者的反感，而導致使用者禁推或者解除安裝APP，當推送成為日常的運營手段時，需要關注推送後用戶的禁推率和解除安裝APP的資料波動。