訊息推送作為使用者促活的有效利器，具有低成本、高效率的明顯優勢，已成為App運營中最重要的使用者觸達方式之一。為幫助開發者有策略地提升訊息推送的效果，增加訊息的到達率和點選率，個推訊息推送SDK於今年初重磅上線了後效分析功能，旨在為開發者和運營人員科學調整推送策略提供有效支撐。

後效分析功能上線後，我們結合產品目標和使用者建議，進行了多次迭代。本文就開發和迭代過程中沉澱的經驗與大家做分享，也歡迎感興趣的開發者們透過企業微信和我們交流。

後效分析功能的開發背景

訊息推送過程中，從服務端推送訊息、訊息到達客戶端，到使用者點選推送、開啟應用的各階段，都可能存在訊息折損的情況。

以往，訊息系統透過簡單對比下發、到達、展示、點選等四個維度的資料，來計算訊息的折損程度。但這樣的訊息折損計算方式不夠準確，運營人員較難深入瞭解訊息的折損原因，也就無法對推送引數、推送設定做出科學有效的改進。此外，以往客戶遇到訊息推送的問題時，會直接與技術支援人員聯絡解決，溝通和時間成本較高。

因此，我們需要設計出一種自動化方式，來幫助開發者清晰瞭解推送訊息的各項後效資料，並能夠自主、高效地找出訊息折損的原因。

後效分析功能的開發思路

我們的解決思路是：

1.推出後效資料包表功能。透過將訊息在服務端下發過程中的折損情況以及客戶端回執資料進行梳理、統計，形成各環節後效資料的清晰報表，以幫助開發者和運營人員透過資料表象，快速定位出訊息折損原因，找到提升推送效果的關鍵環節。

2. 自動採集各推送模組日誌並形成後效分析報告。透過不同模組獲取推送日誌：以類似人工查詢日誌的方式，將一些含有原因標識的日誌進行統一儲存和梳理，從而梳理出某條任務下發時產生的所有異常和折損原因。這其中就包含“目標正處於黑名單”“請求受到頻控（或流控）限制”等原因。與人工技術支援相比，這樣不僅能提高後效分析的效率，還能從一些以往可能被忽略的折損中自動提煉出問題，幫助使用者自檢並規避一些使用不當的情況。

後效分析功能的開發難點

在開發後效分析功能的過程中，我們也遇到了如下一些技術上的難點：

難點一

日誌的聚合歸類和後效原因提煉

在透過日誌進行訊息折損原因排查和分析的過程中，我們首先需要從海量日誌資料中篩選出有效的部分，並對該部分日誌資料進行歸納，根據我們預先設定的日誌解析策略，對全鏈路的日誌資料打上對應標記，以幫助我們分析訊息在各階段的折損原因。

為此，我們對訊息推送的整個鏈路做了一次大梳理，從推送階段入手，將推送模組區分為入口層、處理層、下發層、客戶端等四層，然後對各層可能存在的訊息折損原因進行了提煉：

✦ 在入口層，我們主要關注服務端收到的請求內容是否透過格式校驗，以及各類目標引數是否設定無誤，比如“CID是否有效”“鑑權資訊是否異常”等。

✦ 在處理層，我們關注目標客戶端是否符合下發條件，例如可能因為推送策略限制，導致服務端無法給部分客戶端進行後續推送。

✦ 在下發層，我們關注客戶端與服務端的網路連線是否正常，比如，線上通道是否有效等。

✦最終在客戶端收到推送、使用者點選訊息時，客戶端也會將回執彙報到服務端模組。這一階段的訊息折損原因可能是“通知開關沒有開啟”等。

基於以上業務層次區分，我們可以更清晰地看到訊息推送的整體業務流程。我們將各階段可能存在的異常關注點提煉出來，以便於我們梳理相對應的日誌模組。最終我們將後效異常原因總結為1 2類，分別對應訊息推送各階段中可能遇到的折損情況。

難點二

TB級別日誌資料的處理和準確計算

基於上述各場景，我們篩選出相關日誌，透過前期的標記來提煉訊息折損原因。

在一條訊息的下發過程中，服務端會產生大量日誌，單個功能節點一天的日誌量就能達到TB級別。如何對億級別的日誌進行過濾和計算，成為我們進行後效資料分析的第一個難題。

我們透過Flume傳輸日誌，將日誌資料寫入到HDFS，採用Spark作為計算引擎，HDFS儲存原始日誌資料和維度資料，最後的報表資料存放在ElasticSearch、Hbase和Mysql中。

海量日誌資料的清洗和計算

根據對推送業務特性的瞭解，我們總結出推送日誌資料可能存在的問題如下：

✦ 日誌重複。例如，使用者不斷地登入和登出服務，從而產生大量的重複日誌。

✦ 請求重複。例如，使用者多次發起相同請求，對某個客戶端傳送同一條訊息。客戶端最終只會收到一次訊息並展示，但伺服器會產生多條重複的客戶端/訊息關聯日誌。

✦ 回執重複。下游回執中，由於客戶端的網路環境複雜，有時會出現重複回執的情況，從而導致伺服器重複列印回執日誌。

✦ 日誌不足。比如，一般情況下，關閉通知、裝置活躍等客戶端資訊，在推送流程中不會有日誌產生，這就必須依賴相關資料作為補充，才能綜合評估出客戶端的狀態資訊。

針對以上問題，我們提出的解決辦法是 “人群打標”。我們按照推送流程對日誌資料進行劃分，將推送任務影響到的人群分為到達人群、下發人群、請求人群等三類。我們根據訊息與客戶端的關聯情況，對客戶端進行打標。例如當採集到“線上下發模組”日誌時，如果其中包含某訊息與客戶端的關聯資訊，那麼我們就會給該推送任務下的客戶端打上成功下發標記。每個標記只有0或1，不同日誌不會重複打標，如此就避免了日誌重複統計的情況。

結合上述人群打標邏輯，我們將四個維度的打標資料彙總，最終得到單個推送任務的原始資料。這份資料內，一個客戶端會有多個標記，我們只需要按過濾邏輯將這些標記整理並歸納出最終狀態，就可區分該條訊息對這個客戶端的下發流程最終到了哪一階段，或是在哪一階段因何種原因折損。

解決資料傾斜問題

在日誌資料的計算過程中，我們還遇到了資料傾斜的問題。

我們按照訊息下發階段將整個日誌計算任務拆分成四個。根據推送漏斗，這四個任務之間存在上下游關係。在對指標維度進行聚合的時候，會出現維度聚合體量差異過大導致資料傾斜的情況，甚至因為個別任務計算時間過久拖慢整體的計算進度。

為了解決該問題，我們需要在計算前和計算時對Spark任務進行處理，以減少資料傾斜。

我們採取的處理方式有：1.將大檔案分割成小檔案，或將小檔案合併成大檔案，以此保證每個任務處理的日誌資料量均勻；2.最佳化分割槽策略，防止某個較大推送請求下的所有資料全部匯聚到同一節點，使節點計算壓力更均衡；3.最佳化任務的計算鏈路，保證以最優的計算鏈路完成資料處理。

至此，基於如上所述的日誌資料處理和計算邏輯，我們就可以在HBase中儲存每條任務的後效資料，從而供業務層查詢、呼叫。

總結

近期，我們還引入了Flink流式計算引擎來提升後效資料計算的實時性；我們也結合了更多的訊息細則日誌進一步完善資料，將後效資料包表升級，推出了訊息鏈路查詢功能，藉此來幫助開發者更好地瞭解推送訊息下發情況，並根據對應建議來快速提升訊息的整體到達率。

“碼”上註冊和登入個推開發者中心（https://dev.getui.com/），體驗個推後效分析功能和最新推出的訊息鏈路查詢功能吧！

百億級日誌流分析實踐 | 剖析個推後效分析功能實現原理

相關文章