開發者通過華為分析服務下載所需的事件資料，這些資料可以匯入到開發者自有的分析系統中，用于構建自定義報告或生成受眾群體的個性化分析等，從而幫助制定切實有效的營銷活動，資料匯出支持按照用戶屬性和匯出事件作為過濾條件，同時展示“預計可匯出事件數”，開發者選擇不同的時間段和過濾條件，預估事件數就會隨之改變，
問題描述
一位開發者向我們提出自己在創建資料任務后，發現錯誤獲取了所選日期前一天的資料，例如下圖所示，匯出的2021年12月18日的資料報表中eventtime包含了12月17日發生的事件：
問題定位
1. 確定資料匯出的時間基線規則，
接到問題后，我們首先確定了開發者在創建資料匯出任務時，時間基線規則是基于哪個時間判斷的，然后通過云測資料匯出規則發現，開發者所選的篩選日期是根據分析服務云測服務器的時間判斷的，即server time，
2. 分析跨天上報的資料量占比及特點，
以某應用12月9日的資料為例，當天servertime統計總量資料15xxxxx，eventtime資料量占比97.3%；包含前一天資料量占比2.65%，這些資料無明顯特點，云測資料傳遞程序中的eventtime均為透傳不會做另外的計算，
3. 排查端測上報并復現，
Event time記錄的是事件觸發的時間，因此我們懷疑事件在觸發后沒有及時上報到云測，而是延遲到第二天才上報到server服務器，也就是說，這些事件均快取到了本地，
經過與開發者的溝通，我們了解到其采用的是默認上報策略，即應用切后臺上報策略和閾值上報策略，當開發者沒有設定上報策略時，這兩種策略就會自動生效，由此，通過復現發現如果應用被殺掉，用戶切后臺觸發事件上報，上報行程還沒有走完，行程被殺掉，導致事件上報失敗，快取在本地，等待下次上報，另外還有兩點原因，具體見下節根因描述，
原因
-
用戶切后臺觸發事件上報，上報行程還沒有走完，行程被殺掉，導致事件上報失敗，快取在本地，等待下次上報；
-
用戶切后臺上報時，網路狀況等原因，沒有上報成功；
-
凌晨正在跨天使用App的用戶，資料上報快取到第二天上報，
解決方案
建議開發者通過setReportPolicies介面設定4種上報策略搭配使用，并將定時上報策略設定為60s-1800s（60s最為敏感），如果設定為60s，這種場景即便行程被殺掉，也能確保行程殺死前60s之外的資料能夠上報，避免資料上報時延，
欲了解更多HMS Core分析服務詳情，請參閱：
https://developer.huawei.com/consumer/cn/hms/huawei-analyticskit/?ha_source=hms1
了解更多詳情>>
訪問華為開發者聯盟官網
獲取開發指導檔案
華為移動服務開源倉庫地址：GitHub、Gitee
關注我們，第一時間了解 HMS Core 最新技術資訊~
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/448180.html
標籤：Android