埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

11 評論 1萬 瀏覽 126 收藏 24 分鐘

本文作者帶你避開埋點的深坑,梳理結構化的埋點方案。

在接觸過上百家頭部App客戶中,診斷和參與了數百次的App數據體系搭建工作。幾乎80%的App都沒有科學的埋點規劃,只采集顯性數據,而更深層的與事件、參數相關的隱性數據,都沒有采集到。埋點規劃并不難!但為什么大部分企業都做的不太好?

埋點規劃需要整合產品、運營、技術和業務等跨部門的需求,運營同學不太懂技術、技術同學不太懂業務、產品同學不太懂埋點,這問題該如何解?

在友盟+《戰疫求生,開發者的危與機》直播公開課上,友盟+業務專家張躍梳理出一套完整的埋點干貨筆記。帶你避開埋點的深坑,梳理結構化的埋點方案。

在埋點前,先帶你避開埋點的深坑

第一坑:遺漏

指的是埋點采集不全面,有可能重要的數據并沒有采集到,會對數據分析造成比較直接的影響,出現這個問題的原因是前期數據分析需求不清晰。

第二坑:雜亂

指的是數據采集比較零散,可以理解為前期并沒有進行事件結構化的設計,通常是想到一個需求,就把這個需求提供給技術進行埋點。

這種稱之為“扁平化”的埋點方式,例如:某一個位置或者某一個功能的點擊行為,就當做一個事件進行采集,看上去采集和查看很容易,但隨著時間跟需求的增加,當采集了大量零散的事件之后,需要在統計工具中通過分組分析時,就會比較麻煩。

第三坑:低效

不同于雜亂,雜亂是任何行為數據都會直接當事件去進行采集,沒有利用參數去進行結構化的設計。低效指的是在事件設計的時候,會去做結構化處理。但事件設計的參數邏輯會有問題,通常都是以大的頁面這種框架的思維去進行設計。

舉個例子:部分客戶在設計時,會按照頁面的思路去進行事件采集,頁面上有推薦位,還有很多功能按鈕的點擊,那么就會把這個頁面所有的點擊行為都歸到一個事件,并且點擊具體的按鈕和內容都當做參數傳回來。

但這里埋著兩個雷區:

  1. 在分析數據時,例如想了解整個用戶瀏覽內容的情況,或者是想了解某個功能(搜索引擎)整體使用情況,按照如上設計,內容和功能的采集都分布在每一個事件中了,這樣后面再歸類、分析就非常不方便。
  2. 當產品結構產生變化時,原有事件調整概率會比較大,因為之前都是按頁面結構去設計,頁面的調整直接影響事件采集。

第四坑:無用

指的是數據雖然采集了,但分析時根本用不上,這個問題主要有2個原因導致:一是前期需求不太清晰,另一個是之前的采集需求都是由不同人提出的。由于中間人員變動,很多采集需求就不清楚了,并且也不敢下掉,因為并不清楚這個事件是否還有人使用。

第五坑:復用

指的是事件重復采集,或者是需求重復,這個同樣是與多個人提需求有關,并沒有一個人去做整合管理,或者是說,沒有一個工具去幫忙我們做管理。

如果想要避免這些坑,就需要堅守五個原則:

  1. 需求清晰。
  2. 合理設計。
  3. 實施規范。
  4. 結果可驗。
  5. 規范管理。

埋點方法論——五步一全(ODEIIC),需要多角色參與統籌決策

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

第一、需求梳理

在梳理埋點設計的時候,通常會以產品、運營和市場以及KPI三個視角去切入。通常,產品關注的核心業務點會聚焦在內容和功能上,運營和市場關注的業務點在拉新、留存、促活和轉化上,KPI視角會聚焦在轉化與收入上,但也需要根據客戶的實際情況而定。

同時,會把不同視角的業務需求再轉化成需要關注的核心數據,如產品運營在內容上所需要關注用戶瀏覽、內容的轉發或者是偏好,針對功能使用會關注注冊、登錄、搜索等這些功能的使用情況。

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

業務需求拆解成核心數據后,針對每一個核心數據進行維度的細分,如內容方面:會按照標題、頻道或者是標簽,進行拆分分析。那么我們針對功能方面,會按照功能使用情況以及步驟的轉化去進行分析。通過要分析的關鍵點,就可以把細分維度拆出來,最后還會再加上一些通用的維度,例如可以對單個用戶或者某一個地區的用戶進行深度分析。

以產品視角的需求樣例,產品通常情況下會聚焦內容與功能上的使用,但在需求收集時都是分散和抽象的,例如:業務需要分析內容偏好和推薦效果以及內容受歡迎的程度。

那在這個環節就需要先做需求拆解,也就是說要去找到能分析這個需求的核心數據與能夠幫助判斷業務變化的一些指標,細分維度在這里的作用更多的是做需求詳細的拆解,可以理解為是去做核心數據的多維度明細展示,那么目的就是從更細的維度去滿足業務分析需求;

總結:先要找到能滿足這個需求的核心數據,在找到核心數據分析時所需要涉及的細分維度,如圖:

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

第二、事件設計

可以通過這3個步驟去完成事件的結構化設計:

  • 第一個步驟是要了解產品結構,也就是先要了解分析的范圍是什么,例如需要知道對哪些頁面或者哪些功能有分析需求;
  • 第二步,就是要針對這些鎖定的范圍,去明確我們要分析用戶的行為有哪些;
  • 第三步,要把這些行為,落實到具體的分析維度上。

后面會通過指標體系、分析需求、分析方法這3個角度,在去結合這三個步驟,進行事件結構化設計的詳細說明。

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

在介紹按照指標體系去進行結構化事件設計前,我們先看下指標體系的樣例,通常會按照這幾個模塊去搭建指標體系,分為:概況、營銷、用戶價值、運營和核心功能。

  1. 概況可以理解日常關注的核心數據,比如:新增、啟動、日活、周活、月活以及會員數據、注冊數據以及使用黏性、使用時長、留存等,還包括技術、產品較為關注的穩定性數據。總的來說:就是將核心或常看的數據放在概況的大板塊中。
  2. 營銷。通常會把廣告數據,例如:廣告的曝光、點擊率以及廣告點擊排行,媒體排行、展示排行信息會放在第二個板塊。
  3. 用戶價值。通常會把新用戶的次留、成本以及用戶回本周期模型和生命周期模型放在用戶價值模塊。
  4. 運營。主要關注內容與轉化,通常會分析內容的熱度,任務的交互與會員的轉化,針對會員還會分析會員新增、會員累計、會員續費等維度。
  5. 核心功能。是產品崗位較為關注的,例如:導航位、導航按鈕,被用戶點擊的情況、使用的情況,對應核心功能,比如說搜索功能或者是注冊功能,整個功能的入口、被點擊的情況和轉化率等相關的這些數據會放到這個板塊。

從指標體系到事件設計

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

如何通過指標體系去進行結構化設計?指標體系可以理解為指標與報表的一個組合,整個指標體系對應到產品結構上,可以分為對產品頁面和產品功能的分析需求。

下面先從產品頁面的角度去進行事件設計說明:

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

  • 第一步,會先鎖定頁面的范圍,比如產品里有活動頁、內容頁、如果是視頻App的話會有播放頁,小說App會有閱讀或者是聽書頁面。
  • 第二步,范圍圈定后就需要找分析行為,用戶看到內容是否有點擊行為,進入頁面后的瀏覽行為,以及是否有分享、評論等行為。
  • 第三步,確定了要分析的行為后,就需要進行分析維度的細化,如要分析用戶瀏覽(瀏覽完成行為)內容都有哪些,還想分析用戶是哪個入口(來源)進入到頁面等等,這些都是針對用戶行為要分析的維度。

按照這三步梳理清楚后,事件設計中與產品頁面相關的事件和參數就能整理出來了,如頁面范圍對應的“內容頁”和分析行為對應的“點擊”行為,就能夠清楚我們要采集的事件為“內容點擊”,在根據這個事件需要分析的維度是頁面名稱、頁面分類以及頁面來源,這個事件所需要的參數也就找到了。

下圖中是以內容頁和活動頁梳理的結構化事件樣例。

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

以產品功能的角度去進行事件設計說明:

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

同樣,第一步先找到要分析哪些功能,比如:搜索、登錄、注冊、會員、付費、簽到等。第一步找到監測功能的范圍。

第二步在找行為,功能層面的行為比內容會稍微簡單一些,主要是點擊行為或者是完成狀態。

第三步是維度,例如:搜索功能,想分析搜索入口的點擊情況,搜索的關鍵詞是什么,針對登錄與充值的話,需要分析帳號登錄的類型、充值的方式等等。

頁面功能所產出的結構化事件樣例

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

以搜索引擎為例:搜索引擎監測的行為是點擊和完成,通常會用兩個事件進行監測,搜索引擎功能在很多頁面都會有入口,通常會建議在這里增加一個參數叫搜索位置,可以辨識用戶點擊哪些搜索位的按鈕,另外可增加參數叫用戶ID,去了解具體是哪些用戶進行的點擊。

重點說一下功能按鈕點擊事件。通常情況下,會將核心要分析的功能都抽離成單獨的事件進行統計。如登錄、注冊、付費或者是會員購買等,這些屬于核心要關注的功能,并且會為這些核心功能事件單獨設計要分析的參數。

但如掃一掃、加載更多以及一些Tab鍵,只需要監測用戶點擊即可,不需要監測功能背后的參數信息。通常會將這些點擊行為放在一個事件下,定義名稱叫功能按鈕點擊,會通過“按鈕名稱“與“所屬頁面”等參數去鎖定用戶點的具體按鈕是哪個。

小結,通過指標體系去進行事件設計,就能夠把大部分需要采集的頁面與功能都能覆蓋到,并且可以滿足后期看數據的需求。

從分析需求到事件設計

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

先引用小說行業的一個需求舉例,近期上架了新書,要分析新書對用戶的吸引力如何。那么第一步,就要把需求進行轉義,也就是需要知道哪些數據和維度,能證明用戶對新書的吸引力。

針對這個需求,分析思路是:今天新上架的小說,用戶看了多少章節和時間,明天會不會繼續來看,可以通過這幾個維度去判斷出新書吸引力。

那么在落實到事件設計的三個步驟中,第一步采集的頁面范圍是小說頁面,第二步采集的行為就是閱讀,這兩步對應出我們需要采集的事件就是小說閱讀,第三步需要分析的維度就是閱讀章節、閱讀時長、小說名稱以及上線日期,這些維度就可以轉化成參數在事件中設計進來。

另外,一般做內容事件時,通常還會增加來源參數,比如:來源頁面、來源版塊、來源位置,這些參數可以幫我們定位到用戶是從那些入口獲取到內容的,便于后期去分析各入口的導流效率。

從分析方法到事件設計

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

這部分指的是根據核心目標,在利用一套分析方法去解決問題時,如何找到解決問題環節中所需要采集的事件。

比如,目標鎖定是要提升用戶留存或者是提升付費轉化率,那么,首先要找到不同的人群,針對人群找差異(功能使用、內容偏好的差異),找到不同的人群在功能使用、以及轉化路徑的差異后,在去找問題,如某一些功能對于非留存用戶或者是非付費用戶體驗不好或推薦的內容用戶不感興趣,找到問題后,就需要進行優化,并進行驗證。

針對分析方法中的每個環節,其實都能對應到需要分析的事件,如找問題的環節會對入口的點擊、完成的情況,內容瀏覽的來源等等進行事件采集,在分人群環節,會對用戶的付費行為進行事件采集等等。

通過每個環節找到對應需要分析的行為后,就可以把相關信息以事件或者是參數的形式,補充到現有結構化埋點方案中了。

按照指標、需求、方法這3個角度去做了事件設計方法的介紹,總體可歸納為:

有了指標體系與分析需求,整個結構化埋點方案的框架就能設計出來了。分析方法更多的作用是做分析思路上的貫穿,可以幫我們發現埋點設計中缺少或者遺漏的環節,整體上我們就可以理解為,指標體系+分析需求+分析方法這三部分的結合,才能得到一個非常貼合業務的埋點方案。

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

小結:“事件采集“就是要知道誰在什么時候做了什么事情,設計思路可以分為三步。

首先,了解產品結構(產品結構的范圍,頁面結構、功能結構);其次,了解用戶行為(點擊行為、完成行為、曝光行為等);最后,行為可以細分哪些維度,按照三步結構化事件就可以設計完成了。

總結三個避坑的Tips

(1)需求

如果前期需求不是很明確時,可以先把這個指標體系梳理起來,比如:核心關注的指標,采集方案是可以滿足暫時看數的需求,后期可以根據對分析需求的升級再去補充。

(2)歸類

在事件設計時要合理的進行歸類,盡量用一個事件滿足多個分析需求。比如,了解用戶都是從哪些入口獲取內容的,和內容瀏覽的熱度排行,是可以通過一個事件來實現的,只需要通過內容名稱和來源頁面兩個參數,就能夠滿足這兩個需求了。

(3)范圍

在參數設計中兩個范圍需要注意,即來源和點擊按鈕,內容采集會涉及三個來源:來源頁面、來源板塊和來源位置,是為了去鎖定到底內容從哪里點過來,開發也會要求將入口信息梳理清楚,從而進行埋點的開發工作。點擊按鈕,將按鈕都歸屬到一個事件中,將參數設置為按鈕名稱,梳理出具體的按鈕采集的范圍給到開發,才能去進行后續的埋點。

埋點設計不是簡單的事件與參數的結合,而是需要貼合業務、貼合分析場景去進行設計。

結構化事件設計完成后,下一步就是要交付給技術進行開發,下圖為一個資訊行業的事件埋點模版,可以參照這個模板去進行梳理并提交給技術。

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

埋點實施:

市場上主流支持的四種埋點方式,分別是代碼埋點、服務端埋點、可視化埋點和全埋點。代碼埋點,支持事件與參數這種結構化的使用方式,弊端是想增加或修改事件,都需要重新發版,用戶更新后才能采集。服務端埋點,通常用于業務數據的采集,例如:付費成功、用戶注冊等,這個場景會選擇用服務埋點進行采集。

可視化埋點和全埋點,都是解決整個App前端操作的一些點擊行為,例如說某些按鈕、頁面,每一個點擊都能監測。但差異點在于可視化埋點只能看到圈定后的數據,那么全埋點則是在圈定時,歷史數據也能去追溯。

但這兩個埋點的弊端是散點采集,每一個點擊行為都是一個事件,在數據分析時,事件的量級會較大,不易于分析,而且它只能是取這種點擊行為的事件,并不能把參數帶過來,你可以理解為它就是一個純扁平化的一個事件采集。

針對需求的不同,數據采集方式應該是結合使用的,以友盟+為例,友盟+現在支持兩種埋點方式,代碼埋點和可視化埋點,開發者可以結合使用,去滿足事件方案的采集需求。

【干貨】埋點還是埋雷? 十年數據分析經驗,教你如何結構化埋點!

看板校驗:

埋點后可通過三種方式驗證:

  1. 打印日志,開啟debug去打印Log,去驗證觸發事件log是否有上報,這種方式需要技術來配合驗證。
  2. 集成測試,只需要在測試設備上去觸發事件,產品、運營的同學就可直接測試埋點情況。
  3. 也可以使用市場上智能驗證的工具,自動去識別整個埋點的情況,且日志是實時的,可產出事件的驗證報告。

智能驗證:

可以智能驗證這些事件的點是否采集了,是否有遺漏,最后會定期給出體檢報告,詳細的明細都會有。只需要注冊一個測試設備,這個測試設備填加完之后會實時把客戶這些埋點的數據進行驗證,到底是成功還是異常,以及測試的時間是什么都會有詳細的數據。

綜上所述

一個公司的埋點要可見、可控、可管,如果一家公司不清楚自己的埋點結構,便是在錯誤的數據上長期持續經營業務,越走越錯。合理的埋點方案,可以使埋點能夠智能調試和驗證,大幅降低埋點采集的成本,從而最終達成數據質量的根本性提升。

 

作者:友盟全域數據;公眾號:友盟全域數據(ID:umeng_data)

本文由 @友盟全域數據 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 不錯,看了這么多,這篇價值最高,雖然沒用過友盟
    另外問下,能不能著重說一下 前端埋點和后端埋點,搜索了半天,沒有一篇講清楚他們在DRD中的差別到底是什么,我的理解,當事件需要服務器數據時,用后端埋點。
    一個事件再多個端口都會發生時,用后端埋點,屬性增加一個平臺即可。

    回復
    1. 前端埋點:一般主要用于采集前端用戶行為,如在某個流程中點擊了那些按鈕等操作;也不是說當事件需要服務器數據時就一定要后端埋點,這種情況也可以把信息傳給客戶端,然后通過前端埋點進行上報;
      后端埋點:一般用于采集特別核心的行為,舉例如用戶購買、充值等行為,這個可以從服務端采集,準確性較高;
      上面說的都是事件采集的情況,還有一種是用戶屬性采集,也就是我們說的用戶表,里面涉及了很多用戶字段,也是需要前端和服務端采集在不同場景下進行寫入的;

      回復
  2. 同求,PPT能不能分享一下呢。郵箱:416137212@qq.com

    回復
  3. 感謝作者,終于把埋點理清楚了

    回復
  4. 可視化埋點和全埋點,都是解決整個App前端操作的一些點擊行為,例如說某些按鈕、頁面,每一個點擊都能監測。但差異點在于可視化埋點只能看到圈定后的數據,那么全埋點則是在圈定時,歷史數據也能去追溯。
    ———————–
    請問下作者或看懂了的朋友,“全埋點則是在圈定時,歷史數據也能去追溯。”怎么理解呢,全埋點也是后期圈定啊,我以前沒圈定過的歷史數據從哪里來的呢?不是很能理解這句話

    回復
    1. 全埋點會默認采集用戶點擊頁面的行為數據并保存一定周期,當你有分析需求并圈選點位時,就可以看到保存周期內的結果。

      回復
  5. 請問PPT能不能分享一下呢。郵箱:116558614@qq.com

    回復
  6. 《戰疫求生,開發者的危與機》這個在哪里能看到呢

    回復
    1. 來友盟+的官網就可以看到呢!

      回復
  7. 很不錯,感謝樓主

    回復
  8. 很不錯 學習

    回復