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

一、?收集需求

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

埋點的兩個使用場景：

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

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

?

二、?? ?數(shù)據(jù)埋點與數(shù)據(jù)需求文檔

埋點困境：

1、困境一：自己理不清

• 要啥數(shù)據(jù)
• 有啥屬性

2、困境二：RD聽不懂

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

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

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

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

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

?

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

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

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

3.1 需求→指標(biāo)→埋點

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

在登錄頁埋點，會記錄到

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

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

3、點擊注冊--跳轉(zhuǎn)頁面

4、忘記密碼--跳轉(zhuǎn)頁面

這4個事件我們怎么記錄呢，事件名稱分別叫l(wèi)ogin_pageview、register_pageview、校驗失敗、forgetpassword_pageview嗎？

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

這就回到了埋點的最終目的和初衷：有能力觀測及分析數(shù)據(jù)。這時候我們選擇適當(dāng)?shù)穆顸c屬性，有兩種方法：

• 依據(jù)經(jīng)驗，預(yù)先按分析維度設(shè)計屬性

較為依賴分析經(jīng)驗

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

• 根據(jù)套路，預(yù)先設(shè)計埋點屬性

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

Who:有兩種記錄方法，一個是認(rèn)設(shè)備，一個是認(rèn)人；

When，有兩個問題：

1、哪個節(jié)點產(chǎn)生的

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

2、哪個時區(qū)的時間

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

Where:有3種記錄方法

1、GPS

GPS是通過衛(wèi)星定位當(dāng)前的位置經(jīng)緯度，但日常做分析的時候，需要的是行政區(qū)縣的信息，比如在北京市朝陽區(qū)，GPS怎么轉(zhuǎn)換成省市區(qū)呢？通過專業(yè)的工具，比如調(diào)取高德、百度公開的API.

2、IP地址

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

3、自主填寫

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

How:

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

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

?

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

事件聚類：

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

3.2 事件分類

我們就埋點方案的前端埋點著重說一下，無線客戶端的日志采集采用采集SDK來完成。根據(jù)不同的用戶行為分成不同的事件，“事件”是無線客戶端日志行為的最小單位，一個行為產(chǎn)生一條日志，如一次瀏覽、一次點擊等?；诔Ｒ?guī)的分析，事件分為頁面事件（頁面瀏覽）和控件點擊事件，頁面事件和控件點擊事件的日志觸發(fā)時機、日志內(nèi)容和實現(xiàn)方式有差異之處：

3.2.1 頁面事件

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

①設(shè)備及用戶的基本信息，主要包括：城市、地址、年齡、性別、經(jīng)緯度、賬號類型、運營商、網(wǎng)絡(luò)、設(shè)備等等；

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

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

實現(xiàn)頁面事件的三種方法：

①無痕模式：采集SDK在頁面創(chuàng)建時即發(fā)送日志；

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

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

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

3.2.2 控件事件

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

①設(shè)備及用戶的基本信息；

②記錄控件所在頁面名稱、控件名稱、控件的業(yè)務(wù)參數(shù)等。

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

4.1 埋點位置選擇

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

?

前端埋點的弊端：

• 某些屬性前端沒有

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

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

• 改動依賴產(chǎn)品發(fā)版

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

• 事件上報時機略尷尬

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

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

?

4.2 埋點屬性的來源

前端的屬性來源有：

• 調(diào)用API
• 取頁面上的值
• 行為統(tǒng)計，比如使用頁面計時器計算頁面停留時長

后端的屬性來源：

• 業(yè)務(wù)數(shù)據(jù)
• 查關(guān)聯(lián)表
• 前端送來的數(shù)據(jù)
• 技術(shù)數(shù)據(jù)，比如用戶發(fā)送搜索請求，搜索引擎的搜索時間是幾秒記錄下來

4.3 埋點有效性的校驗

檢驗的手段：

• 抓包
• 看數(shù)據(jù)平臺是否顯示對應(yīng)事件

?

檢驗的方法：

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

檢驗的意義：

• 數(shù)據(jù)不具備回溯性，信息損失了，后續(xù)再也補不回來了

4.4 埋點文檔的維護

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

?

五、?? ?數(shù)據(jù)采集實戰(zhàn)

在本小節(jié)中，用某Feed流產(chǎn)品來講述整個數(shù)據(jù)采集歷程。

5.1 業(yè)務(wù)背景

5.2? 指標(biāo)建模

根據(jù)收集需求的數(shù)據(jù)建立相應(yīng)的指標(biāo)，來源2個方面：

• 產(chǎn)品自身的指標(biāo)建模

個性化推薦產(chǎn)品方面的指標(biāo)有人均內(nèi)容曝光量、內(nèi)容的點擊率、評論數(shù)、點贊數(shù)

• 業(yè)務(wù)部門的分析需求

每個卡片配[不感興趣]按鈕，用于分析什么原因?qū)е掠脩簟安桓信d趣”；

用戶主動刷新/加載內(nèi)容

區(qū)分不同推薦理由（好友推薦、單個用戶的歷史內(nèi)容推薦、當(dāng)前社區(qū)熱門推薦）

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

廣告曝光時長

需求轉(zhuǎn)化為指標(biāo)：

指標(biāo)轉(zhuǎn)化為埋點

通用屬性

反復(fù)溝通：?

六、?? ?其他類型的數(shù)據(jù)采集方法

七、?? ?總結(jié)：數(shù)據(jù)采集

?

雜項，待梳理：

1.2.3?埋點管理

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

埋點位置

埋點事件

事件變量定義

其他說明

指標(biāo)變更日志備注

平臺類型

一級模塊

二級模塊

三級模塊

四級模塊

事件顯示名

觸發(fā)時機

事件英文變量

事件變量

變量顯示名

變量值示例或說明

變量值類型

埋點形式

埋點版本

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

一級模塊：APP的話指下方的標(biāo)簽菜單，比如首頁、通訊錄、發(fā)現(xiàn)...，Web的話指首頁菜單；

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

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

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

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

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

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

其中11-001-001是指一級選課“我”模塊下的“設(shè)置”的“關(guān)于”選項

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

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

舉一例，電商產(chǎn)品，商品詳情頁的事件變量怎么設(shè)計，見下圖：

?

?

參考資料：

埋點的設(shè)計、管理與應(yīng)用

埋點—這一篇文章就夠了

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。