2023年一文讀懂 - B端數(shù)據(jù)埋點

一文讀懂|B端數(shù)據(jù)埋點哈嘍~不知各位奮斗在一線的B端小伙伴是否會經(jīng)常會有以下的困惑？

現(xiàn)有的設(shè)計方案是最適合用戶的嗎？如何通過科學(xué)的手段去驗證呢？設(shè)計了多個版本的方案，畢竟哪個版本是更好的？為什么是這個版比較好？

設(shè)計師在輸出設(shè)計稿之時，通常會使用各式各樣方法論來幫助設(shè)計，如：用戶調(diào)研，競品分析，可用性測試等。但是這些方法論并不能很客觀驗證我們的設(shè)計。想要客觀驗證我們的設(shè)計只有通過數(shù)據(jù)去發(fā)掘有方案里面的問題，驗證最終方案是否有效；而數(shù)據(jù)的埋點是我們打開數(shù)據(jù)思維的重要一環(huán)。

什么是數(shù)據(jù)埋點？

“應(yīng)用埋點數(shù)據(jù)”也叫“埋點數(shù)據(jù)”或“前端頁面數(shù)據(jù)”，我們可以簡潔理解為“通過技術(shù)手段獲得用戶在應(yīng)用內(nèi)（網(wǎng)站、客戶端、小程序等）的操作行為數(shù)據(jù)”。其背后原理是：用戶和界面發(fā)生交互，系統(tǒng)需要向服務(wù)器發(fā)送懇求和返回懇求，把這些懇求預(yù)埋一段計數(shù)代碼，就能得到頁面的曝光數(shù)據(jù)和用戶的操作數(shù)據(jù)?！浴厄v訊文檔|數(shù)據(jù)化設(shè)計》

拿個通俗的例子來講，數(shù)據(jù)埋點就像是我們城市街道里面的攝像頭，每一個攝像頭、都是城市這個大系統(tǒng)的一個埋點，它監(jiān)控記錄著這個區(qū)域里面發(fā)生的一切事情，滿意交通，市政，企業(yè)管理，等等的需求。通過這個比方是不是就能很快明白什么是數(shù)據(jù)埋點了呢？

我們對埋點的定義有了一個基礎(chǔ)的認知，那么請各位小伙伴們想一想，我們在日常工作中數(shù)據(jù)質(zhì)量慘淡的緣由是什么？這邊給大家5秒鐘思索一下~

5

4

3

2

1

信任大家或多或少都會有一些小思路！那么此處共享一些我們公司數(shù)據(jù)混亂的緣由，起初，我在剛來公司時，整個接受的業(yè)務(wù)數(shù)據(jù)質(zhì)量是存在著特別大的提升空間的，查看了現(xiàn)有數(shù)據(jù)后發(fā)覺主要問題在于數(shù)據(jù)收集這一塊沒有做好，而今日要提到的數(shù)據(jù)埋點又是數(shù)據(jù)收集這塊的主要方式，我總結(jié)了我們公司數(shù)據(jù)混亂的緣由有以下幾點：

前期產(chǎn)品上線壓根沒考慮到埋點；埋點后模塊數(shù)據(jù)無法正常上報或者上報錯誤不進行處理；埋點方式錯誤，沒有找準(zhǔn)關(guān)鍵數(shù)據(jù)指標(biāo)；PC端采納了M端的埋點方式，B端產(chǎn)品采納了C端的埋點方式。

不知道有木有小伙伴的狀況和我們的全都呢？，假如有那得打起十二分精神看下去啦，下面會講一些怎么去優(yōu)化這種狀況的方法。

一、你的數(shù)據(jù)來源真的精確?????嗎？

在總結(jié)埋點的方法之前，我與許多在B端行業(yè)深耕多年的設(shè)計小伙伴們溝通后，發(fā)覺一個特別魔幻的現(xiàn)象。

的確隨著互聯(lián)網(wǎng)環(huán)境轉(zhuǎn)變，無論是在處理產(chǎn)品迭代需求還是運營的活動，都會依靠數(shù)據(jù)作為一個決策參考。但是通常我們的對數(shù)據(jù)來源卻不會產(chǎn)生質(zhì)疑，設(shè)計師的數(shù)據(jù)來源通常都是從產(chǎn)品那邊拿來的，我們卻沒思索過產(chǎn)品是從哪里拿來的數(shù)據(jù)。深挖以后才發(fā)覺產(chǎn)品對手上的數(shù)據(jù)真實性其實也沒有驗證過，因此產(chǎn)品端數(shù)據(jù)都是模糊的更別提經(jīng)手到設(shè)計這邊了。

那么假如我們能通過自身推動埋點需求，獵取想要的數(shù)據(jù)，便從根源上解決了數(shù)據(jù)真實性的問題了~

二、B端設(shè)計師需要懂得的埋點學(xué)問有哪些？

前面提到了攝像頭是監(jiān)控一個城市是否運作良好的重要工具，同樣的，數(shù)據(jù)埋點也是監(jiān)控我們產(chǎn)品體驗良好的重要手段。當(dāng)一個城市發(fā)生交通事故的時候，我們可以依靠攝像頭來還原大事的過程，從而得出結(jié)論和處理方法，當(dāng)用戶反饋一個問題時我們也可以通過埋點的數(shù)據(jù)去給我們的產(chǎn)品開處方，避開頭疼醫(yī)頭、腳疼醫(yī)腳的尷尬境地。

埋點的兩種模式？

1）私有化部署

在一些對數(shù)據(jù)平安性要求比較高的工地，他們會自主研發(fā)或私有化部署適合自身的獨立數(shù)據(jù)系統(tǒng)。

2）接入第三方服務(wù)

目前大部分公司更多是專注業(yè)務(wù)本身，埋點直接使用第三方的技術(shù)服務(wù)；接入第三方技術(shù)服務(wù)優(yōu)勢在于研發(fā)成本低，幾乎能滿意企業(yè)對數(shù)據(jù)埋點的要求。同樣缺點也是蠻明顯的，無法定制共性化埋點方案，存在數(shù)據(jù)風(fēng)險等。

目前市面上有許多的數(shù)據(jù)支持公司，例如：神策、GrowingIO、友盟等。

三、B端那些地方需要進行埋點？

B端產(chǎn)品，尤其是業(yè)務(wù)系統(tǒng)，埋點的作用往往觀看并討論用戶對各項產(chǎn)品功能的接受程度、使用狀況，以及用戶的操作習(xí)慣等，從而進一步評估功能設(shè)計是否合理，是否幫用戶提高了效率等，為持續(xù)優(yōu)化供應(yīng)依據(jù)。因此就很清楚我們的埋點思路了。

1.上線新的功能時

在產(chǎn)品設(shè)計前，產(chǎn)品和設(shè)計師都會進行肯定的調(diào)研，依據(jù)調(diào)研結(jié)果判定功能是否符合用戶的真實需求，但是前期的調(diào)研結(jié)果其實是主觀的，無論是采納問卷、訪談等形式，用戶的反饋并不能其真實的想法。

通過埋點新功能相關(guān)點位，我們發(fā)覺用戶使用量符合預(yù)期，那說明這是一個正確的決策。假如發(fā)覺沒有人用，那可能這個功能宣揚太弱，用戶沒發(fā)覺，也可能這個決策根本就是錯誤的。

此處埋點的目的主要在于功能的優(yōu)化，常用于對新上線功能的檢測。

舉個例子：比如我們產(chǎn)品新上線了一個功能，該功能屬于便利用戶進行表格篩選。那么我們就需要對這個篩選功能的使用頻率進行檢測，用以判定我們的業(yè)務(wù)結(jié)果；詳細需要測量其那種類型數(shù)據(jù)指標(biāo)，這里可以提前說一下是點擊量這個指標(biāo)，詳細的類型后面會提到。

2.核心業(yè)務(wù)功能

與業(yè)務(wù)關(guān)聯(lián)性強的都可以算為重點功能，比如我們是做電商零售平臺的，那么訂單管理，商鋪管理這些模塊毫無疑問是重點功能，與這些模塊相關(guān)的用戶操作路徑上的交互控件都應(yīng)當(dāng)受到監(jiān)控。

舉個例子：我們公司是做電商零售平臺的，最近用戶反饋在訂單管理里面能不能將近三個月訂單放在第一個table上便利他不用去切換。當(dāng)然不是有單個用戶反饋就去改產(chǎn)品的結(jié)構(gòu)的，這時候我們就需要提取這幾個table的點擊狀況來推斷這幾個table的權(quán)重了。假如大部分用戶需要來回切換近三個月訂單，我們便可以考慮將其放在進入頁面的首位。

3.推斷設(shè)計方案

在C端我們可以通過A/BTest的方式來觀看數(shù)據(jù)，看哪個位置或者形式更能引起用戶的留意，達到想要的效果。

B端產(chǎn)品也會采納類似這個的方式，此處也舉個例子：比如最近想要改版一下關(guān)于消息通知是從頂部右側(cè)彈出還是從底部右側(cè)彈出更不干擾用戶，當(dāng)然我們可以看競品怎么做，但是總是借鑒競品也不是解決根本問題的方法。此時我們可以將時間維度作為測試基本盤，通過不同的方案獵取不同的數(shù)據(jù)來進行決策。

四、用戶會觸發(fā)哪幾類行為？

在檢測用戶數(shù)據(jù)之前，需要了解用戶在PC端上會觸發(fā)哪幾種行為？根據(jù)獵取數(shù)據(jù)的類型和用戶觸發(fā)的行為不同，通?？梢詫⒂脩粜袨榉譃辄c擊大事、曝光大事、頁面大事三種類型。

1.點擊大事

用戶在系統(tǒng)內(nèi)部的每一次點擊行為，都可以記為一次點擊大事。比如按鈕的點擊、輸入框的點擊、訂單的點擊、每一條消息的點擊等，都可以成為一個點擊大事。

2.曝光大事

曝光大事簡潔來說是為了統(tǒng)計系統(tǒng)內(nèi)的特定區(qū)域是否被用戶有效掃瞄。比如工作臺，訂單中心的表格，系統(tǒng)內(nèi)的廣告位等等。

通常來說我們在衡量頁面某個區(qū)域用戶的點擊率的時候，首先需要搞清晰的就是這個區(qū)域究竟被多少用戶看到了，點擊人數(shù)除以看到了該廣告位的人數(shù)，才能計算點擊率。如何統(tǒng)計曝光大事才算合理比較簡單，這個點假如大家感愛好可以考慮再出文章細講。

3.頁面大事

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

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

掃瞄器信息：掃瞄器版本，掃瞄器語言，掃瞄器編碼，屏幕辨別率等等；訪問信息：用戶賬號，當(dāng)前頁面url，上次訪問時間，訪問時長，頁面停留時間等等；來源信息：用戶到這個頁面的來源，上一頁面url等等；物品信息：不同的業(yè)務(wù)，這部分信息會區(qū)分很大。通過了解大事的分類我們再做指標(biāo)時就不會無從下手了，舉個小例子。

我們的業(yè)務(wù)最近上新了一個新功能“消息通知”那么我需要知道這個功能上線后倒地有多少人去使用，那么我就需要獵取想消息通知icon的點擊率（點擊大事），同時我還需要知道這個消息通知列表頁面用戶一般會看幾條信息，由于業(yè)務(wù)可能會推送多條的更新信息，所以我需要頁面停留時長和掃瞄高度（曝光大事），后續(xù)我還得知道用戶是那個信息來源來到消息通知頁面的，是自主點擊“消息通知”icon進來的、還是點擊通知提示進來的（頁面大事）？

通過上面這個例子是不是就很簡單理解大事的類型呢？

五、在B端需要獵取的關(guān)鍵指標(biāo)有哪些？

與C端所需要采集的數(shù)據(jù)不同的是，B端的應(yīng)用場景主要是web端居多，B端主要采集的數(shù)據(jù)也更側(cè)重于業(yè)務(wù)數(shù)據(jù)、PVuv、點擊量、掃瞄器的類型、頁面停留時長、操作路徑等。

B端產(chǎn)品，尤其是業(yè)務(wù)系統(tǒng)，往往借助埋點觀看并討論用戶對各項產(chǎn)品功能的接受程度、使用狀況，以及用戶的操作習(xí)慣，從而進一步評估功能設(shè)計是否合理，是否幫用戶降低了使用門檻，提升了工作的效率。從這一點來說B端與C端還是有些區(qū)分的。

1.業(yè)務(wù)數(shù)據(jù)

業(yè)務(wù)數(shù)據(jù)包含用戶的基礎(chǔ)信息，比如拿一個電商零售平臺來說店鋪有幾個客服、有幾個角色；也包含用戶的交易數(shù)據(jù)，比如說訂單數(shù)量、訂單金額。

雖然這些埋點數(shù)據(jù)可以要求后臺直接導(dǎo)出，但是假如這樣每次導(dǎo)出都需要開發(fā)單獨去處理，無法獲得實時的數(shù)據(jù)也很不利于團隊氛圍營造，所以建議埋點的時候也將此部分的數(shù)據(jù)統(tǒng)計進去。

2.PV/UV

PV：頁面訪問量，每打開一次頁面PV計數(shù)+1，刷新頁面也是算是加1個訪問量的；UV：獨立訪客訪問數(shù)，一臺電腦終端為一個訪客，通常是算IP的。這是設(shè)計師必需要懂得的兩個數(shù)據(jù)之一。

3.點擊量

常用于頁面中按鈕、選擇的點擊量統(tǒng)計。比如上面的例子：近三個月訂單、全部訂單、待發(fā)貨訂單的table，是否是高頻操作，將那個放在前面，這樣排列的挨次是否合適？該數(shù)據(jù)利于細節(jié)優(yōu)化。

4.掃瞄器類型

B端業(yè)務(wù)大部分場景都是在PC端上完成，我們可以通過埋點了解用戶的掃瞄器類型、屏幕辨別率，做好適配。就像是表格表單等等相關(guān)業(yè)務(wù)控件數(shù)據(jù)字段特殊多，可能在1920px下，正好能看全，但是在720px下，會有一部分數(shù)據(jù)看不到。這時候要等比壓縮，還是做拖拉？

5.頁面有效停留時長

B端用戶在頁面的停留時長還是能說明肯定的問題。比如說我們的業(yè)務(wù)會有一個店鋪裝修的業(yè)務(wù)，這個業(yè)務(wù)通常交互都會比較簡單，通過檢測頁面的有效停留時長可以反映目前這個業(yè)務(wù)用戶在使用上是否存在難點，針對性去優(yōu)化該部分的用戶的體驗；

6.操作路徑

操作路徑就是跟著業(yè)務(wù)流程，來監(jiān)控用戶的操作行為。比如說我們業(yè)務(wù)上其中一部分流程是這樣的：

但當(dāng)時有另一個方案流程是這樣的：

我們可以總結(jié)出最常用的流程，來優(yōu)化使用的路徑。但操作路徑的埋點，工作量特別大，所以需要在埋點的設(shè)計上思索好關(guān)鍵的數(shù)據(jù)指標(biāo)。

六、實操：一個埋點需求從開頭到落地

上面已知我們要對批量發(fā)貨、批量標(biāo)記、批量免運費進行監(jiān)測，由于我們不能自己去進行埋點，或者你也可以將這個需求告知給產(chǎn)品經(jīng)理讓他幫你出這一份文檔。但是我覺得假如設(shè)計能寫出來給到開發(fā)而且能直接跟開發(fā)溝通是一件很酷的事情，不妨學(xué)習(xí)寫一下文檔。

1.整理埋點需求并輸出文檔

此處可以看到，一份規(guī)范的埋點文檔會包括：大事名稱、大事屬性、數(shù)據(jù)類型、屬性說明、埋點形式、觸發(fā)時機等，只有將埋點文檔梳理規(guī)范了，前端小哥才不會和你打架哦。

2.埋點代碼的植入

不同于攝像頭，數(shù)據(jù)的采集工具通常為埋點代碼，不用的產(chǎn)品形態(tài)實行不同的埋點代碼植入，通常有三種：js文件、SDK、http懇求，詳細對應(yīng)的是M端，網(wǎng)頁端和服務(wù)器。這塊通常是研發(fā)來做，產(chǎn)品經(jīng)理和設(shè)計在旁邊加油打氣就行了。

在研發(fā)完成埋點注冊后，研發(fā)就開頭Coding了，通常研發(fā)都會采納第三方公司的SDK（可以理解成代碼包）這樣可以節(jié)約大量的工作量，當(dāng)然假如公司自研SDK期可擴展性會高許多，可以實現(xiàn)全埋點可視化埋點的采集方式，當(dāng)然這樣成本也會高。

現(xiàn)有市面上主流SDK數(shù)據(jù)分析公司的埋點方式比較：

3.埋點測試與校驗

這一部分的內(nèi)容通常是由測試同學(xué)來完成的，測試同學(xué)通過測試這些埋點數(shù)據(jù)，通過后才可以部署上線，此處粗略講講他們需要測些啥：

測試埋點數(shù)據(jù)是否正常報出；在數(shù)據(jù)庫里面能不能檢測到埋點數(shù)據(jù)；大事和對應(yīng)屬性是否能對的上。當(dāng)他們將這些點驗收完成，研發(fā)人員部署上線，就可以等著收數(shù)據(jù)了。

4.線上數(shù)據(jù)追蹤

埋點上線后，假如采納的是第三方的SDK公司都會供應(yīng)對應(yīng)的數(shù)據(jù)可視化產(chǎn)品用于數(shù)據(jù)展現(xiàn)，當(dāng)然假如自研SDK并沒有做數(shù)據(jù)可視化產(chǎn)品也可以直接叫后臺同學(xué)提取SQL提數(shù)，當(dāng)然這對設(shè)計師和產(chǎn)品經(jīng)理就很不友好了。

5.如何利用好數(shù)據(jù)

1）同一版本只驗證一個設(shè)計點

有時候我們需要驗證某個數(shù)據(jù)時，需要考慮到是否會有其他的改動點影響到當(dāng)前的數(shù)據(jù)，比如上面我們在討論批量發(fā)貨、批量標(biāo)記、批量免運費三個table的使用狀況，而恰巧這個時候開發(fā)小哥說要不要做一個用戶可以自定義拖拽table的功能，這樣做起來很便利。但是假如這兩個優(yōu)化點同時上線，我們就無法知道這3個Table點擊率結(jié)果是哪個優(yōu)化點所帶來的效果了.

因此我們可以將自由拖拽table放在下一個版本中，避開數(shù)據(jù)是由多種緣由