俗話說“巧婦難為無米之炊”，對數據分析師來說，好的數據源，是數據分析的根基。在整個數據分析流程中，數據采集，是整個數據流的起點，也是最重要的環節之一。采集到的數據質量與準確性直接決定數據廣度和質量，影響整個分析報告的所有環節。
在獲得高質量數據的過程中，數據埋點這一動作尤為必要，這是針對特定用戶行為或事件進行捕獲、處理和發送的相關技術及其實施過程。今天我們來說說如何做好數據埋點，為收集優質數據壘實基礎。
一、什么是數據埋點
所謂埋點是數據領域的專業術語，也是互聯網應用里的一個俗稱。它的學名應該叫做事件追蹤，對應的英文是Event Tracking。它主要是針對特定用戶行為或事件進行捕獲、處理和發送的相關技術及其實施過程。
數據埋點是數據產品經理、數據運營以及數據分析師，基于業務需求或產品需求對用戶行為的每一個事件對應的位置進行開發埋點，并通過SDK上報埋點的數據結果，記錄匯總數據后進行分析，推動產品優化和指導運營。
數據分析的前提是數據。例如對于電子商務平臺來說，數據分為以下幾類：
用戶基本屬性數據、交易數據、商品數據是直接通過用戶錄入或者行為觸發，在數據庫里面產生記錄。而流量數據或者說用戶行為數據，則需要識別具體的每個行為。通過埋點就可以取得這部分數據。
通常是業務方、PD、BI，通過實際需求設計埋點方案。開發人員在代碼（前端或后端）的相應位置點植入統計代碼，對用戶的行為進行記錄，這就是埋點。埋點后，通過打點將埋點數據發送出去，存儲到服務器上，在數據庫中產生記錄。
包括2個步驟：①日志收集：獲取每次用戶行為，發送服務器；②日志處理：將日志處理、提取需要的信息，存儲在數據庫中。
數據埋點主流部署的方式有：①私有化部署：即部署在自己公司的服務器上，如果期望提高數據安全性，或者定制化的埋點方案較多，則適合私有部署，并開發一套針對自己公司定制化的數據后臺查詢系統保證數據的安全性和精確性，缺點是成本較高；②接入第三方服務：比如國內或者國外的統計工具，優點是成本較低，部分基礎服務免費，缺點是：數據會存在不安全的風險；③通用的簡單分析，無法定制化埋點方案。
二、為什么要做數據埋點
埋點就是為了對產品進行持續追蹤，通過深度數據分析不斷優化產品。好比去醫院體檢，醫生測了你身體的各個健康指標，以此來判斷你的健康狀況。埋點的目的，其實就是隨時或者定期監測你的產品的“健康”狀況。
任何一個系統在設計初始階段只關心核心業務的功能，等到系統上線以后，數據分析師對用戶行為分析時會發現缺少很多數據，此時需要采用埋點的方法進行采集需要的數據。
業務人員主要通過自有或第三方的數據統計平臺了解產品的概覽性數據指標，包括新增用戶數、活躍用戶數等。這些指標能幫助企業宏觀的了解用戶訪問的整體情況和趨勢，從整體上把握產品的運營狀況，但很難基于這些指標直接得到切實的產品改進策略。
而埋點將產品數據分析的深度下鉆到流量分布和流動層面，通過對產品中的用戶交互行為的統計分析，對宏觀指標進行深入剖析，發現指標背后的問題，尋找人群的行為特點和關系，洞察用戶行為與提升業務價值之間的潛在關聯，了解組成特定數據現象的原因，并據此構建產品優化迭代和運營策略。
對于產品來說，用戶在你的產品里做了什么、停留了多久、有什么異樣，都是需要關注的。比如用戶點擊率怎么樣？用戶在核心使用路徑上是否順暢？有沒有得到用戶的認可？有沒有因為設計按鈕過多導致用戶行為無效？用戶希望有什么樣的功能更新等等問題都可以通過埋點的方法實現。
埋點做好才能用來進行數據驅動產品和精細化運營。而埋點質量的好壞也直接影響到了產品運營的質量。因此它貫穿了產品的整個生命周期，為產品優化指明了方向。所以說，好的數據埋點，就成功了一半。
三、數據埋點的幾種類型
埋點是在應用系統中嵌入額外的代碼，具體的方式有三種：代碼埋點（手動埋點）、可視化埋點、無埋點（全埋點）。如果從系統的前后端來講，埋點又分為前端埋點和后端埋點。無埋點是前端埋點，而代碼埋點既是前端埋點又是后端埋點。
1.代碼埋點
在你需要統計數據的關鍵部位植入N行代碼，追蹤用戶的關鍵行為，得到想要的數據。簡單的說，就是找節點，布代碼，收數據。又分為前端代碼埋點和后端代碼埋點。它是手動編碼產生的，自由度高，功能強大，企業可以自定義事件和屬性，精準控制監控對象，傳輸豐富的數據內容。
（1）優點：
①采集的數據比較具有針對性，更加適合精細化數據分析；
②同時也能提高數據的準確性。
（2）缺點：
①每一個控件的埋點都需要添加相應的代碼，不僅工作量大，而且限定了必須是技術開發人員才能完成；
②每一次產品迭代，都需要更新埋點方案。
（3）適用場景：
①有具體的業務分析需求，且按照各個事件埋點的方式不能滿足；
②需要對埋點事件進行傳參等自定義屬性設置。代碼埋點雖然較復雜，但功能最完善，覆蓋了埋點中的不同業務需求。
2.可視化埋點
可視化埋點是把核心代碼和配置、資源分開，通過部署在產品上的基礎代碼對產品的所有交互元素進行解析，并在可視化頁面對埋點區域和事件進行設定，從而在用戶有所操作時，對交互時間（操作行為）進行記錄。
（1）優點：
①業務人員可用，無需技術人員進行SDK嵌入，不懂代碼的產品運營人員也可通過后臺可視化界面配置和統計埋點并實時下發到客戶端生效；
②無需版本更新，由于不需要嵌入新SDK，不需要發布新版本，可謂即時生效；
③對所有版本生效：新增埋點在所有版本生效，不存在迭代問題。
（2）缺點：
①可覆蓋的功能有限，目前并不是所有控件操作都可以通過這種方案進行定制；
②不能自定義交互事件屬性，由于獲取的是交互事件元素的DOMpath，無法對具體事件設置參數；
③不支持可以不斷加載的內容瀑布流交互。
（3）適用場景：
①分析或統計需求簡單，不需要對埋點事件進行傳參等自定義屬性設置；
②頻繁上線或更新的H5類型的運營活動
3.無埋點
無埋點又被稱為全埋點，是通過后端配置或前端可視化圈等方式來完成關鍵事件的定義和捕獲。它要求必須在頁面上嵌入數據采集基礎SDK（基礎代碼），就可以采集頁面上所有的點擊行為，并且可以繪制出用戶點擊的熱力圖。這等于做了一個統一的埋點，因此又被稱為全埋點。
（1）優點：
①因為無埋點對頁面所有元素進行埋點，那么這個頁面每個元素被點擊的概率你也就知道，對點擊概率比較大的元素可以進行深入分析；
②可以在系統上線后使用，支持基于全量的數據回溯，因為無埋點在你部署SDK的時候數據就一直在收集，可幫助進行啟發式、探索式的數據分析；
③它技術門檻低，部署簡單。
（2）缺點：
①無埋點無法采集自定義屬性，只使用通用大部門，通用的場景；
②數據形式非業務導向，因為是對所有事件數據的自動收集，沒有按照業務需求進行事件或區域設置，業務或數據人員在使用時或許不能直接使用，需要二次計算或處理；
③兼容性不好，傳輸時效性較差等問題，因為是對所有的元素數據都收集，會給數據傳輸和服務器帶來較大的壓力。
（3）適用場景：
①分析或統計需求簡單，不需要對埋點事件進行傳參等自定義屬性設置的事件；
②針對快速、頻繁上線和迭代的H5類型的運營活動的評估
總體來說，無埋點和可視化埋點更側重結果的展現，對過程追溯少，更適合產品經理分析基礎的產品功能流暢度、用戶體驗、產品路徑設置等。代碼埋點和后端埋點，不僅能展現結果，也會記錄用戶行為過程，支持深度的行為分析和偏好洞察，還可將行為數據與業務數據打通，適合產品和運營人員深度使用。
無論采用哪種埋點方式，都應該根據業務場景和產品階段，梳理和構建數據分析體系。埋點規劃混亂、數據采集無序、數據分析斷層，最終將會讓企業陷入“有數據而無價值”的境地。
四、如何判斷需要埋點的數據
到底哪些數據需要埋點？根據運營目的的不同，埋的點也不盡相同。
舉個例子，對PC端的騰訊視頻，用戶瀏覽時長、用戶觀察類別、用戶活躍、用戶VIP轉化等指標都是很重要的業務指標。但對于一些工具型的產品而來，比如迅雷，那下載成功率、解析成功率等都是核心的關鍵指標。
從經驗上來看，以下3種類型的指標通常需要埋點：基礎指標、用戶行為數據指標和核心質量指標。
1.基礎指標
基礎指標是一些常用的參數指標，比如用戶行為相關的，有用戶數、新增用戶數、活躍用戶數等；用戶設備相關的，比如電腦系統、地區、語言、國家、產品版本等；用戶屬性相關的，性別、年齡等。這一部分一般很難通過埋點拿到，但是通過一般第三方工具可以看個大概。
2.用戶行為數據指標
用戶行為的行為數據，就是埋點的核心了。這一部分根據不同的產品，收集的數據也不同。再拿PC端的騰訊視頻舉例，每個用戶每天使用騰訊視頻的時長是多少？每次看的是哪些視頻？用戶最喜歡看哪個頻道的視頻？每個頻道的使用情況是怎么樣的？用戶一般是在一天中的哪個時間段打開騰訊視頻的……
想要看的數據非常多，而這些，都是要提前規劃好，有目的性得去決定要埋什么點、怎么埋。如果你的目的是為了研究一下用戶對彈幕的接受程度，那圍繞彈幕，設置一些指標數據，比如發布彈幕的次數和頻率？看視頻時是否開啟了彈幕？這樣的話，就能夠通過數據，看出用戶對彈幕的真實反映，對于提升產品功能和運營都有很大幫助。
3.核心質量指標
Crash等一些因為產品質量引起的問題，都是用戶所不能忍受的。而且用戶量越大，越容易出現產品質量問題。尤其是一些產品，他的產品屬性決定了，產品質量是吸引用戶購買的一個很重要的因素。比如迅雷、photoshop等軟件，核心質量的指標能幫助我們監控產品的“健康”情況。
這里說的質量指標，不單單指產品的異常退出率、Crash率，還包括和產品自身業務相關的指標。比如，對于視頻編輯產品，編輯成功率是很重要的指標；對于迅雷，下載成功率是核心指標；對于在線類產品，資源解析成功率是核心指標…...
五、如何做數據埋點
經常有人問我：我要獲取哪些數據來進行數據分析？
其實這個問題不應該問別人，應該問你自己，通過上文，我們已經知道了，如果你想繪制基礎的人群畫像你就需要獲取用戶機型、網絡類型、操作系統，IP地域等數據；如果你想分析每一個注冊轉化率，你就需要獲取每一個步驟的點擊次數，然后制作成漏斗，看那一步轉化率出現了問題……目的不一樣，獲取的數據也不一樣，使用的埋點技術也不一樣。
那么，我們該如何選擇埋點方式呢？
我們的目的是實現深度數據分析，不應該采用與其他企業通用的埋點方法，應該采用適合自己的埋點方法。也就是做到“因系統而異、避免千系統一面的情況。
在系統剛上線的初期階段，我們可以采用無埋點的方式。因為我們通過UV、PV、點擊率等基本指標及即可滿足數據分析需求。如果產品上線時間很長，我們需要進行深度數據分析則選擇代碼埋點。它可以幫我們收集需要的屬性。另外，如何埋點既可以在前端實現，也可以在后端實現，我們推薦在后端實現。因為后端數據可以保證數據的準確性。最后，如果您為了方便快捷并且免費，可以選擇第三方統計工具，但是一定要選擇適合自己業務的統計工具。
從業務過程中采集埋點，是數據驅動型公司的必要條件。一般公司的產品功能評審環節，不僅有 PRD (Product requirement document），還加入了對應的 DRD ( Data requirement document）。對于埋點而言，DRD 需要明確業務目標與埋點缺口之間的關系以及需求的優先級。埋點的需求大多來自于 DRD，整個過程會涉及多個角色，主要包括產品經理、業務數據負責人、開發工程師、測試工程師，如圖所示。
總之，如果您需要深度分析，選擇后端（手動）埋點和無埋點組合的方案；如果您只是想看宏觀數據，可以選擇無埋點。無論采用哪種埋點方法，一定要慎重，根據需要來設置，最好不要出現錯埋或者漏埋的情況。最后，數據分析師一定要和業務工程團隊（部署實施埋點的部門）配合好才能實現完美的數據采集方案，有時候溝通比選擇埋點方式更重。
六、案例：如何做一個社交類App的埋點
其實對一款產品進行數據分析的最佳過程如圖所示，梳理數據分析業務需求和埋點采集是數據分析的第一步，埋點需求梳理和埋點采集的好壞直接決定了后續的實施成本和效果呈現。
1.梳理產品邏輯和需求
下面就以某社交類 APP 為例來進行說明，其實就是一個話題交友興趣聊天的平臺。
（1）產品信息結構圖
通過產品信息圖就能了解到產品承載了哪些信息和功能，并且可以借此思考下，這些信息和功能的目的是什么，想要用戶干什么。
（2）產品功能結構圖
通過產品功能結構圖能夠將產品的功能模塊梳理出來，功能之間怎樣跳轉，功能的上游入口和下游出口是什么都要想清楚，并標記出來。
（3）核心業務流程圖
一個產品總會有那么幾條核心業務流程，比如注冊流程，新手完成任務流程等等，首先需要清楚梳理出產品的核心業務流程，密切觀察用戶在核心業務流程運轉的整個過程。
（4）梳理產品需求
進行需求梳理首先要明確要分析什么樣的場景，解決什么業務問題，要解決這個業務問題，要看什么樣的數據，要衡量什么樣的指標。不同的角色會關心不同的問題，一般會按照業務線進行需求梳理。當然，這些指標是和目前產品要解決的核心業務目標密切相關的。下面就來梳理一下各業務線的指標需求。
這個指標需求和梳理產品邏輯有什么關系？為什么第一步要梳理產品邏輯？你可能會發現，這些需求點和產品的信息架構和功能架構密切相關，舉個例子，拿常用的活躍用戶數這個指標來說，一般是以啟動App的用戶數來定義活躍的，實際上，每一款產品的核心功能不同，只有完成核心功能的用戶數才算活躍，通過以上產品功能架構的分解，才能知道應該優先衡量哪個功能的使用情況。
再有功能轉化率的衡量，功能轉化的過程有沒有想清楚，如果完整梳理出該功能使用的完整業務流程，那么要怎么衡量轉化也就有了眉目，也更能定義出問題所在。
總之，經過一番梳理，對產品的信息架構、功能點、核心業務流程有了一個清晰的了解。有經驗的產品經理可能會發現，這些產品邏輯其實已經在產品需求文檔PRD里面已經有了，只是沒想到還可以用于數據模型的設計和避免埋點的反復。有了上面的準備工作，就可以討論如何進一步設計數據埋點方案了。
2.進行事件設計和數據采集埋點方案設計
說起埋點，很多人都習慣用頁面或點擊來定義埋點，比如手機號碼填寫頁面、播放視頻頁面、成功發布話題頁面或者點擊分享按鈕的次數等等，平時常說的功能，即用戶在使用這些功能時產生的使用行為數據，從用戶使用行為分析的角度去分析自然順理成章。
這里舉個例子，上面提到的發布話題的業務流程，其實是由用戶一系列行為組成的：
這里給出了用戶行為和事件的對應關系，用用戶的真實操作行為去定義事件名稱就可以了。除了要埋點的行為功能以外，每一個功能都需要從不同屬性維度去衡量。比如想看不同話題分類被成功發布的次數這個指標，就可以將話題分類做為發布話題這個事件的屬性，這個話題分類的值可能有圖片、文字、音頻、視頻，這樣我們就能分別看到發布圖文的話題個數、發布音頻或視頻的話題個數了。
通過維度的層層細分，我們一定能定位到業務問題，就怕缺少某個關鍵維度的信息。最后，會形成一張事件設計埋點表。
接下來，可以就上面的事件設計埋點表和開發去溝通了，讓他們明白采集這些事件的意義和目標，每條事件的采集時機是什么，相應的維度信息能不能采到等等，目的是保證最后出來的指標和事件定好的指標統計口徑一致。至此，產品就可以放心的等待開發將點埋好，然后開啟數據驅動產品業務增長的優化之路了。
七、注意事項
1.數據埋點的前提是，團隊需要首先明確產品的目標以及當下的首要問題。產品可能產生的用戶行為數據紛繁復雜，清晰的目標能讓項目團隊避免迷失在數據的海洋中，從而耗費大量的時間和機會成本。
2.最開始進行需求梳理時，需要從整體進行考慮，要給給深層次和具體的需求。不要等到開發埋好指標結果出來時卻不是自己想要的，需要重新埋點。另外，后續產品版本更新迭代了，原有埋點不可用，也需要重新埋點。
3.數據采集方案要想清楚，哪些應該在前端埋點，哪些應該在后端埋點，埋點采集SDK如何正確使用在還沒了解清楚時就急于上手。數據統計口徑需要確定清楚，且和開發保持良好溝通，將埋點的具體采集時機正確傳達給開發，導致最終埋點實現的不是自己想要定義的指標。
4.在分析的一開始，建議采集少數的用戶行為。選擇少量、重要的用戶行為開始記錄和分析，這樣很快就能有成果產出。另外用戶行為不等同于應用的頁面或點擊操作，用戶行為是更加具體的一個事件定義。
5.埋點結束后，測試一般只會看一下埋點是否有數據返回，而不會一個個是對數據是否有收到以及是否準確。這個時候需要我們在有一定數據量積累的時候，對數據的有無和準確性進行驗證
-數據分析展示就用DataHunter-
