策略產品思考:資料埋點的一些小坑總結

編輯導語:什麼是資料埋點?本篇作者給我們介紹了資料埋點的小坑總結以及脫坑指南,一起來看一下。

策略產品思考:資料埋點的一些小坑總結

一、寫在之前:什麼是資料埋點?

簡單來說,埋點就是

部署在前端,或服務端的一段程式碼

,當用戶觸發了某種特定的操作,這段程式碼就會生成一條資料傳送到資料庫裡,這條資料會記錄

哪個使用者在什麼時候在哪個場景以什麼樣的方式做了一件什麼樣的事

核心邏輯是“觸發-記錄-上傳”,業務人員先確定自己需要分析哪方面的資料,研究使用者可能的行為軌跡,並在關鍵節點上做好“埋伏”(記錄),再上傳給客戶端或者Server端,最後落到資料表中,這是一套完整的資料採集工作。

比如我們常常提及的DAU、互動數、留存率,這些指標以及更復雜的資料,都依賴於埋點來提供準確資料。

關於資料埋點更詳細的解釋,可以參考:《當我們在談論資料埋點時,我們在談論些什麼?》

二、資料埋點小坑總結

筆者在策略產品工作中,不免常常與資料打交道,發現這其中的坑簡直多到不可想象,真的讓人不得不感嘆還能這樣,下面就是我覺得最容易跳的幾個坑。

1. 想要找的埋點找不到

這是最常出現的,我們想找一個數據的埋點,但怎麼也找不到,自己也難以確定是沒有打過,還是說這個點位在某個角落默默等著人來用。

產生這種情況主要有兩種:

資料埋點缺乏統一的查詢管理平臺。

資料埋點欄位名不規範 or 中文名不準確。

針對第一點,其實在進行埋點規劃的時候,一般都會有一個文件或者平臺能夠讓使用者對打點情況進行查詢的。但是在真正執行的時候,因為平臺或者文件與實際打點缺乏強繫結性,總會出現點位更新不及時、或者是老點有變動但沒有在平臺或者文件上更新,導致查詢工作變得複雜且困難。

而第二點,也是我個人很想吐槽的一點,在埋點時候缺乏對點位名字的思考,比如首頁曝光的打點居然會叫“batch/c10705”(真實案例),請問這種埋點如果不看文件,誰知道它什麼意思?體現的是埋點者在埋點前的思維惰性。

2. 埋點重複,不知選哪個可信

同樣是真實情況中經常出現的情況,同樣意義的點位會打上多次,出現的原因有可能是以下兩種:

存量埋點Owner離職或者轉崗,導致大量殭屍埋點資訊,與第一個坑有耦合。

老點因為業務變動導致拓展性差,修復困難,因此透過新點替代,但牽扯之前業務,因此老點也無法現在廢除。

而因為查詢平臺與文件的缺失,導致不知道選哪個可信,以及用不同打點測出來資料值差異較大,應該信哪個,這時候的建議可能是

看打點時間,儘量以新的為準

,一般來說新的埋點會更適配當下業務情況。

3. 埋點雜糅,一個點位什麼都打了

對於資料埋點者,一個常犯的錯誤是將過多的埋點任務放到一個urlkey上,並透過子欄位進行場景或者行為的區分,這種很多時候是非常不合理的,比如點選的打點,打的是對內容的點選行為,但如果把點贊,轉發等行為也記錄在內,顯然是不合理的。

雖然廣義上點贊也是一種點選行為,但很少有在業務上要對兩者進行統一統計的情況,更多時候是分開看點選和點贊行為,這樣打在一個點位上,除了給資料分析增加不必要的困難,也會讓點位的維護變得複雜困難。

4. 錯埋、漏埋頻發

在資料分析中,很大一個感受就是每次根據一個點位做資料分析對比的時候,總會發現點位存在錯埋、漏埋的問題,這讓我們資料分析的工作變得滯澀,很多時候都在填之前打點時留下的坑。

對於PM來說,一個忠告是:

千萬不要忽視打點需求的驗收環節!千萬不要忽視打點需求的驗收環節!千萬不要忽視打點需求的驗收環節!

重要的事情說三遍,很多人包括我本人之前,都覺得打點需求相對比較簡單,寫清楚需求文件,驗收的時候卻不怎麼上心,過分相信了rd和qa,這種惰性也讓我後續做了多次埋點的補充需求,重複造輪子。

找到負責的rd,仔細過一遍埋點的觸發邏輯,點位資訊,在和qa一塊showcase時測試線上環境下埋點準確性和全面性,相信我,雖然繁瑣一點,但一定是良好的工作習慣。

我司有一句文化論語:“每個人都要撿起地上的垃圾”,共勉。

三、資料埋點脫坑指南

1. 埋點統一管理:可查可回溯

一個埋點統一管理的平臺,能夠在你後續進行埋點查詢,資料分析的時候節省至少50%的人力和精力(資料無依據,強調重要性)。

有一個優秀的埋點平臺也是不夠的,還需要在打點變動時能夠在平臺上進行更新,而眾所周知,不論是rd還是pm總是缺乏動力去做這個事情的,而且容易忘記,因此應該有一種機制來確保兩者能對應,不然久而久之,平臺查詢的不準,大家對於平臺的使用也不能做到放心,喪失其本身的意義。

筆者個人認為,埋點更多還是應該需要PM來發揮owner意識,因為有更多資料分析處理需求的還是PM。

有幾個可能有效的方法能提升同步的及時性和準確性:

同步工作前置,埋點變動時需要先在平臺管理上進行提交,才能處理,驗收時必須平臺上確認才能完成驗收。

分版本review機制,因為埋點一般需要隨版(端內埋點),每次版本開發完之後,會有負責需求和收益彙總的PM或者PMO,這時候他其中一項任務就應該是double check埋點管理平臺是否同步版本埋點變更資訊。

2. 埋點方式:基於事件還是基於場景打點題

在這個部分,想和大家探討一個問題:

資料埋點應該基於事件還是基於場景?

我個人感覺是要基於事件。

基於場景的邏輯是分場景來埋點,舉抖音的例子,發生在推薦頁的打點應該是與發生在關注頁的區分,同一個動作,比如點贊,推薦頁點贊應該是和關注頁點贊不是一個點位。

而基於事件的意思是基於使用者行為,來做大點位的區分,比如內容的曝光,可以打一個點common_exp,在透過該點位的子欄位來對場景進行區分。

我個人覺得應該基於使用者行為,主要是考慮到不管是哪個場景的曝光行為,對於使用者來說,操作方式是一致的,如果分開打複雜度就變高了。以及管理和整體資料分析的維度上,這種埋點方式也比分場景打點更簡單。

3. 埋點範圍:點位的顆粒度應該怎麼定

當然,基於事件埋點也有兩個問題需要考慮:

1)怎麼做到不重不漏?

因為基於事件的打點是一種歸納方式,那麼分類怎麼做到不重不漏,就是一門學問。筆者個人想法是應該在整體埋點之前有一個清晰的劃分,最好透過腦圖的方式將產品可能涉及到的點位列出來,然後分析點位之間的關聯性,再透過分類體系將其串聯起來。

2)怎麼避免一個點位雜糅,複雜度太高?

這個是點位的顆粒度考慮,需要前置瞭解的是,一個點位並不是包含越多資訊越好,因為太複雜,點位出錯的機率也容易變高,以及後續進行資料拆分也更困難。

在此筆者的經驗有兩點:

整體埋點之前,做全域性思考,儘量做到不重不漏,一個點位的子欄位除了常規的,特殊的子欄位最好不要超過5個。

對於不太好放到原有埋點體系中的點位,不要硬揉,可以新增點位,而不是直接放到一個類似的點位,並透過子欄位進行區分。

四、近期的一點工作和生活思考

埋點是個永恆的難題,我們可能很難做到完全清晰,點位還統計簡單,如果做到了,只有一個可能:

你負責的產品業務複雜度不高

但這也不是我們對於埋點惰性處理的理由,儘可能的多思考,埋點之前多想兩點,都是十分有價值的。

1. 批評阻礙進一步深度思考

最近看的《李誕脫口秀工作手冊》中,有這麼一段話讓我很是警醒:

批評家不是一個體面的職業,還是一個有害的人格。

我在過往的生活工作中,心裡總站著一個小人,對於所有覺得不合理不優美的事情和人做著無情的吐槽,這就是所謂“批評家的人格”,這種小人出現的時候,反映在與人對話中,就表現成了“我覺得不對,xxx”,縱然很多時候你提出的問題並沒有問題,但這種思考方式也阻隔了自己進步和吸取他人處理事情方式優點的道路。

本質就是

提出問題並不難,而解決問題才是更有價值和更有利成長的

2. 同理心體現不僅在與使用者共情,還有跨部門合作時

在進行跨部門合作時,我們應該更多像那個部門的人那樣思考,為什麼ta在推行這個專案時沒有動力?為什麼每次和ta溝通,總是在很多點上存在分歧與矛盾,而且額難以調和?

如果多站在部門合作方的角度去思考問題,才能從更全面更宏觀的角度分析問題,推動事情更好的往下。

#專欄作家#

隨心將夜,微信公眾號 : 網際網路菜鳥產品進階之路,人人都是產品經理專欄作家。關注社交賽道和社群發展,擅長分析行業趨勢。

本文由原創釋出於人人都是產品經理,未經許可,禁止轉載

題圖來自Unsplash,基於CC0協議

頂部