陳漠沙：如何正確理解推送服務的「送達率」

本文選自《程序員》雜誌電子版 2015 年 6 月 B 刊，做者陳漠沙，如需轉載請註明出處。

在選擇和衡量第三方推送服務時，開發者首要考慮的因素就是消息的「送達率」，那麼該如何理解「送達率」呢？ 推送服務的「送達率」能夠達到多高？今天和你們一塊兒來聊聊這個話題。

一次消息推送的完整流程

以 Android 平臺爲例，一次典型的消息推送過程以下圖所示(模型已經簡化):

大體的流程能夠描述以下:

開發者首先將消息推送指令發送給第三方推送提供商（如友盟消息推送），告知推送服務商本次推送任務要發送的內容和目標對象。

• 咱們假定該推送指令要推送給該 App 的全部用戶(廣播)，假設該 App 有 100W 安裝量，那麼「發送總數」就是 100W 。

1. 推送服務商收到推送指令後，會對推送的設備集合作有效性檢查，假設經有效性判斷後，識別出有效設備 99W ，這 99W 設備就是該次推送任務的「接受數」。

• 有效性檢查包括多個層面，基本的層面包括檢查設備號 device-token 的合法性( device-token 根據必定的規則生成，若是設備號不符合生成規則，必然是無效設備)。

1. 在步驟 2 篩選出的合法設備裏面，第三方推送服務會選擇當時長連通道在線的設備進行消息下發，咱們稱這部分設備爲「在線設備」，假設有 40W ，咱們稱之爲「下發數」。

• 這裏說的「在線設備」表示的是設備已經聯網，而且與服務器端創建了長連通道。「設備聯網 & 長連通道創建」是消息下發的前提。上圖中的「設備3」就是一個離線設備的例子。

1. 第三方服務器對步驟 3 選擇出來的「在線設備」進行消息投遞，投遞給設備。假設消息成功下發到設備的有 39.5W ，這個數字咱們稱之爲「送達設備數」。

• 有可能由於網絡緣由，致使消息下發不成功，好比網絡閃斷(從而長連通道也會斷掉)。通常來講，「送達設備數」和「下發數」很是接近，通常都在 98% 以上。

1. 消息會首先送達設備，送達設備後，會根據 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% ，上文中的步驟 4 說的就是在線送達率。
絕大部分推送服務提供商所宣傳的高送達率其實說的就是「在線送達率」。

通用送達率: 針對該次接受的設備集合，成功送達到 App 的比例(定義說起的是送到到 App ，而非設備)。
通用送達率 = 送達 Ap p數( 35W ) / 接收數( 99W )。

這裏還須要補充一點的是，上述假定的數字都是針對消息建立時刻對長連在線的設備進行下發得出的數字。

實際上，開發者發送的消息都會設定必定的有效期(好比新聞類 App 的消息有效期通常比較短，而一些公告類的通知有效期可能會比較長)。在消息有效期內，若是仍有設備上線，那麼消息會繼續下發，「送達設備數」和「送達App數」會繼續增加，直至消息過了有效期，當次發送任務生命週期纔算結束，從而消息不會再去下發了，這個不會影響「在線送達率」，可是「通用送達率」在消息有效期內是會不斷提高，直至消息過了有效期。假設消息最終送達到設備有 55W ，送達到 App 有50W，那麼最終的「通用送達率」應該是 50W/99W 。

通用送達率和 App 活躍度的關係

看過這兩個送達率的定義以後，相信你們就能明白「送達率」的含義了。通常來說，「通用送達率」和 App 自身的活躍度以及所屬的垂直領域相關度很大。

相信你們也能觀察到一個現象：在 App 集成了推送 SDK 剛上線的時候，在友盟推送後臺看到的通用送達率會很高，以後會發現通用送達率就會隨着時間的增加而逐步下降，直至最後穩定在一個數值上。

這就說明了通用送達率和 App 活躍度有很大的關係。不活躍的 App ，有多是由於卸載致使，有多是由於 App 沒有啓動過，致使和服務器的長鏈接創建不起來，從而致使服務器端沒法下發消息(消息下發的前提是設備聯網且和服務器的長連通道創建)。

下面咱們給出一個線上真實 App 的某次發送任務，細分到 App 的活躍區間，來看看 App 活躍度對消息送達率的影響:

這裏的「受理」就是咱們定義的「接收數」，「送出」表示「下發數」，「通道送達」表示「送達設備數」，「送達」表示「送達 App 數」。

上圖代表，隨着活躍度的降低，會致使消息的「下發數」、「送達設備」 和「送達 App 數」所佔比例均會大幅度的下降。

上述過程，咱們解釋了 Android 平臺的消息送達率，對於 iOS 平臺來講，通常來講都是走的蘋果自身提供的 APNs (Apple Push Notification Service)通道，這個時候，咱們只能拿到「發送總數」和「接受數」這兩個數字，其中「接受數」表示 APNs 接受的發送數，咱們沒法進一步獲取蘋果自身的送達數。

所以，談到消息的送達率，咱們通常都是針對 Android 平臺來講的。

相信你們對推送的重要指標「送達率」有了必定了解，想了解更多推送指標和使用技巧？訪問友盟論壇-推送版塊http://bbs.umeng.com/forum-push-1.html

關於做者：陳漠沙，友盟研發總監，消息推送業務線負責人，曾就任於雅虎北京軟件研發中心，擔任系統開發工程師。新浪微博@貝克漢姆老了