數據分析流程數據采集→指標建模→觀測數據→數據分析→業務洞察，數據采集首當其沖，而數據采集中埋點是其中的一個重要方法，移動端的數據采集，一是為了服務于開發者，協助開發者分析各類設備信息；二是為了幫助各APP更好地了解自己的用戶，了解用戶在APP上的各類行為，幫助各應用不斷進行優化，提升用戶體驗，比如業務遇到了問題，在分析的時候也找到了可能的原因在哪，并提出解決方案，但最后會遇到缺指標缺屬性導致分析沒有辦法繼續進行。

一、?收集需求

收集數據來源于兩個方面，一個是產品自身的指標建模，另一個是業務部門的分析需求，比如一個共享出行APP新上一個包月服務，其中最重要的模塊是交易模塊，相關的數據指標有交易總金額和詳情頁轉化率，業務部門提出的需求是包月中有一項是企業版出行服務，他們想知道企業版入口點擊率和該渠道用戶付費轉化率。

埋點的兩個使用場景：

1、酒店預訂類APP，單頁內步驟多，如果對單頁內各事件埋點，無法做漏斗分析，得知用戶在哪一步流失；

2、客戶投訴原因：如果想分析投訴具體出在哪個環節，而這個環節只能在用戶操作時記錄下來，如果沒有即時記錄就沒有相關數據，我們就需要埋點支持。

?

二、?? ?數據埋點與數據需求文檔

埋點困境：

1、困境一：自己理不清

• 要啥數據
• 有啥屬性

2、困境二：RD聽不懂

• 前端采集or 后端采集？
• 跨越前-后端取值？

比如用戶點擊支付按鈕，前端埋點可能統計有2000人的點擊，而后臺確定的訂單人數只有700人，這中間用戶點擊支付以后，需要選擇支付方式，填寫銀行卡之類的信息，后臺才會收到第三方網關支付成功的確認后才會統計，如果只統計前端的話數據誤差較大，只統計后端的話又不知道支付的平均停留時長（只有客戶端才知道），故只有跨前-后端埋點，才會獲取全部數據。

為了解決埋點困境，我們就需要一份數據需求分檔，由兩部分組成：

1、埋點需求：告訴研發做什么事情

2、記錄實施過程中的細節：有了細節以后，能夠保障長期可維護性，并可以讓自己想的更明白，研發更容易聽得懂。

?

三、?? ?明確埋點需求（想清楚）

我們收集完需求以后，需求需要轉化為指標，而指標需要落實到埋點上，比如我們的業務需求是交易模塊運轉的是否順暢，但為了衡量是否順暢，我們選擇了交易轉化率這個指標來描述，交易轉化率這個指標又不能被直接統計到，需要拆解成支付完成和頁面加載這兩個行為事件。

在需求開始，我們往往需要找到描述該需求的指標，再去研究這個數據指標需要怎樣的埋點來支撐，在確定要采集哪些埋點之后，還需要確認哪些屬性來配合我們后續的分析。

3.1 需求→指標→埋點

案例：新浪微博登錄頁埋點

在登錄頁埋點，會記錄到

1、訪問登陸頁面的PV 、UV

2、用戶輸入郵箱后驗證的結果，校驗郵箱的代碼發現用戶輸入郵箱有問題的時候，一方面會提醒用戶郵箱格式有問題，同時也會發出一條日志說郵箱校驗失敗

3、點擊注冊--跳轉頁面

4、忘記密碼--跳轉頁面

這4個事件我們怎么記錄呢，事件名稱分別叫login_pageview、register_pageview、校驗失敗、forgetpassword_pageview嗎？

今天有多少個用戶訪問登陸頁面？是幾天的數據？校驗失敗的原因是什么？

這就回到了埋點的最終目的和初衷：有能力觀測及分析數據。這時候我們選擇適當的埋點屬性，有兩種方法：

• 依據經驗，預先按分析維度設計屬性

較為依賴分析經驗

頻繁添加埋點，則需要RD密切配合

• 根據套路，預先設計埋點屬性

套路有4W1H，一個優秀的完備的埋點應該包含Who When Where How What，即某個用戶在某個時間點、某個地方以某種方式完成了某個具體的事情。

Who:有兩種記錄方法，一個是認設備，一個是認人；

When，有兩個問題：

1、哪個節點產生的

為節約用戶手機電量，研發不會對用戶每產生1個事件就上報日志，通常策略是延遲30秒，集中打包上傳30秒內的埋點數據，研發做的不好的話這30秒的事件時間都被打成同一個時間，即上報時間，而不是真實的事件發生時間，做行為序列的時候就很尷尬；還有的用戶點擊了某些按鈕，產生了2個事件，手機突然斷網，第二天才恢復正常，昨天的數據今天才入庫，這時對數據處理入庫的話，數據會入到今天的數據，統計日活的話會遇到問題，這個影響不是很大，心里知道就行了。

2、哪個時區的時間

事件時間記錄有2種方法，一個是上報時間時，帶時區，現在的APP世界各地都有用戶，在后期分析時統一時間會增加處理難度，另一種方法是使用Unix時間戳，優點是全世界統一，和時區沒關系，在全世界取這個值都是唯一的，因為它的運行原理是從1970年1月1日0點0分0秒開始計數，每增加1秒就加1。

Where:有3種記錄方法

1、GPS

GPS是通過衛星定位當前的位置經緯度，但日常做分析的時候，需要的是行政區縣的信息，比如在北京市朝陽區，GPS怎么轉換成省市區呢？通過專業的工具，比如調取高德、百度公開的API.

2、IP地址

在電腦上網或手機不授權GPS定位的情況下，可以從IP獲取地址，不過IP地址獲取的地址范圍比較廣，只能到城市，沒法具體到區縣和街道。

3、自主填寫

這個使用場景是用戶實際在哪不重要，用戶希望在哪才重要，比如用戶身在北京，想去重慶租房。

How:

圍繞用戶做某個事情的時候，他所處的環境是什么（設備、版本...），盡可能地把這個環境全面的還原出來。

What:關于事件更詳細的信息，比如“購買”這個事件，我需要知道我買的這個商品名稱、類型，用戶買了幾件，付了多少錢，付款方式是什么？再比如昨天申請退貨之前每天基本在100人左右，昨天突然增加到1000人，我們通過拆分退貨方式，發現80%的退貨方式是快遞，我就就知道分析的方向。

?

公共屬性：通過上面的4W1H分析，不管是什么事件，我們總要知道Who When Where How What這5個公共屬性，那這個地方出現一個問題，比如說支付系統的研發，覺得Who應該取device_id,換了另一個開發者，他取了user_id,不同的研發不同的想法，When有的研發取Unixstamp，有的取日期時間，公共屬性的定義不一樣，做交叉分析和合并分析就沒法進行，這個問題的解決方案是什么？把公共屬性的部分統一起來讓一個研發管理，其他研發埋點的時候不需要自己取，直接讀公司公共屬性表，就解決了公共屬性統一維護的難題。

事件聚類：

如果有一大堆埋點名稱，但背后對應的動作和行為都是同一個事件（比如都是支付，名稱可以是詳情頁支付、首頁支付 、H5支付...），如果老板讓統計昨天有多少次支付事件，遇到這種問題推薦做法是事件聚類，即埋點指標名稱合成一個，但在不同位置/地方還有有一些區別，這時候我們需要開一個屬性（position）就能區分開，這個屬性作為How的一部分。

3.2 事件分類

我們就埋點方案的前端埋點著重說一下，無線客戶端的日志采集采用采集SDK來完成。根據不同的用戶行為分成不同的事件，“事件”是無線客戶端日志行為的最小單位，一個行為產生一條日志，如一次瀏覽、一次點擊等。基于常規的分析，事件分為頁面事件（頁面瀏覽）和控件點擊事件，頁面事件和控件點擊事件的日志觸發時機、日志內容和實現方式有差異之處：

3.2.1 頁面事件

每條頁面事件日志記錄三類信息：

①設備及用戶的基本信息，主要包括：城市、地址、年齡、性別、經緯度、賬號類型、運營商、網絡、設備等等；

②被訪問頁面的信息，主要是一些業務參數：商品詳情頁的商品ID、所屬的店鋪等；

③訪問基本路徑（如頁面來源、來源的來源等），用于還原用戶完整的訪問行為等。

實現頁面事件的三種方法：

①無痕模式：采集SDK在頁面創建時即發送日志；

②手動模式：提供兩個接口，分別在頁面展現和頁面退出時調用，當用戶進入一個商品詳情頁時，調用頁面展現的接口，該接口會記錄頁面進入時的一些狀態信息，但此時不發送日志，當從詳情頁離開時（可能在詳情頁點擊某個商品到了對應的商品詳情頁，也可能退出了APP，抑或是點擊返回，返回到了之前的一個頁面），調用頁面退出的接口，該接口會發送日志；

③頁面擴展信息的接口，在頁面離開前，使用該接口提供的方法給頁面添加相關參數，比如給商品詳情頁添加店鋪ID、店鋪類型等。

上述三種接口方法必須配合使用，即頁面展現和頁面退出方法必須成對使用（方便計算停留時長），而頁面擴展信息的接口必須在使用頁面展現和頁面退出方法的前提下使用。為了平衡采集、計算和分析的成本，在部分場景下我們選擇采集更多的信息來減少計算及分析的成本。采集SDK提供透傳參數功能。所謂透傳參數，即把當前頁面的某些信息，傳遞到下一個頁面甚至下下一個頁面的日志中。舉個例子，首頁搜索“連衣裙”，進入搜索List頁面，然后點擊某個商品進入商品A詳情頁。如果分析“連衣裙”這個關鍵詞，或者商品A的來源搜索詞，此時就需要把“連衣裙”這個關鍵詞帶入到搜索List頁面日志、商品A詳情頁日志中，這樣一來，分析搜索詞的效果就顯而易見了，通過透傳機制將參數帶入到下一步甚至下下一步的瀏覽頁面，整個用戶行為路徑還原輕松實現。

3.2.2 控件事件

控件點擊事件，比頁面事件要簡單得多，點擊即發送日志，他記錄兩類信息：

①設備及用戶的基本信息；

②記錄控件所在頁面名稱、控件名稱、控件的業務參數等。

四、?? ?形成需求文檔（講明白）

4.1 埋點位置選擇

埋點位置選擇，除非某個行為只在前端發生（比如美顏自拍APP,拍照時選了哪款濾鏡，以及列表的訪問深度：讀了幾條內容），否則，建議永遠在后端采集。比如用戶點擊A，發出一個“給我看A商品詳情頁”請求給后端，后端收集A商品各項信息，返回給前端，前端會渲染A商品詳情頁的數據，用戶在前端點擊購買，后臺完成訂單、庫存等操作反饋前端購買狀態，按照“購買”這個事件來說，它到底放前端還是后端比較合適？比如放用戶前端點擊“購買”按鈕，還是在后端完成一系列訂單庫存操作之后再采集數據？我們知道用戶的行為不可控，有可能在點擊“購買”按鈕啪啪啪點兩三次，或偶爾忘記點了又多點一次，我們只希望記錄最真實的一次，像“購買”這樣的操作，我們希望埋在后端，記錄真正完成訂單操作的數據。

?

前端埋點的弊端：

• 某些屬性前端沒有

where/what/how的許多信息，往往只存在于后端。

比如“where”，用戶的手機或電腦有時會在重重防火墻和路由器后面，網頁是不知道自己的IP是什么，而后端服務器知道出口IP是什么，“How”和“What”更不用提了，想記錄用戶瀏覽的商品，他的類型是什么？是不是折扣品，前端頁面壓根沒有這樣的信息，這個信息只存在于后端數據庫；

• 改動依賴產品發版

后端埋點隨時可以改，可以發布，隨時可以添加更改，放在前端需要發版，時間往往在十天半月之后；

• 事件上報時機略尷尬

前端上報時機略尷尬，我們既想幫用戶省流量/省電量，又想數據及時上報，前端埋點需要在這兩方面做取舍，后端就沒有這個矛盾。

埋點有3種方案，一般采用前端埋點和服務端埋點相結合的方式，因為有些數據流分析需要跨前-后端取值，比如用戶點擊支付按鈕，前端埋點可能統計有2000人的點擊，而后臺確定的訂單人數只有200人，這中間用戶點擊支付以后，需要選擇支付方式，填寫銀行卡之類的信息，后臺才會收到第三方網關支付成功的確認后才會統計，如果只統計前端的話數據誤差較大，只統計后端的話又不知道支付的平均停留時長（只有客戶端才知道），故只有跨前-后端埋點，才會獲取全部數據。

?

4.2 埋點屬性的來源

前端的屬性來源有：

• 調用API
• 取頁面上的值
• 行為統計，比如使用頁面計時器計算頁面停留時長

后端的屬性來源：

• 業務數據
• 查關聯表
• 前端送來的數據
• 技術數據，比如用戶發送搜索請求，搜索引擎的搜索時間是幾秒記錄下來

4.3 埋點有效性的校驗

檢驗的手段：

• 抓包
• 看數據平臺是否顯示對應事件

?

檢驗的方法：

• 與DRD“逐個”對比，核驗是否符合預期 --最笨最有效的方法，拿著數據需求文檔，比如埋點有7個埋點，我一個個點頁面或按鈕，檢查埋點里的名稱和屬性是否正確

檢驗的意義：

• 數據不具備回溯性，信息損失了，后續再也補不回來了

4.4 埋點文檔的維護

有一個專門的維護需求文檔?的字段（是否在線、上線時間、下線時間、修改備注），方便日后其他同事回顧并了解這些埋點的細節，修改備注可以填寫特殊的埋點邏輯，供日后參考。

?

五、?? ?數據采集實戰

在本小節中，用某Feed流產品來講述整個數據采集歷程。

5.1 業務背景

5.2? 指標建模

根據收集需求的數據建立相應的指標，來源2個方面：

• 產品自身的指標建模

個性化推薦產品方面的指標有人均內容曝光量、內容的點擊率、評論數、點贊數

• 業務部門的分析需求

每個卡片配[不感興趣]按鈕，用于分析什么原因導致用戶“不感興趣”；

用戶主動刷新/加載內容

區分不同推薦理由（好友推薦、單個用戶的歷史內容推薦、當前社區熱門推薦）

每天廣告的曝光量及CTR效果

廣告曝光時長

需求轉化為指標：

指標轉化為埋點

通用屬性

反復溝通：?

六、?? ?其他類型的數據采集方法

七、?? ?總結：數據采集

?

雜項，待梳理：

1.2.3?埋點管理

在初期的數據建設階段，先要做的是定義想要的數據，告訴前端開發和后臺的同事，你想要的數據有哪些，定義這些數據的字段包括但不限于以下字段：

埋點位置

埋點事件

事件變量定義

其他說明

指標變更日志備注

平臺類型

一級模塊

二級模塊

三級模塊

四級模塊

事件顯示名

觸發時機

事件英文變量

事件變量

變量顯示名

變量值示例或說明

變量值類型

埋點形式

埋點版本

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?埋點指標定義
上圖字段，分別解釋下：? ? ? ? ?
埋點位置：平臺類型覆蓋了APP（分安卓或者ios端，因為有一些交互安卓與ios不同所以要做區分）、Web和小程序平臺，其中有部分核心功能、頁面在三個平臺都有涉及（類似于電商平臺的商品詳情頁），分開管理會造成指標冗余，因此對于多平臺存在的核心指標，采用的是統一事件名定義，不同平臺觸發時，數據上報到同一個事件名上，通過平臺類型（platform_type）進行拆分；? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 功能模塊，分四級：

一級模塊：APP的話指下方的標簽菜單，比如首頁、通訊錄、發現...，Web的話指首頁菜單；

二級模塊：一級模塊下的全部頁面，比如課程列表頁、詳情頁、購課單頁、banner詳情頁····

三級模塊：二級模塊全部頁面中的全部按鈕，

每一個按鈕都有唯一一個id，這個id組成是一級模塊、二級模塊、三級模塊的id串聯

比如點擊事件 11-001-001，

其中11是指“我”一級模塊

其11-001是指一級選課模塊下的“設置”

其中11-001-001是指一級選課“我”模塊下的“設置”的“關于”選項

這樣每一個頁面每一個按鈕都有條理的排列下來了，其中，比較難處理的是每個模塊的瀏覽，模塊長短不一，到何種深度會觸發對應模塊的瀏覽，需要定義時想清楚，與開發溝通實現細節，避免后期踩坑。

事件變量定義：用來定義事件的參數，也可以理解為事件維度。該字段決定了事件的顆粒度，直接影響到事件下鉆的顆粒度，對于數據PM來說，平臺不同位置的事件抽象后，盡可能提取出公用事件，然后通過事件變量進行區分，能減少：指標冗余、指標管理工作、培訓成本，以及使用者的學習成本。當然這里也并不完全執著于抽象公用性，對于數據PM和開發來說，指標越精簡越好，便于理解和管理，但可能對于運營同事來說，學習和使用成本高企，數據產生了但無法最大化應用側價值，那就得不償失，所以需要平衡。

舉一例，電商產品，商品詳情頁的事件變量怎么設計，見下圖：

?

?

參考資料：

埋點的設計、管理與應用

埋點—這一篇文章就夠了

總結

以上是生活随笔為你收集整理的数据埋点与数据需求文档的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。