你是否遭遇過以下場景？

老板：“你提交的報告，怎么和我查的不一樣？”

業(yè)務(wù)部：“ERP 后臺顯示成單 687 筆，你怎么告訴我成單 620 筆？”

運營：“你給我的轉(zhuǎn)化率，為何比實際成單算的轉(zhuǎn)化率低？”

顯然，數(shù)據(jù)準(zhǔn)確性，常常成為企業(yè)爆發(fā)內(nèi)戰(zhàn)的導(dǎo)火索。

數(shù)據(jù)驅(qū)動時代，數(shù)據(jù)準(zhǔn)確性即將成為進一步數(shù)字化、精細化的硬性指標(biāo)，特別是越來越注重用戶行為分析的今天，精益求精，是歷史的趨勢，也是神策數(shù)據(jù)相信的未來。

事實上，排除掉人為因素，或技術(shù)能力限制，不可抗因素導(dǎo)致的數(shù)據(jù)上報不及時或丟失，一般情況下 App 端約占 1%，Web 端約占 5%。這在過去歷史數(shù)據(jù)的洪流中可能激不起波瀾，但在做精細化運營的今天，用戶行為路徑中哪怕只丟失 1% 的數(shù)據(jù)，也可能影響分析結(jié)果或錯失機遇。

比如，漏斗分析、留存分析、歸因分析等模型均為多步驟組合，丟失任一環(huán)節(jié)的數(shù)據(jù)均可能影響最終的結(jié)果。

舉個例子某電商的漏斗模型為：瀏覽商品詳情頁-加入購物車-提交訂單-支付訂單，一般數(shù)據(jù)是實時采集上報，但在極端情況下，部分用戶在提交訂單的數(shù)據(jù)丟失，那么相關(guān)環(huán)節(jié)的轉(zhuǎn)化率將不準(zhǔn)確，分析結(jié)果也會出現(xiàn)誤差。

再比如，若未上報的這 1% 的數(shù)據(jù)，涵蓋極其關(guān)鍵的甚至決定性的事件數(shù)據(jù)，將造成連帶影響，如影響數(shù)據(jù)的完整性。

舉個例子，神策數(shù)據(jù)支持用戶未登錄的匿名行為與登錄后的行為打通，還原完整的用戶全鏈條。在該過程中，存在一個關(guān)鍵事件，用戶登錄的當(dāng)下綁定未登錄之前的行為，如果丟失了這個事件，用戶登錄前的行為就無法匹配了，因為用戶行為鏈條是環(huán)環(huán)相扣的。

綜上，在精益求精的大數(shù)據(jù)時代，丟失哪怕不到 1% 的數(shù)據(jù)，也會牽一發(fā)而動全身。因此，神策堅持使數(shù)據(jù)準(zhǔn)確，且保證數(shù)據(jù)與真實場景發(fā)生的當(dāng)時當(dāng)刻吻合，不容一絲僥幸與意外。

一、關(guān)于數(shù)據(jù)準(zhǔn)確性，你必須知道的事

縱觀大部分?jǐn)?shù)據(jù)應(yīng)用，數(shù)據(jù)處理可以劃分為如下五個步驟，每個步驟都可能影響數(shù)據(jù)準(zhǔn)確性：

圖 1 數(shù)據(jù)處理的五個步驟

總體上看，排除人為因素，通常數(shù)據(jù)準(zhǔn)確性的問題可抽象為 3 種情況：

1. 統(tǒng)計口徑差異

如 App 啟動，很多統(tǒng)計工具使用設(shè)備 ID 計算用戶，將導(dǎo)致同一個登錄 ID 在多設(shè)備使用的情況下使 uv=N。而神策數(shù)據(jù)使用神策 ID 進行計算，可使同一個登錄 ID 在多設(shè)備使用的情況下 uv=1。

2. 代碼采集異常

如客戶端使用匿名 ID 上報數(shù)據(jù)，服務(wù)端使用登錄 ID 上傳數(shù)據(jù)，導(dǎo)致同一用戶沒有關(guān)聯(lián)，系統(tǒng)識別為兩個用戶導(dǎo)致用戶總量不一致，神策數(shù)據(jù)使用同一 ID 上報全端數(shù)據(jù)，支持企業(yè)打通用戶登錄前后行為。

3. 數(shù)據(jù)上報延遲或丟失

數(shù)據(jù)上報往往是通過 http 或者 https 請求進行傳輸，因此網(wǎng)絡(luò)穩(wěn)定性和 App 使用異常均極大的影響上報的及時性。

在這三方面中，數(shù)據(jù)上報延遲或丟失存在非技術(shù)原因的不可抗因素導(dǎo)致，如下圖。

表 1 數(shù)據(jù)延遲場景?

在以上場景中，用戶產(chǎn)生了數(shù)據(jù)，但卻因為非數(shù)據(jù)采集技術(shù)原因?qū)е铝藬?shù)據(jù)的丟失或延遲。針對這一特殊情況，你會選擇在事后進行數(shù)據(jù)的回溯，還是忽略未實時上報的數(shù)據(jù)？

大多數(shù)的直覺答案是“利用數(shù)據(jù)回溯，保證數(shù)據(jù)準(zhǔn)確性”，但數(shù)據(jù)回溯還面臨兩大難題：其一，由于技術(shù)能力限制只能讓數(shù)據(jù)延遲或丟失；其二，同一天的數(shù)據(jù)在不同周期查看會發(fā)生變化，如何向用戶解釋？

因此，大部分?jǐn)?shù)據(jù)分析平臺服務(wù)提供商選擇了犧牲數(shù)據(jù)準(zhǔn)確性，與之不同，神策數(shù)據(jù)精研技術(shù)，通過數(shù)據(jù)的回溯與補充助力企業(yè)堅守數(shù)據(jù)準(zhǔn)確性的紅線。

二、可解釋性 VS 準(zhǔn)確性，神策數(shù)據(jù)的堅持

面對變幻莫測的現(xiàn)實情況，極端情況下的數(shù)據(jù)準(zhǔn)確性和可解釋性總是不可兼得——極端情況下數(shù)據(jù)的丟失易讓人接受，復(fù)雜技術(shù)下堅守的數(shù)據(jù)準(zhǔn)確卻令人費解。

技術(shù)壁壘從不是神策數(shù)據(jù)的難題，但面對客戶潛在的不解，又該如何抉擇？神策堅持選擇數(shù)據(jù)準(zhǔn)確性。

1. 看似正確的“錯誤”，數(shù)據(jù)不應(yīng)該變化？

在數(shù)據(jù)分析行業(yè)中，為保證數(shù)據(jù)的可解釋性，基本上企業(yè)會以當(dāng)天 23 點 59 分 59 秒截止進行數(shù)據(jù)的結(jié)算。由于數(shù)據(jù)分析系統(tǒng)歷史的技術(shù)框架限制，后續(xù)即使有延遲數(shù)據(jù)也不會進行數(shù)據(jù)的補充。長期以往，各企業(yè)習(xí)慣了以當(dāng)天結(jié)算的數(shù)據(jù)為準(zhǔn)，即不管時間周期如何變化，僅看某一天的數(shù)據(jù)是固定不變的，成為大家默認的規(guī)則。當(dāng)數(shù)據(jù)發(fā)生變化，常常會被冠上“數(shù)據(jù)不準(zhǔn)確”的帽子。

?“忽略特殊情況下未上報的數(shù)據(jù)”只是歷史遺留問題，卻被誤認為“正確的事”。因此，變化的數(shù)據(jù)，無疑將增加解釋成本。更難的是，數(shù)據(jù)并不是給 1 個人看的，每個人都可能提出數(shù)據(jù)變化的質(zhì)疑。

首先，數(shù)據(jù)分析的人會困惑數(shù)據(jù)的變化；其次，即使給數(shù)據(jù)分析的人進行了清晰的說明，但向上匯報時，又會衍生新的可解釋性問題。舉個例子，數(shù)據(jù)分析師 A 做了一個報告給老板，報告中記錄周一日活為 14000，但老板周五看的時候發(fā)現(xiàn)周一日活為 14500，因此，數(shù)據(jù)分析師 A 可能會迎來老板的質(zhì)疑，這給 A 帶來困擾，甚至該負面情緒可能并不會因為解釋而消除。

歷史遺留問題加上解釋成本，讓很多數(shù)據(jù)分析企業(yè)望而卻步，有的是出于技術(shù)能力限制，有的是無法面對“約定俗成”的質(zhì)疑。但神策數(shù)據(jù)，選擇堅守信念，只做正確的事情。

三、敢為人先，神策數(shù)據(jù)以變制變

“把事情做到極致”是神策數(shù)據(jù)的做事原則。在數(shù)據(jù)準(zhǔn)確性這件事上，哪怕付出更多的技術(shù)資源和解釋成本，也堅持為“給客戶帶來價值”負責(zé)，面對疑慮，坦然應(yīng)對。

神策數(shù)據(jù)選擇以變制變。目前，使用神策數(shù)據(jù)的企業(yè)數(shù)據(jù)產(chǎn)生后，存在 10 天的回溯期，在此期間查詢相關(guān)的數(shù)據(jù)均可能發(fā)生變化，10 天之后回溯完畢，數(shù)據(jù)將不再變化。

以下，為神策數(shù)據(jù) SDK 緩存上報數(shù)據(jù)的場景：

1. 強殺場景，用戶主動關(guān)閉
對于 Android 用戶來說，用戶常用的關(guān)閉 App 的方式就是退到后臺將 App 劃掉，對于這種場景，埋點數(shù)據(jù)會緩存在本地，未及時上傳，比如退出事件，需要用戶下次打開時進行上報。

2.?多進程觸發(fā)數(shù)據(jù)采集
對于 Android App 來說，多進程場景是很普遍的場景，比如推送場景，或者一些來電服務(wù)的 App，經(jīng)常活動的是子進程，對于這種在子進程埋點業(yè)務(wù)數(shù)據(jù)比較多的場景，需要在主進程啟動時才會將緩存在本地的數(shù)據(jù)進行上報。

3.?沒有網(wǎng)絡(luò)或網(wǎng)絡(luò)信號較差
在電梯或地鐵里由于網(wǎng)絡(luò)信號較差時，可能會出現(xiàn)埋點數(shù)據(jù)無法上報的情況，造成本地緩存埋點數(shù)據(jù)的情況，需要用戶在網(wǎng)絡(luò)條件狀況良好時，重新進行數(shù)據(jù)上報。

4. App 異常退出
App 異常是最普遍的一個場景了，當(dāng) App 出現(xiàn)異常退出時，可能會造成部分埋點數(shù)據(jù)無法及時上傳，待用戶下次打開 App 時重新上傳。

5.?iOS 被動啟動
在 iOS 中，當(dāng) App 由于一些原因（例如靜默推送）被動啟動時，采集的所有事件會在 App 下次啟動時上傳數(shù)據(jù)。

俗話說，“你不能解決問題，你就會成為問題”。在面對數(shù)據(jù)準(zhǔn)確性的歷史挑戰(zhàn)，神策數(shù)據(jù)選擇了更艱難的一條路，這條路雖然會偶遇客戶的不解，但其終點是給客戶帶來更大的價值，神策數(shù)據(jù)矢志不渝。同時，若客戶因特殊原因，理解背景后仍堅持保持?jǐn)?shù)據(jù)不變，我們也給予了靈活的策略，可將回溯周期降低為 24 小時。此外，神策也會優(yōu)化產(chǎn)品，如增加小提示，促進客戶的理解。

在過去的 5 年里，神策數(shù)據(jù)服務(wù)了 1000 余家企業(yè)，未來將為更多的企業(yè)解決數(shù)據(jù)根基問題。背負著客戶的未來，神策數(shù)據(jù)面對歷史的難題，堅持以變應(yīng)變，以變制變，力求在大數(shù)據(jù)時代，為即將到來的數(shù)據(jù)準(zhǔn)確性變革領(lǐng)航，更為客戶保駕護航。

立足于重構(gòu)中國互聯(lián)網(wǎng)數(shù)據(jù)根基的愿景，關(guān)于數(shù)據(jù)準(zhǔn)確性，神策數(shù)據(jù)捍衛(wèi)到底，決不允許一絲的僥幸與意外。

???

【更多內(nèi)容】

• 銀行 4.0 時代，打開客戶標(biāo)簽五扇門，高效賦能數(shù)據(jù)化運營
  

• 還沒真正理解用戶標(biāo)簽體系？看這篇就夠了！
  

• 神策數(shù)據(jù)保險行業(yè)解決方案，正式上線官網(wǎng)！

點擊“閱讀原文”，體驗 demo~

總結(jié)

以上是生活随笔為你收集整理的关于数据准确性，精益求精，神策数据矢志不渝的坚持的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。