看到 caoz 推薦了這本書, 趕緊買來讀一讀, 寫一寫筆記.
我猜大家還是驅(qū)動決策
方面做得多
痛苦: 埋點混亂, 常規(guī)埋錯, 漏埋
看來大家都需要一個完善的埋點需求管理工具, 在英語流利說淮蜈,我們這樣管理數(shù)據(jù)采集需求 拿走不謝
無奈: 數(shù)據(jù)團(tuán)隊和業(yè)務(wù)工程團(tuán)隊配合困難
首先, 求"快", 數(shù)據(jù)分析讓路產(chǎn)品升級
其次, KPI 驅(qū)動, 數(shù)據(jù)團(tuán)隊需求得不到重視
關(guān)于 數(shù)據(jù)分析讓路產(chǎn)品升級
, 書中給出的回答也足夠日后拿來懟類似場景了: 沒有數(shù)據(jù)支撐, 如何衡量產(chǎn)品做得是否合理?
關(guān)于 KPI 驅(qū)動, 數(shù)據(jù)團(tuán)隊需求得不到重視
, 我覺得還是看老板: 老板的風(fēng)格就是數(shù)據(jù)驅(qū)動, 天天跟業(yè)務(wù)方要數(shù)據(jù), 你說數(shù)據(jù)團(tuán)隊的需求業(yè)務(wù)方配合不配合? 相反, 靠業(yè)務(wù)方主動根據(jù)數(shù)據(jù)反饋優(yōu)化功能, 你怎么保證你找來的產(chǎn)品經(jīng)理不是憑借自身感覺做事的"藝術(shù)家"? 數(shù)據(jù)團(tuán)隊作為業(yè)務(wù)支持部門, 還是要盡力避免"皇上不急太監(jiān)急"的尷尬.
數(shù)據(jù)采集遵循法則
讓數(shù)據(jù)驅(qū)動落地企業(yè), 數(shù)據(jù)采集的質(zhì)量將決定數(shù)據(jù)分析的深度. 其中, 數(shù)據(jù)源是最重要的.
這一點深有同感, Garbage In, Garage Out
法則. 在數(shù)據(jù)質(zhì)量上我們也走了一些彎路, 花費了很多功夫. 還是很好奇 SensorData 自己的 SDK 是如何保障數(shù)據(jù)質(zhì)量的.
數(shù)據(jù)采集的四個法則: 大, 全, 細(xì), 時
- "大"強(qiáng)調(diào)的是宏觀的大, 這不只需要海量數(shù)據(jù), 還要從系統(tǒng)的角度去考慮
- "全"強(qiáng)調(diào)多種數(shù)據(jù)源. 對于用戶行為分析來說, 不但要采集客戶端數(shù)據(jù), 還要采集服務(wù)端日志, 業(yè)務(wù)數(shù)據(jù)庫, 以及第三方數(shù)據(jù), 全面覆蓋, 而且是全量數(shù)據(jù).
- "細(xì)"要求把不同的維度都采集下來. 對于用戶行為來說, 我們要采集 Who, When, Where, How, What 等信息. 如果缺失會導(dǎo)致重新采集, 延長迭代周期
- "時" 則強(qiáng)調(diào)時效性
實際工作中, "大"可作為宏觀考量, 重點關(guān)注"全"和"細(xì)", 而"時"可以根據(jù)業(yè)務(wù)場景靈活把控, 畢竟數(shù)據(jù)的時效性是有成本的.
這個四個原則中, 全
細(xì)
時
我非常贊同, 并且也是這樣實踐的, 尤其后續(xù)總結(jié)畢竟數(shù)據(jù)的時效性是有成本的
這一語道破真諦.
而關(guān)于大
的描述, 我看著有些虛, 或許是境界不夠吧.
總結(jié)一句話: 一旦企業(yè)有復(fù)雜的分析需求, 就必須進(jìn)行代碼埋點, 否則數(shù)據(jù)無法進(jìn)行靈活下鉆.
使用后端埋點會有一個問題: 維度采集的問題. 上文也提到數(shù)據(jù)采集要盡量細(xì)
: Who, When, Where, How, What 都要帶著, 但后端請求可能在當(dāng)次請求時能拿到的維度信息不夠(例如沒有設(shè)備相關(guān)的信息等), 解決的辦法也無外乎這幾種:
- 后續(xù) ETL 的時候補(bǔ)數(shù)據(jù), 靠 ETL 計算出用戶 session 期間的設(shè)備信息, 然后補(bǔ)全到后端埋點數(shù)據(jù)中.
- 在用戶首次請求時保存設(shè)備 Context 信息到緩存中, 后續(xù)埋點通過緩存將數(shù)據(jù)補(bǔ)齊.
導(dǎo)致數(shù)據(jù)不準(zhǔn)確的幾個原因
- 網(wǎng)絡(luò)異常
- 統(tǒng)計口徑不同
- 代碼質(zhì)量問題
- 無效請求
關(guān)于 網(wǎng)絡(luò)異常
代碼適量問題
, 我想解決的辦法只有一個: 讓最靠譜的工程師來開發(fā)這個 SDK, 并給充足的時間和耐心進(jìn)行測試.
關(guān)于統(tǒng)計口徑不同
, 我的看法是統(tǒng)一口徑是一個方面, 另一個方面就是方便閱讀數(shù)據(jù)計算邏輯, 例如如果用 SQL 開發(fā), 那么這個結(jié)果使用了哪些數(shù)據(jù), 這些數(shù)據(jù)的來源是如何, 如何方便的看到代碼, 開發(fā)過程是否有 code review, 這后面其實是整個數(shù)據(jù)開發(fā)平臺工具鏈的建設(shè), 非一日之功.
今天暫時寫到這里, 改天繼續(xù).
-- EOF --