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

01 背景

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

02 緩存機(jī)制

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

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

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

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

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

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

03 如何過濾緩存曝光數(shù)據(jù)

1. 簡單方案

埋點(diǎn)數(shù)據(jù)中有一個參數(shù)是此內(nèi)容的服務(wù)器下發(fā)時間的，因此可以用服務(wù)器下發(fā)時間和客戶端本地的曝光時間進(jìn)行對比，只要是非當(dāng)天的內(nèi)容就內(nèi)容是緩存數(shù)據(jù)，對其進(jìn)行過濾。

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

2. 精細(xì)化方案

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

這樣就能真正意義上去設(shè)別曝光數(shù)據(jù)是否為緩存曝光。并且對于網(wǎng)絡(luò)不佳，雖然展示緩存內(nèi)容的曝光，可以正確的標(biāo)記為正常曝光，因為這種場景下用戶也是正?？吹搅苏故镜木彺鎯?nèi)容，對于數(shù)據(jù)統(tǒng)計來說確實(shí)需要標(biāo)記為正常曝光。

04 如何驗證緩存日志標(biāo)記的準(zhǔn)確度

精細(xì)化方案標(biāo)記緩存日志的方案，由于整個埋點(diǎn)架構(gòu)方案設(shè)計的比較合理，使得進(jìn)行緩存標(biāo)記時客戶端的實(shí)現(xiàn)成本并不高。但是這個曝光數(shù)據(jù)對于業(yè)務(wù)來說是非常重要的數(shù)據(jù)，如果保證客戶端的緩存標(biāo)記的準(zhǔn)確度是足夠的，才能讓這個標(biāo)記上線。

1. 緩存刷新邏輯

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

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

2, 數(shù)據(jù)驗證方案

基于上面2種頁面的緩存刷新邏輯設(shè)計一套數(shù)據(jù)驗證方案，核心驗證的點(diǎn)就是：該標(biāo)記為緩存日志的沒有正確標(biāo)記，不該標(biāo)記為緩存日志的卻錯誤標(biāo)記。

1) 不該標(biāo)記為緩存日志的卻錯誤標(biāo)記

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

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

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

2) 該標(biāo)記為緩存日志的沒有正確標(biāo)記

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

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

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

經(jīng)過各種bug修復(fù)最終得到符合預(yù)期的錯誤標(biāo)記比例后，緩存曝光的標(biāo)記就達(dá)到上了可以上線的標(biāo)準(zhǔn)。

05 曝光統(tǒng)計口徑更變

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

基于這個情況一定需要對使用數(shù)據(jù)的業(yè)務(wù)方進(jìn)行宣導(dǎo)，要不然后面非常容易的產(chǎn)生排查，各種業(yè)務(wù)方來咨詢我的業(yè)務(wù)數(shù)據(jù)怎么下降了。

06 緩存標(biāo)記監(jiān)控

對于緩存標(biāo)記當(dāng)下的bug都已經(jīng)解決了，但是在客戶端版本迭代的過程中難免會發(fā)生開發(fā)業(yè)務(wù) 需求時導(dǎo)致緩存標(biāo)記出現(xiàn)了bug，數(shù)據(jù)組需要保證這個緩存標(biāo)記是穩(wěn)定可靠的，因此可以基于緩存標(biāo)記驗證的方案設(shè)計一套埋點(diǎn)緩存標(biāo)記的監(jiān)控體系，確保所有有緩存機(jī)制頁面的緩存標(biāo)記的準(zhǔn)確度都在閾值之內(nèi)，在發(fā)生異常情況時，及時聯(lián)系客戶端開發(fā)工程師尋找問題修復(fù)bug。

07 最后

數(shù)據(jù)組有責(zé)任保證所有提供的數(shù)據(jù)是準(zhǔn)確可靠的，對于這種緩存曝光的統(tǒng)計雖然不是數(shù)據(jù)開發(fā)問題導(dǎo)致的不合理統(tǒng)計結(jié)果，但是數(shù)據(jù)組還是有責(zé)任去推動送緩存曝光過濾的項目落地，給業(yè)務(wù)方更真實(shí)的統(tǒng)計結(jié)果，確保業(yè)務(wù)方能使用正確的數(shù)據(jù)做出合適的決策，驅(qū)動業(yè)務(wù)增長。