策略產品思考:數(shù)據(jù)埋點的一些小坑總結
編輯導語:什么是數(shù)據(jù)埋點?本篇作者給我們介紹了數(shù)據(jù)埋點的小坑總結以及脫坑指南,一起來看一下。
一、寫在之前:什么是數(shù)據(jù)埋點?
簡單來說,埋點就是部署在前端,或服務端的一段代碼,當用戶觸發(fā)了某種特定的操作,這段代碼就會生成一條數(shù)據(jù)發(fā)送到數(shù)據(jù)庫里,這條數(shù)據(jù)會記錄哪個用戶在什么時候在哪個場景以什么樣的方式做了一件什么樣的事。
核心邏輯是“觸發(fā)-記錄-上傳”,業(yè)務人員先確定自己需要分析哪方面的數(shù)據(jù),研究用戶可能的行為軌跡,并在關鍵節(jié)點上做好“埋伏”(記錄),再上傳給客戶端或者Server端,最后落到數(shù)據(jù)表中,這是一套完整的數(shù)據(jù)采集工作。
比如我們常常提及的DAU、互動數(shù)、留存率,這些指標以及更復雜的數(shù)據(jù),都依賴于埋點來提供準確數(shù)據(jù)。
關于數(shù)據(jù)埋點更詳細的解釋,可以參考:《當我們在談論數(shù)據(jù)埋點時,我們在談論些什么?》
二、數(shù)據(jù)埋點小坑總結
筆者在策略產品工作中,不免常常與數(shù)據(jù)打交道,發(fā)現(xiàn)這其中的坑簡直多到不可想象,真的讓人不得不感嘆還能這樣,下面就是我覺得最容易跳的幾個坑。
1. 想要找的埋點找不到
這是最常出現(xiàn)的,我們想找一個數(shù)據(jù)的埋點,但怎么也找不到,自己也難以確定是沒有打過,還是說這個點位在某個角落默默等著人來用。
產生這種情況主要有兩種:
- 數(shù)據(jù)埋點缺乏統(tǒng)一的查詢管理平臺。
- 數(shù)據(jù)埋點字段名不規(guī)范 or 中文名不準確。
針對第一點,其實在進行埋點規(guī)劃的時候,一般都會有一個文檔或者平臺能夠讓使用者對打點情況進行查詢的。但是在真正執(zhí)行的時候,因為平臺或者文檔與實際打點缺乏強綁定性,總會出現(xiàn)點位更新不及時、或者是老點有變動但沒有在平臺或者文檔上更新,導致查詢工作變得復雜且困難。
而第二點,也是我個人很想吐槽的一點,在埋點時候缺乏對點位名字的思考,比如首頁曝光的打點居然會叫“batch/c10705”(真實案例),請問這種埋點如果不看文檔,誰知道它什么意思?體現(xiàn)的是埋點者在埋點前的思維惰性。
2. 埋點重復,不知選哪個可信
同樣是真實情況中經常出現(xiàn)的情況,同樣意義的點位會打上多次,出現(xiàn)的原因有可能是以下兩種:
- 存量埋點Owner離職或者轉崗,導致大量僵尸埋點信息,與第一個坑有耦合。
- 老點因為業(yè)務變動導致拓展性差,修復困難,因此通過新點替代,但牽扯之前業(yè)務,因此老點也無法現(xiàn)在廢除。
而因為查詢平臺與文檔的缺失,導致不知道選哪個可信,以及用不同打點測出來數(shù)據(jù)值差異較大,應該信哪個,這時候的建議可能是看打點時間,盡量以新的為準,一般來說新的埋點會更適配當下業(yè)務情況。
3. 埋點雜糅,一個點位什么都打了
對于數(shù)據(jù)埋點者,一個常犯的錯誤是將過多的埋點任務放到一個urlkey上,并通過子字段進行場景或者行為的區(qū)分,這種很多時候是非常不合理的,比如點擊的打點,打的是對內容的點擊行為,但如果把點贊,轉發(fā)等行為也記錄在內,顯然是不合理的。
雖然廣義上點贊也是一種點擊行為,但很少有在業(yè)務上要對兩者進行統(tǒng)一統(tǒng)計的情況,更多時候是分開看點擊和點贊行為,這樣打在一個點位上,除了給數(shù)據(jù)分析增加不必要的困難,也會讓點位的維護變得復雜困難。
4. 錯埋、漏埋頻發(fā)
在數(shù)據(jù)分析中,很大一個感受就是每次根據(jù)一個點位做數(shù)據(jù)分析對比的時候,總會發(fā)現(xiàn)點位存在錯埋、漏埋的問題,這讓我們數(shù)據(jù)分析的工作變得滯澀,很多時候都在填之前打點時留下的坑。
對于PM來說,一個忠告是:
千萬不要忽視打點需求的驗收環(huán)節(jié)!千萬不要忽視打點需求的驗收環(huán)節(jié)!千萬不要忽視打點需求的驗收環(huán)節(jié)!
重要的事情說三遍,很多人包括我本人之前,都覺得打點需求相對比較簡單,寫清楚需求文檔,驗收的時候卻不怎么上心,過分相信了rd和qa,這種惰性也讓我后續(xù)做了多次埋點的補充需求,重復造輪子。
找到負責的rd,仔細過一遍埋點的觸發(fā)邏輯,點位信息,在和qa一塊showcase時測試線上環(huán)境下埋點準確性和全面性,相信我,雖然繁瑣一點,但一定是良好的工作習慣。
我司有一句文化論語:“每個人都要撿起地上的垃圾”,共勉。
三、數(shù)據(jù)埋點脫坑指南
1. 埋點統(tǒng)一管理:可查可回溯
一個埋點統(tǒng)一管理的平臺,能夠在你后續(xù)進行埋點查詢,數(shù)據(jù)分析的時候節(jié)省至少50%的人力和精力(數(shù)據(jù)無依據(jù),強調重要性)。
有一個優(yōu)秀的埋點平臺也是不夠的,還需要在打點變動時能夠在平臺上進行更新,而眾所周知,不論是rd還是pm總是缺乏動力去做這個事情的,而且容易忘記,因此應該有一種機制來確保兩者能對應,不然久而久之,平臺查詢的不準,大家對于平臺的使用也不能做到放心,喪失其本身的意義。
筆者個人認為,埋點更多還是應該需要PM來發(fā)揮owner意識,因為有更多數(shù)據(jù)分析處理需求的還是PM。
有幾個可能有效的方法能提升同步的及時性和準確性:
- 同步工作前置,埋點變動時需要先在平臺管理上進行提交,才能處理,驗收時必須平臺上確認才能完成驗收。
- 分版本review機制,因為埋點一般需要隨版(端內埋點),每次版本開發(fā)完之后,會有負責需求和收益匯總的PM或者PMO,這時候他其中一項任務就應該是double check埋點管理平臺是否同步版本埋點變更信息。
2. 埋點方式:基于事件還是基于場景打點題
在這個部分,想和大家探討一個問題:
數(shù)據(jù)埋點應該基于事件還是基于場景?
我個人感覺是要基于事件。
基于場景的邏輯是分場景來埋點,舉抖音的例子,發(fā)生在推薦頁的打點應該是與發(fā)生在關注頁的區(qū)分,同一個動作,比如點贊,推薦頁點贊應該是和關注頁點贊不是一個點位。
而基于事件的意思是基于用戶行為,來做大點位的區(qū)分,比如內容的曝光,可以打一個點common_exp,在通過該點位的子字段來對場景進行區(qū)分。
我個人覺得應該基于用戶行為,主要是考慮到不管是哪個場景的曝光行為,對于用戶來說,操作方式是一致的,如果分開打復雜度就變高了。以及管理和整體數(shù)據(jù)分析的維度上,這種埋點方式也比分場景打點更簡單。
3. 埋點范圍:點位的顆粒度應該怎么定
當然,基于事件埋點也有兩個問題需要考慮:
1)怎么做到不重不漏?
因為基于事件的打點是一種歸納方式,那么分類怎么做到不重不漏,就是一門學問。筆者個人想法是應該在整體埋點之前有一個清晰的劃分,最好通過腦圖的方式將產品可能涉及到的點位列出來,然后分析點位之間的關聯(lián)性,再通過分類體系將其串聯(lián)起來。
2)怎么避免一個點位雜糅,復雜度太高?
這個是點位的顆粒度考慮,需要前置了解的是,一個點位并不是包含越多信息越好,因為太復雜,點位出錯的概率也容易變高,以及后續(xù)進行數(shù)據(jù)拆分也更困難。
在此筆者的經驗有兩點:
- 整體埋點之前,做全局思考,盡量做到不重不漏,一個點位的子字段除了常規(guī)的,特殊的子字段最好不要超過5個。
- 對于不太好放到原有埋點體系中的點位,不要硬揉,可以新增點位,而不是直接放到一個類似的點位,并通過子字段進行區(qū)分。
四、近期的一點工作和生活思考
埋點是個永恒的難題,我們可能很難做到完全清晰,點位還統(tǒng)計簡單,如果做到了,只有一個可能:你負責的產品業(yè)務復雜度不高。
但這也不是我們對于埋點惰性處理的理由,盡可能的多思考,埋點之前多想兩點,都是十分有價值的。
1. 批評阻礙進一步深度思考
最近看的《李誕脫口秀工作手冊》中,有這么一段話讓我很是警醒:
批評家不是一個體面的職業(yè),還是一個有害的人格。
我在過往的生活工作中,心里總站著一個小人,對于所有覺得不合理不優(yōu)美的事情和人做著無情的吐槽,這就是所謂“批評家的人格”,這種小人出現(xiàn)的時候,反映在與人對話中,就表現(xiàn)成了“我覺得不對,xxx”,縱然很多時候你提出的問題并沒有問題,但這種思考方式也阻隔了自己進步和吸取他人處理事情方式優(yōu)點的道路。
本質就是提出問題并不難,而解決問題才是更有價值和更有利成長的。
2. 同理心體現(xiàn)不僅在與用戶共情,還有跨部門合作時
在進行跨部門合作時,我們應該更多像那個部門的人那樣思考,為什么ta在推行這個項目時沒有動力?為什么每次和ta溝通,總是在很多點上存在分歧與矛盾,而且額難以調和?
如果多站在部門合作方的角度去思考問題,才能從更全面更宏觀的角度分析問題,推動事情更好的往下。
#專欄作家#
隨心將夜,微信公眾號 : 互聯(lián)網(wǎng)菜鳥產品進階之路,人人都是產品經理專欄作家。關注社交賽道和社區(qū)發(fā)展,擅長分析行業(yè)趨勢。
本文由原創(chuàng)發(fā)布于人人都是產品經理,未經許可,禁止轉載
題圖來自Unsplash,基于CC0協(xié)議
我個人覺得應該基于用戶行為,主要是考慮到不管是哪個場景的曝光行為,對于用戶來說,操作方式是一致的,如果分開打復雜度就變高了。
— 這個想跟作者探討下,也是看了其他文章里有說對于一些比較重要的場景,可以單獨抽出來,因為都歸在一個行為事件里,會讓這一個事件變得非常復雜。