起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導(dǎo)直播
12場專業(yè)技能直播
會員專屬社群
榮耀標(biāo)識4個實操要點，幫助產(chǎn)品新人掌握數(shù)據(jù)埋點
編輯導(dǎo)讀：數(shù)據(jù)埋點，對于產(chǎn)品迭代而言，有很重要的指向意義。但是實際應(yīng)用中，大多數(shù)產(chǎn)品新人對數(shù)據(jù)埋點都沒有具體實操，只有基礎(chǔ)的了解。本文作者依據(jù)自身工作實踐，從埋點思路、埋點設(shè)計、埋點文檔格式和迭代等四個方面對數(shù)據(jù)埋點的操作流程進(jìn)行了拆解分析，供大家一同參考學(xué)習(xí)。
文檔適用人群：數(shù)據(jù)埋點小白
文檔提及工具：神策、腦圖
文檔背景：筆者剛接觸數(shù)據(jù)埋點和分析2個月，通過大量實操總結(jié)出的實操手冊，非常適用于現(xiàn)階段的自己。
文檔介紹：沒有概念講解，沒有術(shù)語堆疊，沒有技術(shù)分析，都是非常落地的方法論述。希望對小白有幫助。
一、埋點梳理思路
1. 從0到1，基于鏈路的梳理
在沒有任何埋點的情況下，合適的方式是根據(jù)產(chǎn)品的鏈路進(jìn)行埋點的梳理。
以倒序鏈路形式記錄用戶的每一條路徑、頁面，與點擊。同級頁面操作或多來源頁面一漏斗形式呈現(xiàn)。
在梳理鏈路時一定做到盡善盡美，每個頁面的瀏覽和每一次點擊都要記錄在案。至于埋不埋是下一步考慮的事情。
梳理VIP充值鏈路：
2. 版本迭代，基于動作的梳理
在已有埋點的情況下，日常迭代中，我們會修改產(chǎn)品的一些功能點，此時我們的埋點就需要進(jìn)行相應(yīng)的補充和修改，這個時候可以采取另一種辦法梳理埋點。
首先是從2個緯度去梳理數(shù)據(jù)需求。一是功能數(shù)據(jù)，二是核心數(shù)據(jù)。
（1）功能數(shù)據(jù)
指的是基于版本動作而產(chǎn)生的數(shù)據(jù)需求。列舉版本所做的新功能和修改，從動作出發(fā)去思考帶來的直接數(shù)據(jù)效果，或者用什么數(shù)據(jù)去驗證動作效果。
例如新版本上了一個在線用戶列表，其他用戶可查看用戶列表后前往個人主頁發(fā)起聊天。在列表中增加了新人權(quán)重，以提高新人收信率。
此時整理出的數(shù)據(jù)需求包含：
- 通過該列表進(jìn)行發(fā)送私信的轉(zhuǎn)化率
- 新用戶首日被瀏覽率
- 新用戶首日收招呼率
從數(shù)據(jù)需求出發(fā)梳理短鏈路和埋點，在埋點文檔中查漏補缺?？赡苁茄a充事件，也可能補充埋點就足夠了。
（2）核心數(shù)據(jù)
每個版本我們都會做不同的動作，或大或小。動作有對應(yīng)的數(shù)據(jù)去驗證其有效性。但是產(chǎn)品在一個階段內(nèi)，會有一些核心數(shù)據(jù)需要去持續(xù)觀測，要和功能數(shù)據(jù)去進(jìn)行一個權(quán)衡對比。如果功能數(shù)據(jù)上升了，但是核心數(shù)據(jù)下降了，也是不可取的片面驗證。
核心數(shù)據(jù)便是產(chǎn)品在一個階段內(nèi)需要去持續(xù)觀測的最重要的一些數(shù)據(jù)。例如對于社交產(chǎn)品來說，我們一般持續(xù)觀測其留存率、連接率和客單價等關(guān)鍵數(shù)據(jù)。
（3）其他小tips
如果有使用數(shù)據(jù)分析系統(tǒng)，要在梳理數(shù)據(jù)需求的時候，思考自己怎么通過系統(tǒng)去獲取到數(shù)據(jù)，可以幫助你設(shè)計更實用的埋點。例如，我是使用神策的，我在填數(shù)據(jù)需求的時候，會直接寫上，是用漏斗分析，還是事件分析，還是占比分析等。
如果對應(yīng)的動作有舊數(shù)據(jù)，應(yīng)直接記錄舊數(shù)據(jù)，方便之后做對比。
建議以腦圖形式輸出，格式參考：
版本升級和埋點發(fā)布后，前往數(shù)據(jù)分析系統(tǒng)進(jìn)行數(shù)據(jù)看版和概覽的建設(shè)。可以用分類進(jìn)行概覽分組的依據(jù)，也可以用版本為劃分，方便版本數(shù)據(jù)統(tǒng)計與復(fù)盤。
二、埋點設(shè)計準(zhǔn)則
（1）事無巨細(xì)，每一步用戶行為全都需要獲取數(shù)據(jù)。
舉例：在一個基本資料填寫頁面，點擊選項出現(xiàn)填寫彈窗，在彈窗上有提交、取消的按鍵，點擊彈窗外區(qū)域也會關(guān)閉彈窗。點擊打開彈窗的量、打開彈窗后的各個操作量，都需要獲取數(shù)據(jù)。
（2）同級頁面操作和同頁面多來源為一個事件，不同的操作內(nèi)容和頁面來源作為事件的屬性進(jìn)行采集。
舉例：承接上一個基本資料頁的案例。基本資料頁5個選項，獲取打開彈窗/提交/取消只需要1個事件與2個屬性。
中文事件名稱：填寫基本資料項
中文屬性名稱一：填寫類型（昵稱、性別、生日、身高、常住地）
中文屬性名稱二：是否成功（真、假）
（3）用戶的點擊，若與下一個頁面的瀏覽是直接觸達(dá)可只埋一個事件。
舉例：點擊去填寫資料，就直接開始瀏覽填寫資料頁面。前者完全等于后者（數(shù)據(jù)量大時可忽略不計bug），只需要埋一個事件即可。
（4）前端的行為與后端的結(jié)果應(yīng)盡量分開。前端的操作結(jié)果作為屬性去記錄，可能會有接口反饋不及時的風(fēng)險。
舉例：提交VIP充值訂單，前端記錄一個點擊事件（即“點擊提交”），后端記錄一個結(jié)果事件（即VIP訂單提交，屬性為是否成功）。
（5）平臺型和互動型產(chǎn)品需要注意被動數(shù)據(jù)的埋點。目前發(fā)現(xiàn)的規(guī)律是，涉及到雙方的動作節(jié)點需要去注意被動數(shù)據(jù)。
為什么要看被動數(shù)據(jù)？從整體上來看，100個人發(fā)出招呼，就有100個人收到招呼。但是對于個體來說，差異性需要被注意。一個頭部用戶占據(jù)了90個招呼，其余人收到1個或0個招呼，是我們不希望看到的。再換個說法，我在平臺跟100個人打了招呼，但只收到10個招呼。主動和被動的數(shù)據(jù)，感覺明顯是不一樣的。
因此被動數(shù)據(jù)的采集有利于我們?nèi)テ胶庥脩趔w驗，在用戶分層時也會大有作用。
（5）英文名稱字母大小寫需要區(qū)分，名稱不可一致這種我就不說了。
（6）尚未找到合適的埋點命名規(guī)范方式。硬性條件是“動作+對象”。期待建議與補充！
（6）再簡單提一下用戶屬性表和預(yù)置屬性。
- 用戶屬性表是性別、城市、年齡、身高等屬性值，可以在數(shù)據(jù)分析時快速進(jìn)行人群的精準(zhǔn)定位。
- 預(yù)置屬性是一個快捷的默認(rèn)操作，其中包含的內(nèi)容會在埋點觸發(fā)時被自動采集。例如操作系統(tǒng)、應(yīng)用版本等數(shù)據(jù)。
三、埋點文檔格式
筆者日常使用的文檔格式，可供參考，包含以下元素：
- 分類：這個字段存在的意義是，方便埋點的快速定位與新人快速熟悉?；臼腔诠δ芑蛘邔ο笕澐值模ㄎ覍τ趯ο筮@個詞的理解還不是很深刻），分類可以是個名詞也可以是個動詞。
- 埋點形式：基本是前端或后端。
- 事件英文變量：事件的唯一性標(biāo)識。建議首詞大小寫。
- 事件顯示名：就是事件的中文名，方便大家去使用埋點。建議是動詞+名詞，例如瀏覽xx，點擊xx。
- 屬性英文變量：常見的屬性包括瀏覽時長（View_Time）、是否成功（isSuccess）、操作類型（Op_Type）、頁面來源（Page_Access）、失敗原因（Fail_Reason）等。屬性的英文名可以重復(fù)，因為屬性可以被共用。共用的前提是大小寫完全一致。如果不想共用，可以在屬性英文名中帶上事件名稱。
- 事件屬性顯示名：即事件屬性的中文名稱，一定程度上允許重復(fù)。例如都叫做頁面來源、彈窗來源等。
- 屬性值類型：常用的包含BOOL值、字符串、數(shù)值等。
- 性值示例或說明：BOOL值和字符串類型的屬性值需要被列舉。例如頁面來源是A\B\C，操作類型是點開主頁\點擊私聊等。BOOL值需要去定義什么為真，什么為假。例如點擊提交，是真；點擊取消，或者其他任何形式的關(guān)閉彈窗都為假。
- 觸發(fā)時機(jī)：準(zhǔn)確描述埋點的觸發(fā)時機(jī)。例如進(jìn)入頁面后觸發(fā)，打開彈窗時觸發(fā)或者彈窗關(guān)閉時觸發(fā)等。
- 備注：留下你想說的話，或者避免歧義的解釋。
- 創(chuàng)建時間：記錄埋點的創(chuàng)建時間，我的習(xí)慣是寫下“年+月+版本號”。
四、迭代埋點文檔
1. 用時間維度來沉淀文檔的弊端
原先的埋點文檔采取的是以創(chuàng)建時間為維度正序疊加的迭代方法，新的埋點會疊加在文件的最下方，若修改舊埋點，會新建一條數(shù)據(jù)，標(biāo)注一下是舊埋點，讓開發(fā)進(jìn)行相應(yīng)修改。
此種方式有以下不足之處：
- 文檔的更新重新增和修改，刪除的內(nèi)容不方便體現(xiàn)。
- 功能已下線的埋點未被刪除，還遺留在文檔中，日積月累下文檔非常累贅，大量不再使用的文檔干擾著使用者的視線。
- 被修改的舊埋點也留在了上方的文檔之中，對最新埋點的查看帶來難度。
- 文檔的檢索只能依靠事件名稱的搜索，無法根據(jù)類別快速定位，新人熟悉文檔的時候也沒有邏輯主線
2. 埋點文檔迭代需求
埋點文檔的迭代要考慮到當(dāng)下與開發(fā)的溝通，和以后文檔的繼承。
- 當(dāng)下溝通的需求是：需要知曉新增的、修改的、刪除的埋點分別是什么
- 文檔繼承的需求是：一個新人可通過閱讀埋點文檔快速知曉整體埋點框架，在后續(xù)進(jìn)行埋點補充和梳理的時候可快速定位到相應(yīng)模塊。
針對這兩個需求，最終拋棄了原先的文檔沉淀方式，而是采用了新的方法：
- 每條埋點都?xì)w屬于一個分類\模塊。根據(jù)埋點設(shè)計者對業(yè)務(wù)的理解來靈活劃分，該分類僅用于文檔分類，可幫助埋點的快速定位，也能給予新人熟悉文檔的邏輯線。
- 用眼色來區(qū)分新增的、修改的、刪除的埋點。例如新增和修改都用的是暖色系，分別是紅色和橙色。刪除的事件或者屬性使用冷色系的藍(lán)色。在每行的開頭可進(jìn)行實色填充，來加重區(qū)分。
下一版本的埋點輸出后，將上一版本的埋點標(biāo)黑。
比較謹(jǐn)慎的做法是：單獨建立一個文檔來記錄被刪除的埋點。
最后
目前我的埋點經(jīng)驗分享就到這里啦！由于數(shù)據(jù)分析這個事情和工具很掛鉤，因此本文就不多加描述了～ 每個文字都是自己敲出來的，謝謝觀看到這里，有不足之處歡迎留言探討。
本文由 @不太然 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于CC0協(xié)議。
- 目前還沒評論，等你發(fā)揮！
