本篇主要為大家介紹了推送消息在傳輸過程中，會出現(xiàn)怎么樣丟失的情況，而消息的丟失不應(yīng)該歸入點(diǎn)擊率的計(jì)算。

上一篇文章已經(jīng)詳細(xì)講述了推送任務(wù)建立后，消息是如何到達(dá)用戶的設(shè)備上的，在推送消息的傳輸過程中經(jīng)歷了什么步驟。大家可以再回顧一下?推送系統(tǒng)從0到1（四）：消息如何到達(dá)設(shè)備。

相信使用過推送的童鞋一定會遇到過這樣的場景：明明給1萬個(gè)用戶發(fā)了推送，結(jié)果只有不到100個(gè)用戶點(diǎn)開并瀏覽了，難道推送的內(nèi)容這么沒有吸引力嗎？還是什么原因呢？如果你也遇到過這種情況，別著急，不一定是推送的內(nèi)容沒有吸引力，很可能是推送消息在推送的過程中“偷偷溜走了”。

從系列文章第二篇，我就一直給大家強(qiáng)調(diào)在推送系統(tǒng)的構(gòu)建中，要盡量排除掉無效的設(shè)備，盡量讓消息能正常的到達(dá)用戶的設(shè)備上，這樣的推送點(diǎn)擊率才是最真實(shí)最能反映推送文案對用戶的吸引力。

所以在建立推送任務(wù)之前，有向大家介紹如何標(biāo)識你的用戶，如何選擇推送服務(wù)，如何建立帶有自濾功能的用戶池。這一切的一切都是希望在消息推送過程中，減少消息的丟失。那么消息在推送過程中，到底為什么會丟失呢？下面為大家詳細(xì)講解。

你的用戶已離開

在推送任務(wù)建立之后，即便你按照我所說的構(gòu)建帶有過濾功能的用戶池，同時(shí)也進(jìn)行了有效用戶的甄別。但是在推送的目標(biāo)用戶中，仍然存在無效用戶，這些用戶也許已經(jīng)卸載了你的APP，或者已經(jīng)關(guān)閉了通知權(quán)限，但你并不知道。此時(shí)，這些用戶注定是無法收到推送消息了。所以這是消息丟失的第一個(gè)環(huán)節(jié)，而這個(gè)問題幾乎無法避免。我們只能通過一些方式盡量減少這些無效用戶。

當(dāng)用戶卸載APP后，我們是否能知道該用戶已經(jīng)是無效的呢？若用戶卸載APP，那么無法再通過APP告知我們的后臺，這個(gè)用戶已經(jīng)不存在了。所以即便我們的用戶池會判斷用戶的token是否發(fā)生變更，在此時(shí)也無法發(fā)揮作用。同時(shí)在甄別有效用戶的時(shí)候，當(dāng)APP卸載的一段時(shí)間內(nèi)，推送服務(wù)仍然會認(rèn)為該用戶的token是有效的。所以在此環(huán)節(jié)也是難以判斷。我個(gè)人的建議是，如果確實(shí)想要排除掉這些無效用戶，可以考慮從以下兩個(gè)角度入手：

（1）APP被用戶卸載后，通過其他途徑告知后臺

如以前Android設(shè)備出現(xiàn)過APP卸載后，利用系統(tǒng)進(jìn)程的某些服務(wù)來告知服務(wù)器?；?者使用其他APP的協(xié)助傳輸被卸載的消息（具體沒嘗試過，可以詢問開發(fā)人員…

（2）甄別有效用戶時(shí)，實(shí)際給該用戶預(yù)先推送

此方法我在上一篇有提到過，實(shí)際推送是排查的有效方式，但是！預(yù)先推送空白通知， 如在蘋果設(shè)備上，可能會被展示給用戶看，對用戶造成困擾。同時(shí)即便是預(yù)先推送測試， 用戶收不到也可能是偶發(fā)的情況，只能在多次推送收不到的情況下，標(biāo)記為疑似無效用戶。

若用戶關(guān)閉通知權(quán)限，此時(shí)也有一個(gè)辦法能解決。用戶關(guān)閉通知權(quán)限后，若開啟APP，則可通過APP檢測到權(quán)限是被關(guān)閉的，并告訴服務(wù)端這個(gè)用戶已經(jīng)失效且不可再推送了。當(dāng)然這個(gè)方法仍然不是萬全之策，若用戶關(guān)閉通知權(quán)限之后，沒有再啟動(dòng)過APP，那么此時(shí)如何告訴服務(wù)端，又是個(gè)難題。

所以在推送過程中，像上述情況因?yàn)橛脩粢呀?jīng)無效，就已經(jīng)丟失了一部分推送消息了。即便我們通過一些策略減少該問題的發(fā)生，仍然會不可避免的摻雜一些無效用戶。那么除此之外還有什么情況會導(dǎo)致消息的丟失呢？

你的用戶失聯(lián)了

即使用戶沒有卸載APP，也沒有關(guān)閉通知權(quán)限，此時(shí)你仍然有可能無法把消息推送給你的用戶。在上一篇我有提到過，在推送任務(wù)開始的時(shí)候，需要與客戶端所在的設(shè)備建立長連接，通過設(shè)備中的推送服務(wù)進(jìn)程完成消息的傳遞。但是有可能無法建立連接導(dǎo)致用戶‘失聯(lián)’，這個(gè)原因其實(shí)我在第二篇有提到過。原因可能如下：

1. 推送服務(wù)進(jìn)程被系統(tǒng)殺死
2. 推送服務(wù)進(jìn)程被第三方軟件殺死
3. 設(shè)備無法建立長連接

先從第3個(gè)原因來看，這是最容易理解的，用戶設(shè)備處于某種異常狀態(tài)情況下，推送服務(wù)無法與用戶建立長連接，或者長連接失效等情況存在，此時(shí)需要推送服務(wù)多次嘗試與設(shè)備建立連接，若仍無法建立，則無法進(jìn)行下一步的推送。那么我們回過來看前2個(gè)原因，都是因?yàn)锳ndroid推送服務(wù)進(jìn)程被殺死，導(dǎo)致無法正常推送消息。這種情況多發(fā)生在Android推送時(shí)，使用第三方推送服務(wù)，系統(tǒng)的安全管家/省電模式將會把這些進(jìn)程殺死（如OPPO）或第三方軟件如某某管家、某某衛(wèi)士等把進(jìn)程殺死。如何避免這個(gè)問題的發(fā)生呢？可以考慮以下方案：

（1）考慮使用系統(tǒng)級推送

即接入你的用戶主流設(shè)備系統(tǒng)的推送服務(wù)，假設(shè)你的用戶主要使用華為、小米、OPPO、等設(shè)備，則可以考慮把這些推送服務(wù)都接入。但是隨之而來的是研發(fā)成本、技術(shù)難題、維護(hù)成本等。

（2）使用大部分APP接入的推送服務(wù)

在第二篇也曾介紹過，若你的APP與其他主流APP均使用相同的推送服務(wù)，即便用戶的設(shè)備把推送服務(wù)殺死后，若用戶使用與你的APP同一家推送服務(wù)的其他APP，則可以實(shí)現(xiàn)相互喚醒。這樣做的優(yōu)點(diǎn)是接入研發(fā)成本較低，維護(hù)較為容易。但是缺點(diǎn)是過度依賴于用戶的行為，用戶若未開啟這些APP，則被系統(tǒng)殺死的問題仍然難以解決。

總結(jié)來說，你要想盡一切辦法讓推送服務(wù)能在用戶的設(shè)備中存活下來，當(dāng)然此問題在蘋果系統(tǒng)是不存在的，APNs是蘋果唯一的系統(tǒng)級通道。而也是由于Android品牌的定制化及開放性問題，讓市場上的Android品牌有各自改造過的系統(tǒng)、自己的推送服務(wù)通道、自己的系統(tǒng)管理機(jī)制。對于推送設(shè)計(jì)者和應(yīng)用開發(fā)來說確實(shí)會造成一定的困擾。其實(shí)如果你請研發(fā)工程師反編譯一些大廠出品的APP，你就會發(fā)現(xiàn)他們也會面對這些問題。有些APP選擇和Android品牌手機(jī)廠商合作，讓它的APP成為系統(tǒng)級服務(wù)。有些APP也會接入多種Android設(shè)備品牌提供的系統(tǒng)級推送服務(wù)，即便接入成本比較高，也會力求消息能正常到達(dá)。

推送服務(wù)的問題

即便排除了用戶的有效性問題及負(fù)責(zé)長連接的進(jìn)程能正常運(yùn)用，天仍有不測風(fēng)云。即便是蘋果的APNs推送都不敢保證推送通知消息能百分百到達(dá)。推送服務(wù)作為一種服務(wù)也會存在故障、擁堵、丟失等情況，對于這種情況的存在幾乎是不可避免的。當(dāng)進(jìn)行大批量發(fā)送時(shí)，這些情況都是偶有發(fā)生的。

對于推送服務(wù)擁堵、故障的問題，需要考慮推送服務(wù)提供商的規(guī)模及資質(zhì)，部分推送服務(wù)擁有多個(gè)推送通道，可以同時(shí)容納大批量的推送任務(wù)同時(shí)執(zhí)行。這樣出現(xiàn)擁堵的風(fēng)險(xiǎn)就能得到降低。但是對于我們作為推送系統(tǒng)的設(shè)計(jì)者來說，是需要正視這些偶發(fā)性的問題及服務(wù)故障問題的存在。及時(shí)這些問題存在，其實(shí)它在推送過程中所占消息丟失的比例很低。由于推送進(jìn)程被殺死或者用戶Token失效造成消息丟失的情況才是大頭。

用戶設(shè)備環(huán)境復(fù)雜

上面曾經(jīng)講述用戶設(shè)備若無法與推送服務(wù)保持長連接，或者推送服務(wù)進(jìn)程被殺死，此時(shí)會造成消息的丟失。其實(shí)除此以外，用戶設(shè)備所處在環(huán)境對消息能否正常到達(dá)，是否可以正常路由顯示也起著非常重要的因素。

你可能遇到過這么一種情況：在火車收到一條推送消息，講的是幾個(gè)小時(shí)前的即時(shí)新聞，你會吐槽到這個(gè)新聞推送一點(diǎn)也不及時(shí)。其實(shí)是因?yàn)槟愕脑O(shè)備處于弱網(wǎng)或無網(wǎng)狀態(tài)，例如在電梯里、地鐵上等弱網(wǎng)環(huán)境中，推送消息即使已經(jīng)發(fā)出，但是由于網(wǎng)絡(luò)情況差，而無法及時(shí)的顯示在設(shè)備上。在這個(gè)過程中，網(wǎng)絡(luò)狀態(tài)較差的時(shí)候，推送服務(wù)將會替你把消息暫時(shí)存儲下來，待接入良好的網(wǎng)絡(luò)環(huán)境再重新展示出來。這樣雖然消息無法及時(shí)到達(dá)，但已經(jīng)能減少消息丟失的幾率?？墒窃谶@個(gè)過程中消息丟失仍是不可避免的，仍然存在由于設(shè)備網(wǎng)絡(luò)環(huán)境差造成的消息丟失。例如當(dāng)設(shè)備較長一段時(shí)間處于關(guān)機(jī)或無網(wǎng)狀態(tài)，當(dāng)突然正常接入網(wǎng)絡(luò)后，大量的推送消息被路由展示，在這個(gè)過程中就很有可能出現(xiàn)消息丟失。

點(diǎn)擊率低，不一定是真的低

也許你會覺得推送點(diǎn)擊率一般都比較低，Android在10%左右，IOS在5%左右已經(jīng)不錯(cuò)了。那也許是你認(rèn)識的點(diǎn)擊率不是真的點(diǎn)擊率。下面先給大家介紹概念：

1. 發(fā)送成功率：建立推送任務(wù)成功數(shù)/計(jì)劃發(fā)送用戶總數(shù)
2. 下發(fā)成功率：推送服務(wù)實(shí)際下發(fā)數(shù)/推送服務(wù)計(jì)劃發(fā)送量
3. 推送到達(dá)率：推送實(shí)際達(dá)到設(shè)備數(shù)/推送服務(wù)下發(fā)量
4. 推送點(diǎn)擊率：用戶點(diǎn)擊推送數(shù)/推送實(shí)際到達(dá)設(shè)備數(shù)

看著是不是有點(diǎn)抽象，待我詳細(xì)介紹一遍。發(fā)送成功率指的是從你的推送系統(tǒng)服務(wù)端發(fā)傳輸?shù)酵扑头?wù)平臺的成功率，這個(gè)時(shí)候做了有效用戶的甄別等丟出，部分無效用戶將會失敗。所以這個(gè)成功率反應(yīng)的是從你的服務(wù)端到推送服務(wù)的丟失和損耗，這個(gè)丟失一般比較小，如果此時(shí)丟失量很大的話，問題就出在服務(wù)端了。

推送平臺通過長連接把推送消息進(jìn)行下發(fā)，可能會遇到什么問題，在上面已經(jīng)講過了，這個(gè)過程中由于推送進(jìn)程被殺死導(dǎo)致長連接失效，會造成大量推送消息丟失，因此在這個(gè)過程中丟失的消息相對較多，同時(shí)由于部分無效設(shè)備并未在第一階段剔除，此時(shí)也將無法實(shí)現(xiàn)消息的下發(fā)。故會把問題堆積在這個(gè)過程中，往往消息下發(fā)過程可能成功率僅為80%左右。

當(dāng)消息成功下發(fā)到設(shè)備上后，設(shè)備講會對消息進(jìn)行路由和展示，根據(jù)上面的講述，這個(gè)過程會由于設(shè)備端的異常狀態(tài)導(dǎo)致消息的丟失，但這個(gè)數(shù)量相對較少。所以消息的到達(dá)率=消息到達(dá)展示數(shù)/消息實(shí)際下發(fā)數(shù)。

縱觀以上過程，消息在推送過程中已經(jīng)損耗了70%，如果讓點(diǎn)擊率來“背鍋”那點(diǎn)擊率自然會更低?？梢越o大家算個(gè)賬。假設(shè)點(diǎn)擊量約為700個(gè)。使用錯(cuò)誤的點(diǎn)擊率=點(diǎn)擊量/總發(fā)送量=700/10,000=7%；而正確的點(diǎn)擊率=點(diǎn)擊量/消息到達(dá)展示量=700/7,000=10%。是的，對比可以發(fā)現(xiàn)實(shí)際點(diǎn)擊率并沒有預(yù)想的這么低，而上述案例建立在消息丟失比較小的情況下，非常多情況消息丟失可能達(dá)到50%。

相比通過本篇文章的講解，大家應(yīng)該了解到推送消息在傳輸?shù)倪^程中，在每個(gè)環(huán)節(jié)均會有丟失的情況，針對丟失的情況我們可以對其做一些對應(yīng)的策略，關(guān)于如何提高推送消息的到達(dá)將會在后面的章節(jié)中講到，敬請期待。

本篇總結(jié)

本篇主要為大家介紹了推送消息在傳輸過程中，會出現(xiàn)怎么樣丟失的情況，而消息的丟失不應(yīng)該歸入點(diǎn)擊率的計(jì)算。具體可以總結(jié)成以下幾點(diǎn)：

1. 推送發(fā)送時(shí)，可能由于用戶卸載、關(guān)閉通知等情況導(dǎo)致消息丟失
2. 推送下發(fā)時(shí)，可能由于長連接失效，推送服務(wù)進(jìn)程被殺死導(dǎo)致丟失
3. 推送到達(dá)時(shí)，可能由于設(shè)備網(wǎng)絡(luò)情況差，處于異常狀態(tài)導(dǎo)致丟失
4. 推送點(diǎn)擊率應(yīng)該為點(diǎn)擊數(shù)/實(shí)際到達(dá)展示數(shù)，消息丟失不應(yīng)歸入點(diǎn)擊率

按照計(jì)劃，下一篇將會為大家介紹，用戶在收到推送消息后的一些點(diǎn)擊和后續(xù)行為，希望大家能喜歡。

相關(guān)閱讀

推送系統(tǒng)從0到1（一）：是系統(tǒng)不是工具

推送系統(tǒng)從0到1（二）：了解你的用戶

推送系統(tǒng)從0到1（三）：推送任務(wù)的建立

推送系統(tǒng)從0到1（四）：消息如何到達(dá)用戶設(shè)備

本文由 @番茄那只羊 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Pexels，基于CC0協(xié)議