如何處理快取導致的無效曝光

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的搭建；“資料人創作者聯盟”成員。