推送服務對于app拉新、拉活、引流、?；疃加惺诛@著的作用，其意義不可否認，但是對于推送服務你真的了解嗎？文章總結了幾個推送服務過程中隱蔽的坑，希望可以給大家一些警示。

隨著移動互聯網行業發展越來越成熟，各種各樣的開發工具與標準化的解決方案，正在急速降低互聯網產品的開發成本。推送服務儼然已成為移動開發中的標配服務。作為業務唯一能夠主動touch用戶的手段，推送服務對于app拉新、拉活、引流、?；疃加兄潜葘こ５囊饬x。

然鵝，作為一個多年奮戰在“技術客服”一線的產品經理，我想說對于推送服務——多的是，你不知道的事~~

接下來我就以小米推送為例，跟各位開發者（產品/運營同學）簡單講講在和形形色色的開發者對接過程中，我所見過的最隱蔽、最難躲的坑。

1 一切的開始：設備注冊

所有的推送服務使用的第一步，都是注冊設備。其實原因和目的都是顯而易見的，因為推送本身是一個點對點的行為，每臺設備的客戶端都需要與服務端建立一個獨立的長連接用于收發消息。因此，推送服務需要對每個設備進行標示。

各家推送服務的注冊接口叫法都不同，但有兩點是一樣的：

1. 這一接口均為客戶端接口
2. 通過調用接口后均會生成一個per app&per 設備的唯一標示

以小米推送為例，客戶端注冊推送的接口叫做register Push，注冊成功后，會生成一個regID，regID在推送系統中是全局唯一的，mipush通過一套復雜的加密算法，保證每個app在每臺設備上都不一樣。

介紹完背景知識，我們來講講在注冊設備這個看似最簡單最基礎的動作中隱藏的坑：設備注冊的時機。

由于push SDK需要有客戶端工程師手動集成到app之中，register Push的方法也需要客戶端自行調用才能完成注冊行為。因此，注冊行為的時機就非常重要。

那么從產品層面，怎樣設計注冊推送的時機呢？

由于不同的產品之間，業務形態千差萬別。所以很難總結一條明確的規定來指導使用者去注冊推送。但每位產品經理在設計推送的使用邏輯時，一定要將這一點想到前邊，了解app注冊推送的時機，結合業務邏輯去決策注冊推送的時機。以免為以后推送的使用埋下“神坑”。

舉個簡單的例子來說明一下吧：

某直播app，產品邏輯中有這樣一條限制：只有登陸之后才能看到內容。即登錄是強制動作。

這時候注冊應該在什么時機呢？是在登錄前還是登錄后呢？

其實這個問題沒有標準答案，要通過業務邏輯來進行設計。如果推送體系是基于賬號設計的，只有登錄完成之后，才能有賬號，那么在登陸后注冊推送聽上去比較合理，沒有登錄的用戶不作為自己的推送目標；如果推送不基于賬號，而是基于設備，及時未登錄的設備，也希望能夠接受推送消息。那么注冊時機應該在用戶登錄之前。即app被用戶打開即可喚起推送。

2不要隨便注銷！

一般的推送服務都會提供注冊（registerPush）和注銷（unregisterPush）兩種接口，這兩種接口都是客戶端能力。用于開啟和關閉推送功能。需要注意的是：調用注銷接口后，之前注冊的設備ID（regID）就失效了，無法繼續使用。即使重新注冊，也會生成新的設備ID。

所以注冊行為是一種不可逆的行為，僅適用于需要完全終止推送服務的場景。

如果一直頻繁的調用注冊和注銷接口，會有什么風險呢？

我們再舉一個栗子：

還是拿剛才的直播app舉例，需求是如果用戶登出，則不再向該設備推送消息?？蛻舳诉壿嫗椋河脩舻顷懞?，調用register Push接口；用戶注銷后，調用unregister Push接口。按照以上行為，每次用戶進行登錄和登出操作，均會生成新的regID。這種行為直接導致無效的regID會越來越多。推送ID體系變得臃腫復雜。

因此，如果只是希望暫時停止推送或關閉推送能力。應當使用別的方式，而不是直接注銷推送。各家基本都提供了暫停推送的接口。

3 正確認識送達率

送達率是每個使用推送的開發者最關心的數據指標之一，也是衡量一個推送服務靠不靠譜的關鍵指標。

然鵝，怎樣才算送達率的正確打開方式？我以小米推送為例來解釋一下這個問題~

首先需要說明的是推送服務送達率的計算方式：

分子比較容易理解，就是本次推送真正送達的設備數。

分母則是本次推送請求所覆蓋的有效的設備數：如果目標對象的選取是所有用戶，那分母就是歷史上所有激活過推送服務的有效設備數；如果是按照標簽選取的，那分母是歷史上所有訂閱過這個標簽的有效設備數；如果是按照別名或者regID來選取，那么分母就是所請求的所有合法的別名或regID。其中，設備的有效性是通過如下規則來判斷的：如果應用有以下幾種行為：

• 調用unregisterPush；
• 用戶主動卸載；
• 超過3個月都沒有和小米服務器建立過長連接，則會判定設備失效；
• 設置alias失敗等。

按照這種計算方式，會有如下幾個影響送達率的因素：

1.應用的留存率。

已經卸載了app的設備，肯定是推送不到的，但按照目前的計算方式，不少卸載設備（尤其是）都會被計入分母（計劃推送數）當中。

2.應用所在設備的聯網情況。

如果在消息有效期內，設備一直不聯網，那消息也是不能送達的，但也會被計入分母當中。

3.消息的有效期。

有效期越短，在有效期內聯網的設備數勢必就越少，因此送達率會隨之下降。

4.目標設備的選取。

如果選取的是全量用戶，那其送達率肯定會比按照用戶聯網情況精準提取目標設備（如選取7天內有過打開應用行為的用戶）要低。

4 APNs服務的“神坑”

作為一個有追求、有態度的推送服務，支持全平臺是基本的專業能力?？墒敲鎸μO果這個神一樣的廠商，再牛叉的平臺都得俯首帖耳，遵從人家的規定。

市面上提供推送服務的公司在面對蘋果時候，基本都會采取相同的做法：

集成APNs（Apple Push Notification service）

APNs是蘋果官方提供的推送服務，由于蘋果閉源的生態，所有開發者都只能使用這種方式來實現推送能力，強如微信也不例外。同時，無論是Android和iOS（包括WinPhone），推送服務的服務端接口的定義和使用方法保持一致，在結合業務邏輯使用的過程當中，客戶端的差異可以透明化。

今天在這里并不想展開講APNs，只想吐槽一下偉大的蘋果……

但凡搞過iOS開發的同學，基本都面對過同一個難題：無法獲取設備的唯一標。唯一用于標識設備的Device Token也會經常發生變化。

這一點其實也很好解釋：如果開發者能唯一標示設備，對用戶而言將會有很大的隱私風險。

開發者可能感觸不深，然鵝對于推送服務而言，這幾乎是令人抓狂的：無法拿到設備的唯一標示，該怎么做推送呢！

無論怎樣，路還得走，產品還要不斷發展，相信我們后面會有更好的解決辦法，幫助廣大開發者解決這些難題~

以上就是我做推送的一點心得，希望能為你提供一點點幫助~

本文由 @yubin 原創發布于人人都是產品經理。未經許可，禁止轉載。