編輯導(dǎo)語(yǔ)：數(shù)據(jù)埋點(diǎn)，就是傳統(tǒng)的數(shù)據(jù)打點(diǎn)，在網(wǎng)站或者APP中加入一些統(tǒng)計(jì)代碼進(jìn)行數(shù)據(jù)采集。埋點(diǎn)的價(jià)值以及正確埋點(diǎn)的重要性，基本上所有的產(chǎn)品或者數(shù)據(jù)人員都得需要了解。在本篇文章中，作者為我們分享了應(yīng)該如何建立埋點(diǎn)規(guī)范。

《數(shù)據(jù)埋點(diǎn)，一次講個(gè)夠》系列文章的第三篇，討論埋點(diǎn)業(yè)務(wù)的流程規(guī)范，主要討論：

1. ?埋點(diǎn)業(yè)務(wù)過(guò)程中涉及的角色及其職責(zé)；
2. 一條完整的埋點(diǎn) workflow 長(zhǎng)什么樣子？

一、角色與職責(zé)

一個(gè)完整的埋點(diǎn)業(yè)務(wù)流程會(huì)涉及業(yè)務(wù)方、埋點(diǎn)研發(fā)測(cè)試團(tuán)隊(duì)、數(shù)據(jù)團(tuán)隊(duì)：

• 業(yè)務(wù)方：產(chǎn)生埋點(diǎn)需求，通常是業(yè)務(wù)線的營(yíng)運(yùn)人員、產(chǎn)品經(jīng)理、數(shù)據(jù)分析師，他們根據(jù)業(yè)務(wù)，提埋點(diǎn)需求，埋點(diǎn)完成之后做數(shù)據(jù)分析，他們主要的工作是輸入原始需求、埋點(diǎn)上線后消費(fèi)數(shù)據(jù)。
• 埋點(diǎn)研發(fā)測(cè)試團(tuán)隊(duì)：負(fù)責(zé)埋點(diǎn)開(kāi)發(fā)、測(cè)試、上線。
• 數(shù)據(jù)團(tuán)隊(duì)：負(fù)責(zé)定義埋點(diǎn)模型，接收埋點(diǎn)數(shù)據(jù)上報(bào)，存儲(chǔ)數(shù)據(jù)、處理數(shù)據(jù)、展示數(shù)據(jù)。

不難看出，一個(gè)具體的埋點(diǎn)業(yè)務(wù)參與的各方需要大量協(xié)同配合。企業(yè)應(yīng)該有一個(gè)與埋點(diǎn)業(yè)務(wù)流相對(duì)應(yīng)的組織架構(gòu)，來(lái)保證埋點(diǎn)采集的質(zhì)量和效率。根據(jù)多年的埋點(diǎn)工作經(jīng)驗(yàn)，有三個(gè)角色對(duì)埋點(diǎn)工作的開(kāi)展有非常關(guān)鍵的作用。

1. 需要設(shè)置一個(gè)角色來(lái)統(tǒng)一規(guī)劃整體的埋點(diǎn)工作，負(fù)責(zé)組織協(xié)同各個(gè)業(yè)務(wù)線，制定埋點(diǎn)流程和規(guī)范，并推廣規(guī)范的落地與執(zhí)行，確保各業(yè)務(wù)線的數(shù)據(jù)接入符合規(guī)范，保障數(shù)據(jù)質(zhì)量，我所在的團(tuán)隊(duì)由數(shù)據(jù)產(chǎn)品經(jīng)理來(lái)負(fù)責(zé)。
2. 對(duì)于公司具體業(yè)務(wù)線的埋點(diǎn)，需要有一個(gè)業(yè)務(wù)負(fù)責(zé)人，負(fù)責(zé)該業(yè)務(wù)線的埋點(diǎn)需求梳理、埋點(diǎn)設(shè)計(jì)、數(shù)據(jù)上線應(yīng)用推廣、日常使用支持和培訓(xùn)，這個(gè)角色，一般由業(yè)務(wù)線的數(shù)分、有數(shù)據(jù) sense 的產(chǎn)品、或者有業(yè)務(wù) sense 的研發(fā)擔(dān)任。
3. 關(guān)鍵的角色是具體業(yè)務(wù)線的埋點(diǎn)技術(shù)負(fù)責(zé)人，一般來(lái)說(shuō)每條業(yè)務(wù)線會(huì)有多種客戶端的產(chǎn)品，埋點(diǎn)的開(kāi)發(fā)可能會(huì)涉及 Android 端、iOS 端、微信小程序端、服務(wù)端，需要有一個(gè)技術(shù)接口人統(tǒng)籌埋點(diǎn)的開(kāi)發(fā)工作，這個(gè)角色可以由前端開(kāi)發(fā)負(fù)責(zé)人擔(dān)任。

二、埋點(diǎn)業(yè)務(wù)流程

上面這張流程圖貫穿了埋點(diǎn)的全過(guò)程，將上面提到的多種不同的角色串聯(lián)協(xié)同起來(lái)，保證埋點(diǎn)采集的高質(zhì)量、高效率，主要環(huán)節(jié)如下：

• 埋點(diǎn)需求提交：該環(huán)節(jié)由業(yè)務(wù)線需求方發(fā)起。通常是業(yè)務(wù)線的營(yíng)運(yùn)、產(chǎn)品、推廣，或者是數(shù)分，他們根據(jù)業(yè)務(wù)數(shù)據(jù)分析需要，提出埋點(diǎn)需求。業(yè)務(wù)方需要發(fā)出正式的需求郵件給埋點(diǎn)研發(fā)測(cè)試團(tuán)隊(duì)、數(shù)據(jù)團(tuán)隊(duì)。
• 需求評(píng)審：埋點(diǎn)需求評(píng)審由數(shù)據(jù)團(tuán)隊(duì)主導(dǎo)，埋點(diǎn)研發(fā)測(cè)試團(tuán)隊(duì)參與，業(yè)務(wù)方確認(rèn)。數(shù)據(jù)團(tuán)隊(duì)根據(jù)業(yè)務(wù)方需求進(jìn)行埋點(diǎn)方案設(shè)計(jì)，輸出 DRD，組織需求評(píng)審。在需求評(píng)審會(huì)上，埋點(diǎn)研發(fā)測(cè)試團(tuán)隊(duì)確認(rèn)需求可行性，業(yè)務(wù)方確認(rèn)事件設(shè)計(jì)方案符合業(yè)務(wù)需求。如一次評(píng)審沒(méi)有達(dá)成一致，將多次組織需求 review，直到三個(gè)團(tuán)隊(duì)達(dá)成一致。
• 埋點(diǎn)開(kāi)發(fā)：在埋點(diǎn)開(kāi)發(fā)之前，業(yè)務(wù)方需要在線注冊(cè)埋點(diǎn)信息，信息的內(nèi)容須和最終評(píng)審?fù)ㄟ^(guò)的 DRD 保持一致。埋點(diǎn)研發(fā)團(tuán)隊(duì)必須以線上注冊(cè)的埋點(diǎn)信息為準(zhǔn)進(jìn)行埋點(diǎn)開(kāi)發(fā)。
• 埋點(diǎn)測(cè)試&驗(yàn)收&部署上線：埋點(diǎn)數(shù)據(jù)測(cè)試由測(cè)試人員完成，測(cè)試完成后由數(shù)據(jù)團(tuán)隊(duì)、業(yè)務(wù) 方驗(yàn)收后，由研發(fā)人員部署上線。
• 埋點(diǎn)應(yīng)用（數(shù)據(jù)分析）：埋點(diǎn)上線后，業(yè)務(wù)方可通過(guò)數(shù)據(jù)提取、用戶行為分析平臺(tái)、用戶畫(huà)像標(biāo)簽系統(tǒng)等方式消費(fèi)埋點(diǎn)數(shù)據(jù)。

理想的情況下，一個(gè)埋點(diǎn)上線要經(jīng)歷上述五個(gè)步驟。

而在實(shí)際中，很多團(tuán)隊(duì)在處理埋點(diǎn)業(yè)務(wù)時(shí)沒(méi)有形成內(nèi)部的流程規(guī)范，帶來(lái)的后果是埋點(diǎn)數(shù)據(jù)質(zhì)量差，數(shù)據(jù)的價(jià)值難以發(fā)揮。

比如：要統(tǒng)計(jì)某個(gè)行為的觸發(fā)人數(shù)時(shí)發(fā)現(xiàn)沒(méi)有埋點(diǎn)，數(shù)分在提取數(shù)據(jù)時(shí)發(fā)現(xiàn)有很多相似的字段不知道該用哪個(gè)，研發(fā)說(shuō)某個(gè)埋點(diǎn)已經(jīng)上線了可數(shù)據(jù)庫(kù)里怎么也查不到數(shù)據(jù)，某個(gè)埋點(diǎn)起初上線的時(shí)候是正常的但從某個(gè)時(shí)候開(kāi)始就沒(méi)有數(shù)據(jù)上報(bào)了。

要解決這些問(wèn)題，需要把埋點(diǎn)當(dāng)做一條獨(dú)立的研發(fā)任務(wù)來(lái)看待，而不是產(chǎn)品開(kāi)發(fā)過(guò)程中順便做一下的任務(wù)。

還有一點(diǎn)需要強(qiáng)調(diào)的是，流程的制定是很簡(jiǎn)單的，畫(huà)一個(gè)圖，發(fā)一個(gè)文，但如果流程規(guī)范只是流于形式，無(wú)法真正的落到實(shí)際的環(huán)節(jié)中去，一切努力也只是白費(fèi)。

因此，我們還需要進(jìn)一步對(duì)流程規(guī)范中每一個(gè)環(huán)節(jié)的輸入輸出做更詳細(xì)的要求。

1. 埋點(diǎn)需求提交

1）提需求并不容易

埋點(diǎn)需求通常是業(yè)務(wù)方的營(yíng)運(yùn)人員、產(chǎn)品經(jīng)理、數(shù)據(jù)分析師根據(jù)業(yè)務(wù)數(shù)據(jù)分析需要， 提出埋點(diǎn)需求。提需求并不是一件顯而易見(jiàn)的事情，也需要學(xué)習(xí)。

Thea 之前所在的團(tuán)隊(duì)，在埋點(diǎn)需求提交環(huán)節(jié)，只要求業(yè)務(wù)方描述清楚要在哪些維度下看哪些指標(biāo)，數(shù)分會(huì)梳理指標(biāo)、維度完成埋點(diǎn)設(shè)計(jì)。

這樣的流程對(duì)提需求的業(yè)務(wù)人員來(lái)說(shuō)是非常友好的，他們不需要去說(shuō)明為什么要看這個(gè)指標(biāo)、在這些維度下分析指標(biāo)對(duì)業(yè)務(wù)的價(jià)值，甚至在很多時(shí)候業(yè)務(wù)人員并不清楚業(yè)務(wù)路徑的全貌，他們只關(guān)注路徑上的某個(gè)環(huán)節(jié)上的指標(biāo)，提上來(lái)的需求都是「局部的」、「臨時(shí)的」、「一次性」的。

基于這樣的需求設(shè)計(jì)出來(lái)的埋點(diǎn)也同樣是「局部的」「臨時(shí)的」「一次性」的，后續(xù)隨著業(yè)務(wù)路徑的調(diào)整，哪怕是小小的微調(diào)，也會(huì)導(dǎo)致埋點(diǎn)不可用要重新設(shè)計(jì)。

比較抽象，來(lái)一個(gè)具體的例子，用戶在社區(qū)中發(fā)帖子。

當(dāng)前，用戶在社區(qū)中發(fā)帖子有兩個(gè)入口，入口 A、入口 B，點(diǎn)擊發(fā)送帖子后，會(huì)進(jìn)入編輯帖子的內(nèi)容頁(yè)面，內(nèi)容頁(yè)面編輯好之后，點(diǎn)擊發(fā)布就可以發(fā)布帖子。

業(yè)務(wù)方希望分析發(fā)帖子的漏斗，但由于業(yè)務(wù)方只知道入口 A，不知道入口 B 的存在，于是提出的漏斗是：點(diǎn)擊入口 A 的用戶數(shù) > 進(jìn)入編輯頁(yè)面的用戶數(shù) > 點(diǎn)擊發(fā)布并成功發(fā)布帖子的用戶數(shù)。

基于此數(shù)分設(shè)計(jì)了兩個(gè)事件「進(jìn)入編輯帖子頁(yè)」、「發(fā)布帖子」兩個(gè)事件（因?yàn)閿?shù)分認(rèn)為編輯帖子頁(yè)面只有唯一入口 A，基本上點(diǎn)擊 入口 A 的人數(shù) = 訪問(wèn)帖子編輯頁(yè)面的人數(shù)）。

在埋點(diǎn)上線后的某一天，業(yè)務(wù)方說(shuō)埋點(diǎn)數(shù)據(jù)有問(wèn)題，來(lái)找數(shù)分核對(duì)數(shù)據(jù)，發(fā)生了如下對(duì)話。

• 業(yè)務(wù)方：「發(fā)布帖子的埋點(diǎn)數(shù)據(jù)有問(wèn)題?！?/li>
• 數(shù)分：「什么問(wèn)題？看起來(lái)沒(méi)毛病啊，昨天有 10000 個(gè)人進(jìn)入了編輯帖子的頁(yè)面，有 5000 個(gè)人成功發(fā)布了帖子?！?/li>
• 業(yè)務(wù)方：「可以入口 A 所在的頁(yè)面一的瀏覽人數(shù)只有 2000 人，怎么可能有 10000 多人點(diǎn)了入口 A 呢？這不符合邏輯，是埋點(diǎn)上報(bào)出錯(cuò)了吧？」
• 數(shù)分：「怎么可能？我來(lái)看看入口 A 頁(yè)面一的訪問(wèn)人數(shù)。」

…

• 數(shù)分：「這不科學(xué)啊，難道發(fā)布帖子的入口不止 A？」
• 業(yè)務(wù)方：「我了解到的，只有入口 A。」
• 數(shù)分：「那我們?nèi)フ疑鐓^(qū)的產(chǎn)品經(jīng)理溝通確認(rèn)下?！?/li>

…

• 數(shù)分：「果然，還有一個(gè)入口 B 也能發(fā)布帖子。這樣就清楚了，這是合理的，埋點(diǎn)數(shù)據(jù)上報(bào)沒(méi)有問(wèn)題?！?/li>
• 業(yè)務(wù)方：「好吧，如果是這樣的話，我希望能夠區(qū)分通過(guò)不同入口發(fā)布帖子的用戶數(shù)?！?/li>
• 數(shù)分：「額，你之前提需求的時(shí)候也沒(méi)說(shuō)，當(dāng)前的埋點(diǎn)做不到，要區(qū)分的話，只有加埋點(diǎn)字段，要等下個(gè)版本才能上線，并且只有在新版本中才能區(qū)分。」
• 業(yè)務(wù)方：「好吧，也只能這樣了。」
• 數(shù)分：「你看一下，新的埋點(diǎn)字段，沒(méi)問(wèn)題的話研發(fā)就這樣開(kāi)發(fā)了。」

這是數(shù)據(jù)團(tuán)隊(duì)和業(yè)務(wù)團(tuán)隊(duì)之間時(shí)常出現(xiàn)的場(chǎng)景。究其原因是掌握更多業(yè)務(wù)知識(shí)的業(yè)務(wù)方?jīng)]有向數(shù)分提供完整的信息（當(dāng)然數(shù)據(jù)分析也沒(méi)有進(jìn)一步詢問(wèn)，業(yè)務(wù)怎么說(shuō)怎么做），數(shù)據(jù)分析設(shè)計(jì)的埋點(diǎn)沒(méi)有覆蓋完整的流程，導(dǎo)致埋點(diǎn)不可用。

為了避免這樣的問(wèn)題發(fā)生，在埋點(diǎn)需求提交階段，要求業(yè)務(wù)方對(duì)業(yè)務(wù)流程給出詳細(xì)的說(shuō)明，包括業(yè)務(wù)功能要引導(dǎo)用戶達(dá)成什么目標(biāo)，業(yè)務(wù)完成的路徑如何，最好能提供用戶體驗(yàn)地圖。

總之，要求業(yè)務(wù)方自己先能把業(yè)務(wù)路徑梳理清楚，提供盡可能多的業(yè)務(wù)背景。

2）提交需求

我們要求業(yè)務(wù)?發(fā)正式的需求郵件，下面的截圖是我們團(tuán)隊(duì)在用的模板。

模板要求的信息和業(yè)務(wù)方要做的業(yè)務(wù)梳理是高度相關(guān)的，業(yè)務(wù)方須嚴(yán)格按照線下郵件流程進(jìn)?提交，在郵件中說(shuō)明要埋點(diǎn)的產(chǎn)品、端的類型、所屬業(yè)務(wù)、業(yè)務(wù)路徑、統(tǒng)計(jì)指標(biāo)、維度、期望上線日期等信息。

收到郵件后，數(shù)據(jù)團(tuán)隊(duì)在兩個(gè)工作日內(nèi)對(duì)接業(yè)務(wù)方溝通需求細(xì)節(jié)。

2. 需求評(píng)審

需求評(píng)審環(huán)節(jié)由數(shù)據(jù)團(tuán)隊(duì)主導(dǎo)，通常是負(fù)責(zé)該條業(yè)務(wù)線的數(shù)據(jù)分析師。又分為三步：一是設(shè)計(jì)埋點(diǎn)，二是組織埋點(diǎn)需求評(píng)審會(huì)議，三是埋點(diǎn)注冊(cè)。

1）埋點(diǎn)設(shè)計(jì)

數(shù)分在收到埋點(diǎn)需求郵件之后，仔細(xì)閱讀需求，找業(yè)務(wù)?溝通需求細(xì)節(jié)，基于業(yè)務(wù)路徑設(shè)計(jì)埋點(diǎn)，盡量做到對(duì)業(yè)務(wù)流程全面覆蓋。

埋點(diǎn)設(shè)計(jì)的結(jié)果是輸出埋點(diǎn) DRD，關(guān)于如何設(shè)計(jì)埋點(diǎn)，在系列上一篇文章中已經(jīng)有很多描述，請(qǐng)點(diǎn)擊閱讀。

2）埋點(diǎn)需求評(píng)審

數(shù)分組織埋點(diǎn)研發(fā)測(cè)試團(tuán)隊(duì)、業(yè)務(wù)方進(jìn)行埋點(diǎn)需求評(píng)審，評(píng)審需要確認(rèn)以下要點(diǎn)：

1. 埋點(diǎn)研發(fā)測(cè)試團(tuán)隊(duì)確認(rèn)需求可行性
2. 業(yè)務(wù)方確認(rèn)埋點(diǎn)設(shè)計(jì)方案符合業(yè)務(wù)需求

如一次評(píng)審沒(méi)有達(dá)成一致，將多次組織需求 review，直到三個(gè)團(tuán)隊(duì)達(dá)成一致。需求評(píng)審?fù)瓿芍?，后續(xù)的開(kāi)發(fā)埋點(diǎn)嚴(yán)格按照文檔進(jìn)?，如有需求調(diào)整需要通過(guò)數(shù)分變更，并由數(shù)分通知相關(guān)方。

3）注冊(cè)埋點(diǎn)

埋點(diǎn)注冊(cè)要做的是將埋點(diǎn) DRD 中的信息錄入到線上的系統(tǒng)，這么做的目的和埋點(diǎn)管理有關(guān)，整個(gè)埋點(diǎn)生命周期：新增、回?cái)?shù)、迭代、下線都在線管理，這樣可以保證埋點(diǎn)不會(huì)越用越亂。

這塊的內(nèi)容會(huì)在下一篇再來(lái)討論，這里先不展開(kāi)。

3. 埋點(diǎn)開(kāi)發(fā)

完成埋點(diǎn)注冊(cè)之后，研發(fā)就可以開(kāi)始 coding 了。研發(fā)團(tuán)隊(duì)可以自研埋點(diǎn) SDK，自己實(shí)現(xiàn)全埋點(diǎn)、代碼埋點(diǎn)、可視化埋點(diǎn)這些采集方式，也可以采用開(kāi)源的埋點(diǎn)SDK，這樣可以節(jié)省很大的工作量。

下面的表格是比較了市面上主流用戶行為數(shù)據(jù)分析公司的埋點(diǎn)方式。

可以看出，如果想要節(jié)省開(kāi)發(fā)人力選擇一款開(kāi)源的埋點(diǎn) SDK，神策埋點(diǎn)幾乎可以說(shuō)是唯一的選擇。

但這個(gè)唯一的選擇也是相當(dāng)不錯(cuò)的，神策埋點(diǎn)采用的是事件模型，SDK 支持的端非常全面，支持前端、后端、服務(wù)端埋點(diǎn)，還支持?jǐn)?shù)據(jù)庫(kù)數(shù)據(jù)導(dǎo)入，Thea 目前就職的公司就采用了神策埋點(diǎn) SDK。

4. 埋點(diǎn)測(cè)試&驗(yàn)收&上線

埋點(diǎn)數(shù)據(jù)測(cè)試由測(cè)試人員完成，測(cè)試通過(guò)后由研發(fā)部署上線，上線之后業(yè)務(wù)方應(yīng)對(duì)埋點(diǎn)數(shù)據(jù)進(jìn)行驗(yàn)收。這里的重點(diǎn)工作是測(cè)試埋點(diǎn)，埋點(diǎn)驗(yàn)證需要完成以下任務(wù)：

• 校驗(yàn)觸發(fā)時(shí)機(jī)下前端/服務(wù)端埋點(diǎn)數(shù)據(jù)是否正常報(bào)出
• 校驗(yàn)數(shù)據(jù)庫(kù)里是否收到上報(bào)的埋點(diǎn)數(shù)據(jù)
• 對(duì)事件和屬性的完整性及數(shù)據(jù)類型進(jìn)?校驗(yàn)

埋點(diǎn)的測(cè)試需要覆蓋主流機(jī)型，驗(yàn)收完成后，由測(cè)試?員發(fā)測(cè)試報(bào)告，研發(fā)人員部署上線。

5. 埋點(diǎn)應(yīng)用（數(shù)據(jù)分析）

最后一個(gè)步驟，基于埋點(diǎn)數(shù)據(jù)做數(shù)據(jù)分析，需要有一個(gè)前端的分析工具支持，這里要展開(kāi)的話會(huì)是龐大的篇幅，以后有機(jī)會(huì)我們?cè)賮?lái)討論用戶行為分析工具。

這是《數(shù)據(jù)埋點(diǎn)，一次講個(gè)夠》系列文章的第三篇，這一系列的文章會(huì)和大家系統(tǒng)地分享我對(duì)埋點(diǎn)體系建設(shè)的實(shí)踐與思考，討論問(wèn)題：

• 如何讓業(yè)務(wù)線的產(chǎn)品/運(yùn)營(yíng)更高效地提埋點(diǎn)需求？
• 如何更快的響應(yīng)業(yè)務(wù)需求，輸出 DRD？
• 如何設(shè)計(jì)更簡(jiǎn)潔、更靈活、拓展性更強(qiáng)的埋點(diǎn)模型？
• 如何協(xié)調(diào)好參與埋點(diǎn)工作的各方，快速產(chǎn)出高質(zhì)量的埋點(diǎn)？
• 如何有效地管理成千上萬(wàn)個(gè)已線上、未上線、需要下線的埋點(diǎn)？

Thea，微信公眾號(hào)：Thea的若干好奇；從事大數(shù)據(jù)產(chǎn)品工作六年，設(shè)計(jì)、管理埋點(diǎn)已有三年，在大廠做過(guò)商業(yè)化大數(shù)據(jù)產(chǎn)品，也在幾十億美金估值的創(chuàng)業(yè)公司參與過(guò)數(shù)據(jù)中臺(tái)的建設(shè)。

經(jīng)手過(guò)上萬(wàn)個(gè)埋點(diǎn)，經(jīng)歷過(guò)從 0 到 1 自建埋點(diǎn)體系，也使用過(guò)第三方的埋點(diǎn)服務(wù)。喜歡研究各種產(chǎn)品，不止限于數(shù)據(jù)產(chǎn)品相關(guān)的。相信優(yōu)雅的工具有很大的能量，可以減少工作和生活的摩擦。

本文由@Thea 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議。