為什麼要關心資料來源？談談埋點數據的陷阱
先想想兩個發現，你會怎麼理解？
- 分析X頁面跳Y頁面的場景時，出現了X頁面跳X頁面的數據？
2. 註冊流程頁面為A->B->C，但是出現Ｃ頁面瀏覽量比B頁面還高？
(可以直接拉到文章後面看解答)
邀請你至Blog閱讀全文：透過埋點，讓數據說話：埋點基本知識
如果你喜歡我的文章，也邀請你訂閱『Rock Data』電子報，支持我持續創作
數據分析，字面意思，數據分析由兩個部分組成：一是數據，二是分析，看起來跟廢話一樣，但卻也是絕大多數人都忽略的。
大多數人更加註重的是分析，而並不是數據本身，這就造成了數據分析最大的誤區：不關心數據怎麼來，使勁做無用功。
最近在從埋點日誌做分析，因為埋點的複雜性、產品線的多元性，以及用戶行為的多樣性，在資料校驗的過程中花費了大量精力。
因此，透過最近使盡全力避免踩到坑的實際例子，來感受一下為什麼關心資料來源很重要。
為何要埋點？
首先想一下最根本的問題，埋點有什麼好處？或是說不埋點會有什麼問題？難道用GA不好嗎？
我認為這問題是看你是什麼角色，或是說想分析到什麼階段。
像以GA或是任何第三方統計平台來進行追蹤，對於負責市場投放或是負責網站優化的人來說，這些功能已經可以滿足，對公司也節省心力。
然而，進行全棧流程的梳理，或是多樣化的分析需求時，就會遭遇一些麻煩了。
分析的問題：
用戶搜索行為、瀏覽行為的資料存在後台，而用戶註冊或是付費等數據是在內部資料庫；分析時無法合併兩邊數據的維度，或是合併很困難。只能做半套，意味著只能看到一半的真相。
平台的問題：
在中國GA需要翻牆，數據會計漏；growing IO強於細緻的用戶行為數據分析，同時宣稱可以無代碼埋點。然而無代碼埋點又必須符合他的框架寫法才行，不然數據統計不上或者出錯。然而，開發也不一定能改掉自己的寫法。另外，細緻的用戶行為數據分析，在實際分析操作上也是要一段時間熟悉。
翻開覆蓋的陷阱卡…
資料會有許多無預期的坑， 最可怕的坑不是指沒有數據、數據不足、或是數據缺失(Null\NaN)等，而是數據乍看很完整的情況下，卻處處充滿陷阱。
確認跟基礎表的數據落差，埋點是會丟失的
- 原因1. 該產品點位沒埋；
- 原因2. 該產品有埋，但有遺漏幾個入口沒埋到；
- 原因3. 響應過程中的丟失；
- 原因4. 網頁曾經改版，埋點數據丟失；
非常多可能性，導致埋點错误，從而導致數據錯誤，再導致分析結論錯誤，舉個例子：
移動端網站的新版本上線，上了一段時間數據穩定後，從數據發現，哎喲，這個新網站效果很好啊，尤其是某個入口來的用戶付費轉化率很高，恩，產品經理表示將要爭取資源大力推廣。
然而，不幸的消息來了！程序員在數據埋點的時候把另一個入口的點位埋了在一起了，也就是說，分母其實是要增加的，相對轉化率就低了…
字段間彼此間的邏輯會很奇怪，未必是資料有誤，要確認數據紀錄的邏輯
- 例如該landing page訪問來源(即上一頁域名)是社交媒體，投放渠道卻是google，此原因為用戶之前在google的行為已被keep住(keep帶n小時)；
- X跳Y頁面場景，手機鎖屏再打開時，前端會重新發送一條頁面進入事件，導致會發生X頁面跳X頁面的數據；
- 註冊流程A->B->C是唯一的，但是在user已有帳號的情況下，A頁面發送時，前端判別後會跳過B步驟直接C，因此出現Ｃ頁面瀏覽量比B高；
結論
交叉驗證，小心求證，搞懂記錄的邏輯，摸清產品操作運行方式
- 可能因為不同程序員的頁面代碼寫法不同，計算結果不同；
- 可能因為埋點過程中沒有溝通好，出現理解偏差，計算結果不同；
- 可能因為開發不小心埋錯點或是遺漏了，計算結果不同；
- 可能因為版本迭代修改了某個地方，導致計算結果不同；
邀請你至Blog閱讀全文：透過埋點，讓數據說話：埋點基本知識
如果你喜歡我的文章，也邀請你訂閱『Rock Data』電子報，支持我持續創作
補充
撈資料時的優化：
- 埋點日誌很大，為了性能考量，使用时一定不能掃全表，要做分區表(partition function)
- 根據可能需求或據業務線，開發適當數據中間層
- 針對漏斗的環節建立中間表，舉例用戶瀏覽行為一張，註冊到付費一張，對效能及分析上的彈性會有幫助
- 有很多map類型的字段，取具體key的值的时候 ，hive 语法 ：column[‘key’] 例：context[‘appsdk_version’] ， presto语法：element_at(column,’key’) 例：element_at(context,’appsdk_version’)
埋點小知識：
好文章，參考一下~
邀請你至Blog閱讀全文：透過埋點，讓數據說話：埋點基本知識
如果你喜歡我的文章，也邀請你訂閱『Rock Data』電子報，支持我持續創作
1. Hello All：主站遷移至👉https://andyrockdata.com/ ，請改至『ROCK DATA』Blog 閱讀新文章完整內容，如果喜歡我的文章，可以訂閱我的電子報(Medium站仍將張貼新文章訊息)2.立即追蹤👉ROCK DATA臉書粉絲頁跟ROCK DATA IG(@andyrockdata)3.【入門數據分析，掌握HiveSQL取數能力】在hahow上架啦，購買連結👉 http://hahow.in/cr/andyrockhive4. 往期的數據相關文章可以參考以下link
- 數據分析系列1：談談數據分析的眾多Title
- 數據分析系列2：數據分析的一週工作日程
- 數據分析系列3：身為資料分析師，你該如何展現工作中的價值？
- 數據分析系列4：如何量化職場規劃？我這次的轉職規劃與Offer選擇
- 數據分析系列5：為什麼要關心資料來源？談談埋點數據的陷阱
- 數據分析系列6：精選幾個機器學習的學習資源
- 數據分析系列7：數位化決策轉型與企業文化的一些思考
- 數據分析系列8：中山大學經濟所職涯座談(ㄧ)：”了解自己”的重要＆我怎麼成為數據分析師
- 數據分析系列9：中山大學經濟所職涯座談(二)：想從事資料分析？你需要具備這8個能力
- 數據分析系列10：中山大學經濟所職涯座談(三) ：讓資料變商機 — 資料分析在我們生活中的應用
- 數據分析系列11：面試時，資料分析師該怎麼準備作品集？
- 數據分析系列12：2018年終工作總結(數據分析師)
- 數據分析系列13：數據化運營中玩過的分析項目：一個數據分析師的經驗總結
- 數據分析系列14：如何提升運營/產品的優化效率？或許數據指標體系的搭建可以幫到忙
- 數據分析系列15：用戶畫像很重要，那你知道是怎麼畫出來的嗎？
- 數據分析系列16：給剛入行的數據分析師：想產生價值，在試用期要做的三件事
- 數據分析系列17：2019 數據分析工作總結_關鍵詞：數倉構建、BI可視化看板、用戶畫像(標籤)與精準行銷
- 數據分析系列18：入門數據分析的第一個大門檻：SQL/Hive取數-聊聊自身學習SQL的經歷以及三個自學網站分享
- 數據分析系列19：身為數據分析師，我怎麼看hahow上”R語言和商業分析”這門課
- 數據分析系列20：直接用SQL來分析數據？怎麼沒用python/R？3個面向來考量分析工具的選擇
- 數據分析系列21：數據分析的”橫向”學習之路-珍藏的網上文章重新整理放上github
- 數據分析系列22：透過埋點，讓數據說話：埋點基本知識
- 數據分析系列23：以數據為核心的CRM進化產品：帶你了解CDP(客戶數據平台)開發過程與難點
- 數據分析系列24：SQL不難啊，為什麼不容易精通？自學與實務的4個落差
- 數據分析系列25：數據分析基本-相關分析與可視化(R語言)
- 數據分析系列26：刷完了Leetcode SQL Hard Level的28道題：歡迎領取參考答案
- 數據分析系列27：數據太髒了！3個步驟做好數據質量管理
- 數據分析系列28：跨部門溝通成本太高？數據人實現高效跨部門溝通的4個方式
- 數據分析系列29：數據分析師職場發展的另類出路
- 數據分析系列30：Databrick為何收購BI產品Redash？產品視角來看Redash的功能與價值
- 數據分析系列31：數據分析師要失業了？解讀<2022 Gartner BI魔力象限> BI產品趨勢
- 數據分析系列32：Google Data Catalog如何幫忙管理數據？ 產品介紹與體驗心得
- 數據分析系列33：復盤：數據產品從0到1的建設過程，我的9點感觸
- 數據分析系列34：Shopline-數據分析中心(Shoplytics)產品體驗
- 數據分析系列35：搞數據還是做產品？淺談『數據產品經理』
