開發者通過華為分析服務下載所需的事件資料，這些資料可以匯入到開發者自有的分析系統中，用於構建自定義報告或生成受眾群體的個性化分析等，從而幫助制定切實有效的營銷活動。資料匯出支援按照使用者屬性和匯出事件作為過濾條件，同時展示“預計可匯出事件數”。開發者選擇不同的時間段和過濾條件，預估事件數就會隨之改變。
問題描述
一位開發者向我們提出自己在建立資料任務後，發現錯誤獲取了所選日期前一天的資料。例如下圖所示，匯出的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/...
瞭解更多詳情>>
訪問華為開發者聯盟官網
獲取開發指導文件
華為移動服務開源倉庫地址：GitHub、Gitee
關注我們，第一時間瞭解 HMS Core 最新技術資訊~