在做資料分析時，我們常常會根據之前的埋點進行統計，但由于緩存沒有反映真實的使用者情況，給後續的分析帶來了一定影響，導緻分析錯誤。面對緩存導緻的無效曝光，該如何解決？作者分享了幾點心得，一起來看看。
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協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。