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

01 背景

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

02 緩存機制

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

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

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

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

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

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

03 如何過濾緩存曝光數據

1. 簡單方案

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

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

2. 精細化方案

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

這樣就能真正意義上去設别曝光數據是否為緩存曝光。并且對于網絡不佳，雖然展示緩存内容的曝光，可以正确的标記為正常曝光，因為這種場景下用戶也是正常看到了展示的緩存内容，對于數據統計來說确實需要标記為正常曝光。

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 最後

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

作者：杭州@阿坤，母嬰電商行業數據分析師兼數據産品經理，緻力于研究電商行業的數據驅動增長以及數據産品從0到1的搭建；“數據人創作者聯盟”成員。

本文由@一個數據人的自留地 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部