一文詳解數(shù)據(jù)埋點｜馬同學的數(shù)據(jù)筆記

數(shù)據(jù)流程：數(shù)據(jù)生產(chǎn)-數(shù)據(jù)采集-數(shù)據(jù)處理-數(shù)據(jù)分析和挖掘-數(shù)據(jù)驅動/用戶反饋-產(chǎn)品優(yōu)化/迭代。

數(shù)據(jù)埋點是基于業(yè)務需求或產(chǎn)品需求對用戶在應用內產(chǎn)生行為的每一個事件對應的頁面和位置植入相關代碼，并通過采集工具上報統(tǒng)計數(shù)據(jù)，以便相關人員追蹤用戶行為（點擊、瀏覽），推動產(chǎn)品優(yōu)化或指導運營的一項工程。

為什么要做數(shù)據(jù)埋點？

埋點將產(chǎn)品數(shù)據(jù)分析的深度下鉆到流量分布和流動層面，通過對產(chǎn)品中的用戶交互行為的統(tǒng)計分析，對宏觀指標進行深入剖析，發(fā)現(xiàn)指標背后的問題，尋找人群的行為特點和關系，洞察用戶行為與提升業(yè)務價值之間的潛在關聯(lián)，了解組成特定數(shù)據(jù)現(xiàn)象的原因，并據(jù)此構建產(chǎn)品優(yōu)化迭代和運營策略。

• 獲取關鍵指標。埋點可以獲得一些關鍵指標——瀏覽人數(shù)、點擊率、轉化率、退出率等等。
• 定位問題，監(jiān)控產(chǎn)品的流暢性，挖掘流失點，優(yōu)化產(chǎn)品。（漏斗優(yōu)化、用戶增長、流失用戶預警）通過獲得來的數(shù)據(jù)，我們可以判斷出哪些功能模塊對于用戶有較強的吸引作用，哪些功能模塊用戶瀏覽、點擊較少，從而定位出問題，對產(chǎn)品進行改進。
• 分析運營策略的合理性，優(yōu)化用戶體驗，提高使用效率。（精準營銷、場景化提示/私人助理）比如用戶去餐廳購買產(chǎn)品，每次都需要在APP中選擇是否使用優(yōu)惠券，但是通過埋點發(fā)現(xiàn)，全部的用戶對于該商家都是選擇的否，那么說明該商家是從來沒有進行優(yōu)惠券的發(fā)放，那么就可以考慮在商家版中增加一個是否讓用戶選擇優(yōu)惠券的選項，若商家沒有優(yōu)惠券，那么用戶就可以直接跳過選擇是否使用優(yōu)惠券，從而提升用戶體驗及使用效率。
• 分析用戶消費行為，分析不同渠道用戶行為差異。（風險識別）

埋點方式

前端的埋點方式主要分為代碼埋點、可視化埋點、無埋點三種。

1.代碼埋點

在終端嵌入SDK，定義事件并添加事件代碼，用戶所有操作行為會調用SDK的相應數(shù)據(jù)接口然后把數(shù)據(jù)發(fā)送服務端（數(shù)據(jù)庫）。按需采集，業(yè)務信息更完善，對數(shù)據(jù)的分析更聚焦，因此代碼埋點是一種以業(yè)務價值為出發(fā)的行為分析。

• 優(yōu)點：數(shù)據(jù)準確性高，自定義程度高，具有很強的靈活性，可以控制發(fā)送的時機和發(fā)送方式等。

埋點準確性順序：代碼埋點＞可視化埋點＞全埋點，SDK較小，對應用本身的使用體驗沒有影響，是最可控的埋點方式。

• 缺點：需要開發(fā)工程師手工開發(fā)，工作量大，人力成本較高；有時候還要依賴App發(fā)版來生效。
• 市面上產(chǎn)品有：GA（google analytics）、友盟、百度統(tǒng)計

舉例·應用場景：

• 如果你不希望在采集數(shù)據(jù)的同時，降低用戶體驗
• 如果你不希望采集到海量無用數(shù)據(jù)
• 如果你希望采集的數(shù)據(jù)：顆粒度更細，維度更多，數(shù)據(jù)分析的準確性更高那么，從業(yè)務增長的長遠價值考慮，請選擇代碼埋點。
• 常見的如：頁面停留時間，頁面瀏覽深度，視頻播放時長，用戶鼠標軌跡，表單項停留及終止等等。尤其是一些非點擊的、不可視的行為，是非要代碼埋點來實現(xiàn)不可了。

2.可視化埋點

可視化埋點以前端可視化的方式記錄前端設置頁面元素與對其操作的關系，然后以后端截屏的方式統(tǒng)計數(shù)據(jù)。無須進行添加代碼，只需在相應應用界面追加事件數(shù)據(jù)點即可（對于點擊操作的埋點是目前可視化埋點的主攻點）。核心代碼與資源配置器分開，當啟動應用時從服務端更新配置和資源，應用根據(jù)新的配置和資源發(fā)送數(shù)據(jù)。

支持可視化埋點的SDK 會在被監(jiān)測的網(wǎng)站或移動應用被訪問時向服務器校驗是否有新的埋點，如果發(fā)現(xiàn)更新的埋點，則會從服務器下載并且立即生效。這樣就能確保服務器收到最新的埋點后，所有客戶端都能在下一次訪問時得到部署了。

• 優(yōu)點：界面化配置，無需開發(fā)（可視化埋點的理念是提升原工作流程的效率——依然要梳理需求、設計埋點），埋點更新便捷，生效快（可直接在網(wǎng)站或移動應用的真實界面上操作埋點，而且埋點之后立即可以驗證埋點是否正確，而且將埋點部署到所有客戶端也是幾乎實時生效的。）。
• 缺點：不靈活，存在部分數(shù)據(jù)死角（埋點自定義屬性支持較差；重構或者頁面變化時需要重新配置），同時每次啟動加載服務端配置資源，消耗資源；從實際情況看，復雜頁面、不標準頁面、動態(tài)頁面都給可視化埋點增加不可用的風險，一旦遇到就還是只能代碼埋點了。
• 市面上產(chǎn)品有：諸葛IO、神策

3.無埋點/全埋點

無埋點采用“全部采集，按需選取”的形式，通過綁定頁面的各個控件，當事件觸發(fā)時就會調用相關的接口上報數(shù)據(jù)。并不是說不要埋點，而是SDk利用css選擇器技術和監(jiān)聽控件的事件觸發(fā)技術，在應用嵌入SDK，SDK會把頁面中所有交互元素的用戶行為數(shù)據(jù)盡可能的采集下來，通過“統(tǒng)計數(shù)據(jù)篩”，配置待處理的數(shù)據(jù)的特征。

無埋點/全埋點優(yōu)點：可視化展示界面，部署簡單、收集數(shù)據(jù)多，一切操作皆埋點，無需埋點統(tǒng)計數(shù)據(jù)按需處理

無埋點/全埋點缺點：

1. a)     無埋點只能采集到用戶交互數(shù)據(jù)，且適合標準化的采集（無埋點無法深入到更細、更深的粒度），自定義屬性的采集需要代碼埋點來輔助（現(xiàn)階段全埋點對于用戶身份信息和行為附帶的屬性信息也幾乎無能為力。）。
2. b)    無埋點具有前端埋點的固有缺陷，如數(shù)據(jù)采集深度較淺、傳輸時效性較差、數(shù)據(jù)可靠性無法保障等問題。
3. c)      數(shù)據(jù)維度單一（僅點擊、加載、刷新）；影響用戶使用體驗——用戶使用過程中容易出現(xiàn)卡頓，嚴重影響用戶體驗；噪點多，數(shù)據(jù)準確性不高，容易產(chǎn)生干擾；不能自定義埋點收集信息。
4. d)     全埋點的“全”以采集上報的數(shù)據(jù)量為代價，隨著數(shù)據(jù)量上升導致客戶端崩潰的概率也會上升。尤其是移動端，更多的數(shù)據(jù)量意味著更多的電量、流量和內存消耗。從這個角度來看，想做到真正的“全”在現(xiàn)階段也是很難。即使全部行為數(shù)據(jù)可以被接收回來，具體分析時的二次梳理和加工也無法避免，甚至痛苦。因為機器無法在采集時能按照我們想要的方式對全部事件進行有意義的命名，甚至無法保證采集上來的事件都正好是正確的。于是前期埋點時節(jié)省下來的人力成本，這個時候又都搭進去了。
5. l  應用場景：

主要應用于簡單頁面，比如：短期活動中的落地頁/專題頁中，需要快速衡量點擊分布等效果。

• 產(chǎn)品：Heap Analyitcs、諸葛IO

最理想的埋點方案是根據(jù)根據(jù)不同的業(yè)務和場景以及行業(yè)特性和自身實際需求，將埋點通過優(yōu)劣互補方式進行組合，比如：

1、代碼埋點+全埋點：在需要對落地頁進行整體點擊分析時，細節(jié)位置逐一埋點的工作量相對較大，且在頻繁優(yōu)化調整落地頁時，更新埋點的工作量更加不容小覷，但復雜的頁面存在著全埋點不能采集的死角，因此，可將代碼埋點作為輔助，將用戶核心行為進行采集，從而實現(xiàn)精準的可交叉的用戶行為分析；

2、代碼埋點+服務端埋點：以電商平臺為例，用戶在支付環(huán)節(jié)，由于中途會跳轉到第三方支付平臺，是否支付成功需要通過服務器中的交易數(shù)據(jù)來驗證，此時可通過代碼埋點和服務端埋點相結合的方式，提升數(shù)據(jù)的準確性；

3、代碼埋點+可視化埋點：因代碼埋點工作量大，可通過核心事件代碼埋點，可視化埋點用于追加和補充的方式采集數(shù)據(jù)。

埋點事件

在記錄埋點信息時，主要的埋點事件分為點擊事件、曝光事件、頁面事件三類。

1)  點擊事件

用戶在應用內的每一次點擊行為，都可以記為一次點擊事件。比如按鈕的點擊，區(qū)域的點擊，商品的點擊，每一條新聞的點擊等，都可以成為一個點擊事件。一般通過點擊事件，可以拿到點擊PV，點擊UV。

2)  曝光事件

曝光事件是為了統(tǒng)計應用內的某些局部區(qū)域是否被用戶有效瀏覽。比如推薦區(qū)域，某個按鈕，首焦等等。

比如一般來說我們在衡量頁面某個區(qū)域用戶的點擊率的時候，首先需要搞清楚的就是這個區(qū)域到底被多少用戶看到了，每被用戶看到一次就是一個簡單的曝光事件，然后才能計算點擊率。

做曝光埋點的時候需要注意兩個事情：第一，有效曝光的定義要科學，合理；第二，為了不影響頁面性能以及用戶體驗，不能在應用內的所有區(qū)域都加曝光埋點。

曝光埋點即不發(fā)生點擊行為，內容曝光時上報的埋點，多用于內容流（商品流）的數(shù)據(jù)分析，用來計算CTR（點擊通過率，點擊次數(shù)/曝光次數(shù)），用戶時長（曝光時長）。

下面以某電商App首頁商品流為例做埋點示例：

3）頁面事件

頁面事件通常是指頁面的各種維度信息的統(tǒng)計。常見的比如頁面瀏覽PV，頁面瀏覽UV。

頁面事件通常通過頁面參數(shù)來傳遞。

頁面事件通常統(tǒng)計的信息包括以下幾個部分：

• 瀏覽器信息：瀏覽器版本，瀏覽器語言，瀏覽器編碼，屏幕分辨率等；
• 訪問信息：用戶賬號，當前頁面url，上次訪問時間，訪問時長，頁面停留時間等；
• 來源信息：廣告來源，上一頁面url等；
• 物品信息：不同的業(yè)務，這部分信息區(qū)別很大。

現(xiàn)在App端的數(shù)據(jù)埋點一般采取Key-Value的形式，Key一般表示某個事件，Value代表相對應的值，一個Key可以對應一個Value或者多個Value。在埋點過程中，同種屬性的多個事件要命名成一個埋點事件ID，并以Key-Value的形式區(qū)分。不同屬性的多個事件應該命名成多個埋點事件ID，此時也盡量不用Key-Value的形式埋點。

事件三要素：

• 操作（action），定義一個操作動作，如點擊（click）、瀏覽（view）
• 屬性，這個事件相關的內容，比如一個商品瀏覽事件，屬性包含商品ID、商品標題、商品價格、所屬店鋪等信息。
• 屬性值，則表示該屬性對應的值，例如商品標題=“日本品牌一次性醫(yī)用口罩…”

埋點流程

• 運營：一主要需求方，根據(jù)業(yè)務場景，提出并明確具體的數(shù)據(jù)分析需求。
• 數(shù)據(jù)產(chǎn)品經(jīng)理：收集業(yè)務方的需求，將分析需求整理成埋點需求，并組織埋點需求評審、校驗埋點數(shù)據(jù)。
• 開發(fā)團隊：確認埋點可行性和排期，負責埋點開發(fā)、測試和上線。

（1）業(yè)務需求：確定場景或目標

梳理業(yè)務，確定一個場景/目標。

需求階段：進行需求采集和需求分析，保證埋點滿足核心業(yè)務需求。

• 數(shù)據(jù)需求池：對數(shù)據(jù)需求進行整體維護，記錄需求業(yè)務場景、需求內容、提出者、時間等
• 產(chǎn)品信息架構：梳理產(chǎn)品結構，熟悉產(chǎn)品（梳理產(chǎn)品交互架構和頁面設計布局）。
• 用戶行為路徑：分析用戶路徑，建立用戶行為流程圖，得到核心業(yè)務指標，定義好該事件的觸發(fā)時機

優(yōu)先級評估——KANO模型

KANO模型定義了三個層次的用戶需求:基本型需求、期望型需求、興奮型需求。

這三種需求根據(jù)績效指標分類就是基本因素、績效因素和激勵因素。

（2）埋點設計：數(shù)據(jù)采集規(guī)劃，確定關鍵指標

設計階段：埋點版本規(guī)劃和埋點設計(1，確認事件與變量；2，明確事件的觸發(fā)時機；3， 規(guī)范命名；4，明確優(yōu)先級)

• 埋點版本規(guī)劃：根據(jù)需求優(yōu)先級，分版本上線，快速迭代；
• 埋點文檔：詳細描寫版本記錄、數(shù)據(jù)流程圖、埋點事件等內容；
• 埋點的基本信息：業(yè)務、等級、應用、使用說明、打點時機、測試說明、需求文檔等；
• 埋點對應角色：產(chǎn)品經(jīng)理/業(yè)務部、數(shù)據(jù)產(chǎn)品經(jīng)理、開發(fā)團隊；
• 埋點對應字段和字段取值。
• 埋點位置。即需要添加埋點相關信息的位置，比如頁面上的按鈕，搜索結果的每一個卡片，推薦位上的每一個卡片，每一個曝光區(qū)域等等；
• 埋點標識。每一個位置上面需要設置一個埋點的標識來代表這個點擊位；
• 埋點參數(shù)。是指你想要在用戶到達這個位置or頁面，或者點擊這個位置的時候，除了正常的流量數(shù)據(jù)（pv，uv），還想看到那些數(shù)據(jù)；
• 頁面名稱。是指當前埋點所屬的頁面，有這個才能定位到當前埋點是屬于哪個頁面的數(shù)據(jù)；
• 應用標識。是指當前應用的唯一標識，有的也叫站點。用來進行數(shù)據(jù)歸屬劃分。

產(chǎn)品的埋點方案通常由產(chǎn)品經(jīng)理來進行梳理，梳理完畢之后需要協(xié)同數(shù)據(jù)的同事進行確認，核對，保證方案的可行性。

（3）評審開發(fā)：埋點工具植入

采集工具通常為埋點代碼，通常有三種：js文件，SDK，http請求。

埋點代碼等同于一個監(jiān)控系統(tǒng)的中樞，可以說是整個產(chǎn)品埋點的引擎，控制著埋點的數(shù)據(jù)的采集上報，只有它才能夠在用戶與應用發(fā)生交互的時候上報點擊位信息，曝光信息，頁面信息等等。

這塊通常是研發(fā)來做，產(chǎn)品經(jīng)理參與。

（4）測試驗收：埋點測試與數(shù)據(jù)評估

埋點測試是指完成埋點工作后，需要對埋點的有效性進行測試。這塊通常由測試來做，產(chǎn)品經(jīng)理參與。

埋點12字訣：引沒引，埋沒埋，報沒報，落沒落。

• 引：是指埋點代碼是否引入，引入的代碼是否與當前產(chǎn)品形態(tài)吻合；
• 埋：是指是否產(chǎn)品的所有模塊都添加了埋點；
• 報：是指埋點之后數(shù)據(jù)是否能夠正常上報；
• 落：是指上報的數(shù)據(jù)最后是否落到了對應的表里面。

(5) 上線應用

埋點采集的缺點：依賴經(jīng)驗導向；溝通成本高；大量時間數(shù)據(jù)清洗；數(shù)據(jù)漏采錯采。