運營必看：App消息推送”送達率”真的能達到98%嗎？
Warning: Invalid argument supplied for foreach() in /data/cxweb/www/gupowang.com/public/article/view.html on line 71
在選擇和衡量第三方推送服務時，開發者首要考慮的因素就是消息的“送達率”，那么該如何理解“送達率”呢？推送“送達率”高達98%靠譜嗎，該如何理解這么高的“送達率”？今天我們一起來聊聊這個話題。
以Android平臺為例，一次典型的APP消息推送過程如下圖所示(模型已經簡化):
大致的流程可以分為以下五步:
一，開發者首先將消息推送指令發送給第三方推送提供商（如友盟消息推送），告知第三方推送服務商本次推送任務要發送的內容和目標對象。
我們假定該推送指令要推送給該App的所有用戶(廣播)，假設該App有100W安裝量，那么“發送總數”就是100W。
二，第三方推送服務商收到推送指令后，會對推送的設備集合做有效性檢查，假設經有效性判斷后，識別出有效設備99W，那么這99W設備就是該次推送任務的“接受數”。
有效性檢查包括多個層面，基本的層面包括檢查設備號device-token的合法性(device-token根據一定的規則生成，如果設備號不符合生成規則，必然是無效設備)。
三，在步驟b篩選出的合法設備里面，第三方推送服務會選擇當時長連通道在線的設備進行消息下發，我們稱這部分設備為”在線設備“，假設有 40W，我們稱之為“下發數”。
注意，這里說的“在線設備”表示的是設備已經聯網，并且與服務器端建立了長連通道。“設備聯網 & 長連通道建立”是消息下發的前提。上圖中的“設備 3 ”就是一個離線設備的例子。
四，第三方服務器對步驟C選擇出來的“在線設備”進行消息投遞，投遞給設備。假設消息成功下發到設備的有39.5W，這個數字我們稱之為“送達設備數”。
有可能因為網絡原因，導致消息下發不成功，比如網絡閃斷(從而長連通道也會斷掉)。一般來說，“送達設備數”和“下發數”非常接近，一般都在98%以上。
五，消息會首先送達設備，送達設備后，會根據App的包名(Android平臺以包名作為App的唯一標識)路由給App，路由到App之后，終端用戶就可以接收到通知消息了，由此消息推送的整個過程就算完成，上圖中消息發到給“設備1”就是這樣一個過程。假設成功路由到App的消息數為35W ，我們稱為“送達 App 數”。
二，舉一個例子
這個過程牽涉到較多的專業術語，我們可以通過寄快遞的例子來幫助大家理解這個過程:假如你在上海要通過順豐寄送一個快件兒給北京的友盟公司，那么快件兒首先會郵遞到順豐公司在北京的總站點，之后再根據友盟公司的地址投遞/路由到友盟，這樣一個寄件過程就算完成了。在這里，你要寄送的快件兒就是你要發的“消息”，北京的友盟公司相當于最終“接收消息的App”，順豐公司在北京的總站點相當于這里提到的“設備”，友盟公司的地址就相當于這個環節里面提到的“包名”。廣義的來講，其實快遞本質上也可以看做是一種消息推送。）
消息送達設備，但最終沒有成功路由到App的原因比較多，最常見的原因是App已經被刪除，導致路由失敗，或者在某些深度定制系統上(比如MIUI)由于做了某些限制，如果App在消息送達設備后沒有啟動過，也會導致路由失敗。“設備2”就是一個App已經卸載，消息可以下發到設備，但是最終路由不到App的例子。
由此來看，消息推送從開發者創建消息推送指令，到最終消息成功送達 App (只有送達App后，消息才可以正確展示出來)，中間會經過幾個步驟，在每個步驟中，相關數字都會有損耗。接下來我們給大家解釋一下上文提及的幾個數字的概念，由此來引出我們要重點討論的消息“送達率”定義。
發送總數:該數字是從開發者的角度出發的，表示從開發者看到的或者認為的該次發送目標集合的個數。
接受數:表示第三方推送服務提供商認定的合法的發送設備數。“接受數” 是真實的發送總數，表示該次任務計劃下發的總數。一般來說，“接受數”和“發送總數”是非常相近的。
下發數:表示當次發送任務創建時刻，長連在線設備的個數（上文提到，設備聯網且設備長連在線是消息能夠下發的前提），推送服務商會選定這些長連在線的設備，做消息下發。
送達設備數:表示消息送達到設備的數字，注意這個僅表示送達到設備層面的數字。
送達App數: 消息送達到設備后，成功路由到App的數字。
概念明確之后，我們給出兩個送達率的定義，“在線送達率”和“通用送達率”:
在線送達率:表示的是，針對長連在線的設備進行消息下發，成功送達到設備的比例(注意，定義提及的只是送達到設備，而非送達到App這個層面)。 在線送達率 = 送達設備數(39.5W) / 下發數(40W) 或者 在線送達率=送達設備數/接收數*在線設備率≈98.75%，上文中的步驟d說的就是在線送達率。絕大部分推送服務提供商所宣傳的高送達率其實說的就是“在線送達率”。
通用送達率:表示的是，針對該次接受的設備集合，成功送達到App的比例(注意，定義提及的是送到到App，而非設備)。通用送達率=送達App數(35W) / 接收數(99W)。
這里還需要補充一點的是，上述假定的數字都是針對消息創建時刻對長連在線的設備進行下發得出的數字。
實際上，開發者發送的消息都會設定一定的有效期(比如新聞類App的消息有效期一般比較短，而一些公告類的通知有效期可能會比較長)，在消息有效期內，如果仍有設備上線，那么消息會繼續下發，“送達設備數”和“送達App數”會繼續增長，直至消息過了有效期，當次發送任務生命周期才算結束，從而消息不會再去下發了，這個不會影響“在線送達率”，但是“通用送達率”在消息有效期內是會不斷提升，直至消息過了有效期，假設消息最終送達到設備有55W，送達到App有50W，那么最終的“通用送達率”應該是 50W/99W。
看過這兩個送達率的定義之后，相信大家就能明白“送達率”的含義了。一般來講，“通用送達率”和App自身的活躍度以及所屬的垂直領域相關度很大。
相信大家也能觀察到一個現象：在App集成了推送SDK剛上線的時候，在友盟推送后臺看到的通用送達率會很高，之后會發現通用送達率就會隨著時間的增長而逐步降低，直至最后穩定在一個數值上。這就說明了通用送達率和App的活躍度有很大的關系。不活躍的App，有可能是因為卸載導致，有可能是因為App沒有啟動過，導致和服務器的長連接建立不起來，從而導致服務器端無法下發消息(消息下發的前提是設備聯網且和服務器的長連通道建立)。
下面我們給出一個線上真實App的某次發送任務，細分到App的活躍區間，來看看App的活躍度對消息送達率的影響:
這里的“受理”就是我們定義的“接收數”，“送出”表示“下發數”，“通道送達”表示“送達設備數”，“送達”表示“送達App數”。 上圖表明，隨著活躍度的下降，會導致消息的“下發數”、“送達設備” 和“送達App數”所占比例均會大幅度的降低。
上述過程，我們解釋了Android 平臺的消息送達率，對于 iOS 平臺來說，一般來說都是走的蘋果自身提供的APNs (Apple Push Notification Service) 通道，這個時候，我們只能拿到“發送總數”和“接受數”這兩個數字，其中“接受數”表示 APNs 接受的發送數，我們無法進一步獲取蘋果自身的送達數。因此，談到消息的送達率，我們一般都是針對Android平臺來說的。
本文選自《程序員》雜志電子版2015年6月B刊，如需轉載請注明出處。
姑婆那些事兒（www.3377on.com）是互聯網推廣運營知識分享平臺，關注移動推廣（android，ios）運營，網站推廣運營、校園推廣及互聯網領域最新動態 。歡迎關注我們的微信（gupo520），新浪微博（姑婆那些事兒）。
本文由姑婆那些事兒發布，轉載請注明本文出處，并附帶本文鏈接，違者必究。
文章評論(0)