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

在做數據分析時，我們常常會根據之前的埋點進行統計，但由于緩存沒有反映真實的用戶情況，給后續的分析帶來了一定影響，導致分析錯誤。面對緩存導致的無效曝光，該如何解決？作者分享了幾點心得，一起來看看。

01 背景

用戶在App上的行為都通過埋點記錄了下來，那在統計部分行為相關指標時，比如曝光人數、點擊率等相關指標，就會因為緩存的影響導致統計的結果并沒有真實反應用戶的情況。就會導致曝光人數偏高、點擊率偏低，在進行分析對比時就有可能得出錯誤的結論，進而導致決策的失敗。因此需要一個方案來解決緩存對埋點數據的干擾。

02 緩存機制

App的功能在設計時，會考慮到用戶的體驗問題，一般會在App一級模塊頁面建立緩存機制，確保用戶打開APP的瞬間能看到內容，而不是一個空白的頁面。

緩存就是指用戶訪問App的某個功能或者頁面時，客戶端會向服務端請求最新的數據進行展示，那這個請求到展示的過程是需要時間的，一般情況是毫秒級別完成這個過程，但是遇到用戶沒有聯網或者在網絡信號較差的環境，等待新數據加載出來的時間比較久。

如果這個時候給用戶一個空白頁面的話，用戶體驗較差。所以大部分情況下展示用戶上一次訪問這個功能或者頁面時的內容，等最新的數據請求成功后再對數據進行替換。這樣的設計能讓用戶使用App時體驗更好，因此大部分App都會有緩存機制存在，這其實也造成大家安裝的App體積變越來越大的一部分原因。

由于緩存機制是App先展示上一次訪問的內容，請求成功后再替換成新的內容。那對于埋點采集來說，這個時候先展示舊的內容也是發生了一次曝光，那等新的內容加載完成又會產生一次曝光，也就是會上報2次曝光的埋點采集記錄。

那對于實際用戶來說，只要網絡順暢的情況，緩存內容替換最新的內容花費的時間是毫秒級別的，肉眼是無法真正看到緩存的內容，一般只能看到被替換后的新的內容。因此這個時候埋點采集的緩存曝光就是無效曝光，用戶并沒有實際看到，也是無法進行點擊。

這樣的數據業務方直接進行使用時就會容易造成錯誤的決策。特別是首屏直接能看到的內容，緩存影響的情況比較嚴重，跟其他非首屏的內容進行對比時，點擊率會特別偏低，從而可能錯誤的以為內容不夠好。

03 如何過濾緩存曝光數據

1. 簡單方案

埋點數據中有一個參數是此內容的服務器下發時間的，因此可以用服務器下發時間和客戶端本地的曝光時間進行對比，只要是非當天的內容就內容是緩存數據，對其進行過濾。

此項方案有比較多的缺點，首先對于當天的緩存曝光數據無法正確的過濾，另外對于有些接口請求失敗的case來說下，跨天的曝光數據也是真正發生曝光的正常數據。這樣是相對比較簡單粗暴的進行緩存數據過濾，在執行了一段時間之后就放棄此方案，此方案的唯一優先就是開發成本極低。

2. 精細化方案

緩存的本質就是用戶訪問時，是否請求接口之前展示的數據，因此客戶端可以根據這個邏輯進行緩存曝光的標記?？蛻舳藢τ脩粼L問的曝光進行監控，接口請求之前的日志標記為緩存日志，接口請求結束后的日志標記為正常日志，如果請求失敗則會把緩存日志重新標記為正常日志。

這樣就能真正意義上去設別曝光數據是否為緩存曝光。并且對于網絡不佳，雖然展示緩存內容的曝光，可以正確的標記為正常曝光，因為這種場景下用戶也是正?？吹搅苏故镜木彺鎯热?，對于數據統計來說確實需要標記為正常曝光。

04 如何驗證緩存日志標記的準確度

精細化方案標記緩存日志的方案，由于整個埋點架構方案設計的比較合理，使得進行緩存標記時客戶端的實現成本并不高。但是這個曝光數據對于業務來說是非常重要的數據，如果保證客戶端的緩存標記的準確度是足夠的，才能讓這個標記上線。

1. 緩存刷新邏輯

頁面的緩存實現邏輯可以分為進入頁面刷新和定時刷新這2種邏輯。進入頁面刷新代表打開頁面時會先展示緩存內容然后請求接口后替換為新的內容，以返回的形式打開頁面或者App退到后臺后回到前臺的形式打開頁面的2種case不會觸發刷新邏輯。

定時刷新是指打開頁面距離上次打開的時間超過一定時間就會刷新（一般是10分鐘左右），并且殺死App后重新打開App時，不管距離上次打開頁面有多久都會強制刷新一次。

2, 數據驗證方案

基于上面2種頁面的緩存刷新邏輯設計一套數據驗證方案，核心驗證的點就是：該標記為緩存日志的沒有正確標記，不該標記為緩存日志的卻錯誤標記。

1) 不該標記為緩存日志的卻錯誤標記

不該標記為緩存日志的卻錯誤標記的情況是比較不能容忍的，因為這個會丟失正常曝光的數據，因此目標是這個錯誤標記的概率希望能維持在萬分之一以內。

驗證邏輯為：由于對曝光數據大部分情況下都是統計人數，很少去曝光次數這個指標，因此只需要保證服務器下發時間和曝光的觸發時間在定時刷新的時間之內的緩存曝光日志在當天非緩存的曝光日志中有一條相同的日志即可，因為只我們統計人數，不關心次數，因此同一天就算有錯誤標記的曝光日志也沒有影響，只需要在非緩存曝光日志找到一條相同的結果就不會影響人數的統計。

另外再去掉殺死App重新打開case的緩存日志這種正常標記的情況，就可以得到錯誤標記的比例情況。

2) 該標記為緩存日志的沒有正確標記

該標記為緩存日志的沒有正確標記的情況相對的容忍度會好一些，并且不會影響正常曝光日志的統計，只會把一些緩存曝光錯誤的統計為正常數據，跟當前對全部曝光日志進行統計的情況而言只是過濾緩存沒有百分比到位，也已經比統計全部曝光日志更貼近真實情況了，因此目標是錯誤標記的概率維持在百分之一以內即可。

驗證邏輯為：我們先默認服務器下發時間和曝光的本地時間超過定時刷新的時間日志就應該標記為緩存日志，然后再排除從下級頁面返回上級頁面的case；另外沒有定時刷新邏輯頁面還需要排除前后臺切換的case，就能得到錯誤標記的比例情況。

根據上面2種驗證方式就可以得到錯誤標記的日志，就可以根據這個用戶的全部埋點日志去還原其行為情況，從而找到為什么標記錯誤的原因，對于bug部分就行修正，對于如果說是正常的case就在前面驗證方案里面加上此case的排除，這個部分問題原因的尋找，是十分消耗精力的，整個項目最耗時的部分就這里。

經過各種bug修復最終得到符合預期的錯誤標記比例后，緩存曝光的標記就達到上了可以上線的標準。

05 曝光統計口徑更變

數倉直接在ODS層的日志進行緩存數據的過濾，這樣下游就不需要任何的變動，就可以讓所有的報表曝光相關指標都替換為去掉緩存的統計口徑。由于這個緩存的標記是由客戶端進行的，因此是需要發版本處理的，導致無法對歷史數據進行重刷，只能上線當天開始生效，也就是這個切換日志前后同個指標統計的口徑是不一致的。

基于這個情況一定需要對使用數據的業務方進行宣導，要不然后面非常容易的產生排查，各種業務方來咨詢我的業務數據怎么下降了。

06 緩存標記監控

對于緩存標記當下的bug都已經解決了，但是在客戶端版本迭代的過程中難免會發生開發業務 需求時導致緩存標記出現了bug，數據組需要保證這個緩存標記是穩定可靠的，因此可以基于緩存標記驗證的方案設計一套埋點緩存標記的監控體系，確保所有有緩存機制頁面的緩存標記的準確度都在閾值之內，在發生異常情況時，及時聯系客戶端開發工程師尋找問題修復bug。

07 最后

數據組有責任保證所有提供的數據是準確可靠的，對于這種緩存曝光的統計雖然不是數據開發問題導致的不合理統計結果，但是數據組還是有責任去推動送緩存曝光過濾的項目落地，給業務方更真實的統計結果，確保業務方能使用正確的數據做出合適的決策，驅動業務增長。