起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品經理需要了解的埋點知識
為了更加有針對性、科學、客觀的對產品優化迭代，產品經理會進行產品埋點，期望通過分析上報的數據來獲得某種趨勢、特征的信號或者說信息，最后，這些信息被用在產品優化決策上。本篇文章中，筆者對產品經理需要了解的埋點知識進行了梳理，攻大家參考和學習。
產品經理工作的三個常態就是寫文檔、溝通、看數據。畢竟辛辛苦苦寫完需求文檔還冒著被砍需求的風險，好不容易說服了研發開發上線后，總是要關注自己在研發面前吹上天的功能在上線后數據方面是不是有變化。
另外產品經理的本質工作是發現問題、分析問題和解決問題，寫文檔也好，溝通跟進項目也罷，最終的目的都是為了解決問題，那怎么證明問題被解決了？
除了后臺反饋某個問題的聲音沒了以外，最直觀的就是負面數據降低了，正向數據升上去了。
產品經理的價值除了實現用戶價值，解決用戶的各種問題痛點以外，還需要實現商業價值，畢竟老板給定的OKR既不會讓研發背也不會讓測試背，對結果負責的只能是產品了。
那產品怎么證明自己勤勤懇懇夜以繼日的工作是有收獲的呢？
數據是讓老板滿意最有效的方式，畢竟日活能從10w做到100w對企業來說是完全不一樣的概念，直接的商業價值比如售賣的收入轉化從0.4%做到4%就有可能讓企業真正的存活下來。那數據從哪來呢？今天就好好說道說道埋點的全流程。
前面說了產品經理想看數據那就需要多方配合，既然自己需要數據，除了用戶的行為會反映在數據上以外，想要直觀看到數據中間還是隔了不止一座山不止一片海（最近看了張嘉佳的《云邊的小賣部》各種華麗辭藻堆砌雞湯文不禁被帶了節奏），畢竟自己也沒法看到每個用戶的使用情況。那又該如何是好呢？「為何處境如此的像唐僧」
這里就需要我們萬能的研發了，不僅需要他們通過飛舞地敲動鍵盤上的字母轉瞬間變成代碼，進而將草圖上不堪入目的功能概念變成觸手可及的實用功能，也需要他們繼續飛指間將監聽用戶行為的代碼也一同寫進去。
研發能監聽用戶的行為但畢竟這些東西都還是在代碼里，可視化的效果確實有點難，這里就需要數據分析的同學進場了，產品經理除了跟研發提數據需求，也需要跟數據分析的同學提需求，把監聽到的數據變得可視化，易于直觀的看到自己想要的結果。
上面說了這么多，那我們就正式的來說每一步吧~
「埋點原理及方式」
首先是關于埋點的概念，畢竟做啥事能明白其中的原理還是很重要的。
埋點是指對目標事件進行捕獲、處理和上報的相關技術及實施過程，其主要目的是實現用戶對產品行為的監控與數據收集。
具體來說就是在定義的事件代碼中植入一段監控代碼，用戶一旦觸發該事件就會上報埋點代碼中定義的需要上報的字段信息；通俗的說就是實現了給每個用戶在使用自家產品時分配了一個產品經理，用來記錄用戶都打開了哪些頁面，點擊了哪些按鈕，停留了多長時間。
埋點可根據開發方式與埋點位置分為兩類，先是開發方式最常見的一種是代碼埋點，即手工埋點，顧名思義是研發將用于監聽用戶行為的代碼提前手動埋到觸發該事件的代碼中。
這種傳統且常見的方式優點和缺點都極其明顯，優點方面即可以自定義進行數據采集，想采多少就采多少，想采什么數據就采什么數據，哪怕是腦洞再大的產品經理只要是提的數據需求合理，原則上都可以滿足并最終統計到想要的數據。
但同樣的缺點就顯而易見了，這種手動人為的方式就會受到整個APP發版流程的限制，即不管是iOS端還是Android端每次升級都是要發版的，而每次發版都是封裝好當前這版本的代碼，如有變動只能更換提交到各大應用商店的安裝包，如果頻率過多負責渠道的同學定會提著40米的大砍刀來找發版產品經理了。
代碼埋點一旦存在問題進而會引發什么問題呢？
試想新功能上線后老板某一天突然找到你要新版本的數據，這時你找研發要埋點信息但對方告知你沒有埋上或者埋點信息異常，聽到這句話產品心里肯定涼半截，沒法交差了。
如非極其重要的數據只能眼瞅著等待下一個發版周期才能統計新功能的數據了。此外，流程上也會占用一定的人力，這點在后面的埋點流程中會細講。
當一種操作方式有它存在的局限性，隨之就會有其他更便捷高效的方式出現，畢竟事物是發展的，沒錯，近幾年一些第三方數據平臺或諸如bat這種互聯網公司已經想出一種可視化埋點方式
——通常是指通過設備連接用戶行為分析工具的數據接入管理界面，對可交互且交互后有效果的頁面元素（如：圖片、按鈕、鏈接等），直接在界面上進行操作實現數據埋點，下發采集代碼生效回數的埋點方式。
這種埋點方式極大的提高了人力成本，想想傳統的手工埋點方式需要產品給研發提埋點需求，研發需要在代碼中寫入監聽的代碼，產品上線前還需要驗證?？梢暬顸c類似于前端網頁的形式，實時交互降低人力成本和出錯成本。
既然可視化埋點這么好為啥并沒有完全普及或者成為各大互聯網公司的主流埋點方式呢？問題就在于既要輕量級就沒法完全自定義，對于一些基本的記錄某個頁面的展現和按鈕點擊可能沒問題，但是面對一些復雜的數據需求時這種方式便沒轍了。
比如需要區分來源的數據需求，帶各種參數的需求，需要和后端交互的數據需求就不太適合可視化埋點方式。
所以總結來看可視化埋點雖然很美好但僅限于一些簡單的純客戶端埋點統計，在復雜的數據采集需求面前行不通且準確性較低，這也是影響它普及的最大因素。
除了可視化埋點還有一種無埋點方式，也叫全埋點，即事先盡可能收集所有控件的操作數據，然后再通過界面配置哪些數據需要在系統里面進行分析。
相比于可視化埋點這種半自動化模式，全埋點不僅繼承了可視化埋點的優點，同時解決了手工埋點和可視化埋點共同的一個缺點即數據回溯。
比如產品想要看某個按鈕的數據，可視化埋點只能做到從此刻以后的數據，在這之前的數據是沒有的。
但全埋點只要在一開始封裝的SDK就部署在代碼中即可以保留整個時間線的數據，做到真正的所見即所得，通過點擊某一控件區域便能看到該區域的歷史所有數據。
但全埋點也繼承了可視化埋點的所有缺點，所以這種的埋點方式同樣也無法做到全面普及。
上面說的手工埋點、可視化埋點、全埋點是指按照開發方式劃分的，按照埋點位置還可以分為客戶端埋點和服務端埋點。即上面三種埋點方式都是在客戶端實現的，而有一部分數據是可以直接通過服務端去埋點并上報所有數據。
比如統計某款社區產品每天的用戶發帖記錄，除了可以直接在客戶端埋點統計，也可以直接提交至服務端的數據量級?？蛻舳寺顸c和服務端埋點優缺點又是什么呢？
對于客戶端埋點的優點和缺點基本上就是上面介紹的那些，這里相比于服務端埋點存在的另一個缺點是數據上報有延遲且會存在漏報的情況。
而服務端埋點的優勢便是數據上報無延遲，可以實時獲取到數據，且整個操作較客戶端更簡單便捷，缺點方面自然是沒法統計純客戶端的數據，比如不需要跟服務端發生交互的用戶行為。
此外數據的收集會依賴網絡環境，這也是為什么同樣的統計目標一般服務端和客戶端統計的數據有些許偏差。
這里正是因為網絡質量的問題影響了服務端的統計。比如用戶提交某個數據，在客戶端層面用戶已經完成了這個行為，但網絡質量不佳服務端可能就沒有采集到這個數據。
以上關于埋點的原理介紹和分類就已經說完了，下面開始埋點相關角色分工及埋點需求的流程，這里主要講的是當前主流模式的客戶端手動埋點流程。
埋點需求流程中包含的角色如上圖，包括產品經理、研發、測試、商務智能和數據平臺。
- 其中PM作為埋點需求的發起方，跟產品功能需求一樣全流程跟進；
- RD的主要工作是開發埋點功能，即在代碼中添加監聽用戶行為的代碼。但在不同的公司流程中有些RD還承擔定義埋點名稱和維護埋點資料的工作；
- QA一般承擔著測試埋點功能的工作，即測試某個點是否埋點正確。但有些公司QA并不承接這個工作，那這個驗證的工作自然就落在了PM身上。
- 當前面流程走完，埋點跟隨產品功能一起上線后PM就會跟BI同學提出數據需求，由BI同學將數據可視化。
- 至于平臺這個角色需要看公司的在數據這塊的重視程度，雖然埋點流程需要以上角色但并不意味著每家公司的埋點流程都是這樣，具體來說分為規范性流程與非規范性流程。
「埋點流程」
首先是非規范性流程，比如一些創業公司和小公司因為公司處于發展初期或業務對數據的依賴性不是太強的時候一般整體的埋點流程就會隨意一些。具體流程參見下圖：
如上面這張圖當公司無埋點工具或數據平臺時，埋點流程則相對人工化。
如果公司無BI這個崗位，一般由PM在需求文檔中提出埋點需求，在技術評審時提出自己的埋點需求，由RD在開發中自定義埋點名稱和參數（有些公司是由pm定義并維護埋點資料），并將這些信息埋點代碼中，并在公司某一平臺維護埋點資料，以便后續使用。
接著是QA測試環節，一般埋點的邏輯性較為簡單，所以有些公司QA并不介入埋點測試，上線前直接由PM進行埋點驗收。
這種人工式的埋點流程存在著較大的數據風險，一是埋點名稱不規范不統一，對于一些參數的定義也較為隨意，這樣就容易造成后續的埋點名稱冗余且混亂，不利于后續的統一管理；二是流程中諸多環節均為口頭溝通PM驗收較為繁瑣，某個版本漏埋點或埋點不正確的風險大大提高，對于數據的及時提供帶來較大隱患。
一般隨著公司的擴大和流程的規范，數據平臺的建立將大大的提升埋點流程的規范性、時效性。具體參見下圖：
相比于無數據平臺的埋點流程，一旦有定制化的數據平臺，埋點流程將變得完全不一樣。
此時，仍是PM提出埋點需求但是整個流程將收歸至線上，即PM將高保真的頁面記錄在數據平臺，并在數據平臺自動生成埋點名稱及任務推送給對應的RD，RD將根據由平臺定義好的埋點名稱和參數寫入對應的代碼中。
此外數據平臺還支持測試埋點，即PM可通過數據平臺在發版前安裝測試包測試埋點信息是否存在和正確性，極大的降低了風險性。
后續的數據可視化也直接在數據平臺查看，甚至能查看實時的數據大盤，諸如某個時間點的日活，訂單量等。
擁有定制化的數據平臺在埋點名稱的管理和維護方面將更加靈活且自動化，特別是對于擁有多條業務線的公司來說更是必不可少。
這里就不得不多提一些，對于多業務多終端的公司來說，數據的整理與維護工作至關重要，特別是對于現在的互聯網發展形態來說，數據的精細化可視化是指導業務規劃和業務決策的重要參考。
那這樣在埋點流程中埋點名稱的命名規則就需要考慮業務、終端、頁面的唯一性和可辨識度。
此外對于一些參數的定義也不再隨意，應包含全局通用參數即所有業務所有終端所有埋點都需要統一攜帶的參數。
比如一家教育公司中年級、學科這種應該就屬于全局通用參數，這樣在統計多業務多終端時才能保證參數的統一性；業務公共參數是指某一業務下多終端所有埋點攜帶的參數需要一致；業務自定義參數即部分參數可僅屬于某一業務下某一模塊獨有的信息，可使用自定義的方式命名參數，無需考慮其他終端其他業務。
當功能上線后PM需要某些數據時可根據業務需要向bi或數據分析師提出數據需求，具體的數據呈現方式也可根據數據的重要性及查看頻率決定是建立數據報表長期監控還是一次性的將數據導出以Excel等形式展示。
在提出數據需求方面也應以郵件的形式明確需求背景、所需數據時間范圍、數據統計邏輯和預期給到時間等。
「答疑」
以上便是埋點的全流程，每個公司的實際情況可能會有一定出入。但PM作為數據需求的發起方應充分了解埋點的流程，盡量降低各環節因不規范性帶來的風險性，更好的讓數據服務于工作。
以下還有一些關于數據方面的常見問題：
Q：數據的全流程有哪些環節？
A：上面的流程中更多是埋點的業務流程，真正的數據流程包括數據采集、數據上報、數據存儲、數據加工、數據輸出等幾部分。
Q：一般可以采集到哪些數據？
A：按照采集位置可分為客戶端「交互行為」數據和服務端「接口請求」數據?？蛻舳藬祿撁娴恼宫F、控件點擊、停留時長等，服務端數據包括請求狀態、請求結果等。
Q：哪些原因會導致統計的數據不準確？
A：首先是數據源異常，其中包含功能變動后未提出埋點需求、埋點需求不明確不完整、溝通過程中需求方和執行方理解有偏差等；同時在代碼層面可能會出現埋點位置錯誤、參數缺失，或者因為代碼調整導致原有埋點代碼丟失錯位等；
其次是數據上報異常，包括上報數據格式不規范，沒有按照規定格式上報或者各業務的埋點數據格式不統一；因網絡質量不佳和服務器壓力過大會導致數據上報延遲；數據上報地址的錯誤也會導致無法準確統計數據；
最后數據輸出層面也會影響數據的準確性，比如數據需求未將統計邏輯考慮周全，需求方與統計方溝通理解的偏差性，數據產出延遲等。
Q：數據有問題，可以找哪些同學解決？
A：首先是與bi或數據分析同學確認數據上報和產出是否存在延遲問題，其次再確認統計方式與自己的需要的數據統計邏輯是否一致，如若不一致則由數據產出方修改SQL語句即可；當統計方式沒問題時再去和rd同學確認埋點信息、參數信息在代碼中是否埋上且位置準確，上報地址否準確等。
Q：在哪些環節可以避免數據問題？
A：產品、運營、研發加強并培養數據意識，更深入了解并提升數據相關能力。產品、研發、數據分析等同學在埋點流程中保持較高的嚴謹性和專注度，避免在執行層面犯低級錯誤。全流程中各環節各方負責人均需加強自測和驗收，在需求上線前及時發現問題。借助工具的能力，將諸多流程從線下人力遷移至線上流程，減少因人力維護和輸入輸出導致的一些錯誤。
作者：我呀way ；個人公眾號：鄭重心流，歡迎來撩~
本文由 @我呀way 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
建議表述的更清楚、更規范一些
學習了 ??