中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本篇主要為大家介紹了推送消息在傳輸過程中，會出現怎么樣丟失的情況，而消息的丟失不應該歸入點擊率的計算。

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

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

從系列文章第二篇，我就一直給大家強調在推送系統的構建中，要盡量排除掉無效的設備，盡量讓消息能正常的到達用戶的設備上，這樣的推送點擊率才是最真實最能反映推送文案對用戶的吸引力。

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

你的用戶已離開

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

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

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

如以前Android設備出現過APP卸載后，利用系統進程的某些服務來告知服務器?；?者使用其他APP的協助傳輸被卸載的消息（具體沒嘗試過，可以詢問開發人員…

（2）甄別有效用戶時，實際給該用戶預先推送

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

若用戶關閉通知權限，此時也有一個辦法能解決。用戶關閉通知權限后，若開啟APP，則可通過APP檢測到權限是被關閉的，并告訴服務端這個用戶已經失效且不可再推送了。當然這個方法仍然不是萬全之策，若用戶關閉通知權限之后，沒有再啟動過APP，那么此時如何告訴服務端，又是個難題。

所以在推送過程中，像上述情況因為用戶已經無效，就已經丟失了一部分推送消息了。即便我們通過一些策略減少該問題的發生，仍然會不可避免的摻雜一些無效用戶。那么除此之外還有什么情況會導致消息的丟失呢？

你的用戶失聯了

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

1. 推送服務進程被系統殺死
2. 推送服務進程被第三方軟件殺死
3. 設備無法建立長連接

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

（1）考慮使用系統級推送

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

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

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

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

推送服務的問題

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

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

用戶設備環境復雜

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

你可能遇到過這么一種情況：在火車收到一條推送消息，講的是幾個小時前的即時新聞，你會吐槽到這個新聞推送一點也不及時。其實是因為你的設備處于弱網或無網狀態，例如在電梯里、地鐵上等弱網環境中，推送消息即使已經發出，但是由于網絡情況差，而無法及時的顯示在設備上。在這個過程中，網絡狀態較差的時候，推送服務將會替你把消息暫時存儲下來，待接入良好的網絡環境再重新展示出來。這樣雖然消息無法及時到達，但已經能減少消息丟失的幾率。可是在這個過程中消息丟失仍是不可避免的，仍然存在由于設備網絡環境差造成的消息丟失。例如當設備較長一段時間處于關機或無網狀態，當突然正常接入網絡后，大量的推送消息被路由展示，在這個過程中就很有可能出現消息丟失。

點擊率低，不一定是真的低

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

1. 發送成功率：建立推送任務成功數/計劃發送用戶總數
2. 下發成功率：推送服務實際下發數/推送服務計劃發送量
3. 推送到達率：推送實際達到設備數/推送服務下發量
4. 推送點擊率：用戶點擊推送數/推送實際到達設備數

看著是不是有點抽象，待我詳細介紹一遍。發送成功率指的是從你的推送系統服務端發傳輸到推送服務平臺的成功率，這個時候做了有效用戶的甄別等丟出，部分無效用戶將會失敗。所以這個成功率反應的是從你的服務端到推送服務的丟失和損耗，這個丟失一般比較小，如果此時丟失量很大的話，問題就出在服務端了。

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

當消息成功下發到設備上后，設備講會對消息進行路由和展示，根據上面的講述，這個過程會由于設備端的異常狀態導致消息的丟失，但這個數量相對較少。所以消息的到達率=消息到達展示數/消息實際下發數。

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

相比通過本篇文章的講解，大家應該了解到推送消息在傳輸的過程中，在每個環節均會有丟失的情況，針對丟失的情況我們可以對其做一些對應的策略，關于如何提高推送消息的到達將會在后面的章節中講到，敬請期待。

本篇總結

本篇主要為大家介紹了推送消息在傳輸過程中，會出現怎么樣丟失的情況，而消息的丟失不應該歸入點擊率的計算。具體可以總結成以下幾點：

1. 推送發送時，可能由于用戶卸載、關閉通知等情況導致消息丟失
2. 推送下發時，可能由于長連接失效，推送服務進程被殺死導致丟失
3. 推送到達時，可能由于設備網絡情況差，處于異常狀態導致丟失
4. 推送點擊率應該為點擊數/實際到達展示數，消息丟失不應歸入點擊率

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

相關閱讀

推送系統從0到1（一）：是系統不是工具

推送系統從0到1（二）：了解你的用戶

推送系統從0到1（三）：推送任務的建立

推送系統從0到1（四）：消息如何到達用戶設備

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

題圖來自Pexels，基于CC0協議