一個埋點的上線，一般可以分成需求階段、埋點需求評審 / 埋點開發(fā)、灰度測試、正式上線這四個階段，在這些環(huán)節(jié)中，數(shù)據(jù)分析師的重要價值和工作內(nèi)容是怎么樣的呢？本文作者對此作出了分析，一起來看一下吧。

昨天面試了一個偏數(shù)據(jù)基建和治理的分析崗位，結(jié)合昨天的面試問題，對埋點全流程中，數(shù)據(jù)分析師的角色定位和主要做的事情做一個梳理，也對上個階段關(guān)于這部分的工作內(nèi)容淺做一個總結(jié)~

順便也對市面上擁有較成熟的埋點平臺的大廠的公開資料做了了解。這個系列估計還可以有很多延伸，比如埋點的設(shè)計規(guī)范和把控，成熟的埋點平臺可以解決那些問題……

當(dāng)然每個公司人員分工會有細(xì)節(jié)上的不同，但是初心一定是提升埋點質(zhì)量，更好的沉淀數(shù)據(jù)資產(chǎn)。

首先來看一下一個埋點上線全流程及涉及的具體人員，我們可以看到一個埋點的上線通常可以分成四個階段：需求階段 → 埋點需求評審 / 埋點開發(fā) → 灰度測試 → 正式上線。

接下來我們來看看各個環(huán)節(jié)數(shù)據(jù)分析師的主要價值和工作內(nèi)容是怎么樣的。

一、需求階段

這個階段通常會有兩種場景，一種是業(yè)務(wù)方/分析師自身需要統(tǒng)計某種數(shù)據(jù)于是找到分析師，分析師首先要判斷現(xiàn)有埋點是否能支持該需求，如不能且判斷需求價值高，可由分析師發(fā)起新埋點需求，或者對舊埋點做增補。

第二類則是伴隨產(chǎn)品功能迭代/新功能上線，也是實際工作場景中更為常見的一種。通常功能產(chǎn)品經(jīng)理需要預(yù)先產(chǎn)出PRD和原型圖，做出初版的DRD（數(shù)據(jù)需求文檔）。

因為每個人的埋點習(xí)慣不同，單單由功能產(chǎn)品負(fù)責(zé)這一環(huán)可能會出現(xiàn)漏埋錯埋，或者對歷史埋點不了解重復(fù)造輪子等現(xiàn)象，所以需要與數(shù)據(jù)產(chǎn)品進(jìn)行一輪溝通，由數(shù)據(jù)產(chǎn)品來把控埋點是否可以和歷史埋點做兼容。

對于較為重要影響面較廣的項目，數(shù)據(jù)分析同學(xué)也需要在這一環(huán)節(jié)提前參與進(jìn)來，作為分析師，首先需要明確現(xiàn)階段埋點要統(tǒng)計的有哪些指標(biāo)（尤其是確保功能的目標(biāo)提升指標(biāo)可以被統(tǒng)計到），其次要對未來有哪些數(shù)據(jù)分析需求預(yù)判，哪怕現(xiàn)在不需要，未來規(guī)劃中有需要的也要保留下來。

舉個栗子，比如某次某業(yè)務(wù)首頁做改版，用戶首次進(jìn)入該業(yè)務(wù)需要選擇內(nèi)容偏好標(biāo)簽，后續(xù)分析首頁改版時分析師可能暫時不會對用戶的標(biāo)簽做細(xì)節(jié)分析，而主要更關(guān)注首頁改版對用戶行為（比如內(nèi)容滲透率，留存率）是否有正向影響，但是這類選擇信息可以為算法同學(xué)后續(xù)統(tǒng)計用戶內(nèi)容偏好提供一定信息，所以設(shè)計埋點時就需要統(tǒng)計到。

埋點設(shè)計過程中，我的習(xí)慣是先做加法，再做減法。首先力求能簡潔完整的概括用戶行為，對于后續(xù)分析不大可能涉及的屬性要敢于「斷舍離」。

數(shù)據(jù)分析師判斷埋點可以滿足業(yè)務(wù)需求，數(shù)據(jù)產(chǎn)品判斷埋點可以被很好的吸納到現(xiàn)有的埋點體系，功能產(chǎn)品回去「改作業(yè)」后二次確認(rèn)，就可以進(jìn)入需求評審環(huán)節(jié)了。

這一環(huán)，有兩個細(xì)節(jié)需要數(shù)據(jù)產(chǎn)品&分析師格外注意。

1. 埋點易用性

此外，埋點設(shè)計除了考慮到自身使用的易用性，也要盡量考慮到業(yè)務(wù)方的易用性，所以分析師除了要熟練使用代碼語言查詢數(shù)據(jù)，也要盡可能讓埋點在數(shù)據(jù)工具（前司為例，使用神策）上更好用。

這也要求數(shù)據(jù)分析師對數(shù)據(jù)工具有比業(yè)務(wù)方更深的了解，不要只依賴一種方法解決問題，這樣做有兩點好處：

1）可以對業(yè)務(wù)方能否自身處理需求有更好的判斷，不然人說不能做 / 做起來效率低，你對這工具自己都用不利落，怎么判斷到底能不能做呢。

2）不斷幫助業(yè)務(wù)方提升自己使用數(shù)據(jù)工具解決問題的能力，確定好兩者邊界，才能騰出手來做更多只有分析師可以做到的事情。

舉個簡單的例子，一個運營活動主會場需要更換n輪，每個主會場都要求開發(fā)單獨開發(fā)，這時候有兩種方案：

1）每個會場的瀏覽和點擊都采用單獨的埋點事件，比如：活動a_瀏覽，活動b_瀏覽。

2）使用兩個公用事件，在事件屬性中去做細(xì)分，比如：活動_瀏覽，屬性增加活動名稱，限制a/b。

這時候需求來了，運營想知道有多少用戶是兩場活動都有參與的。代碼層面，兩種埋點設(shè)計都可以很容易的解決問題。但是如果在數(shù)據(jù)工具中需要對兩個事件取交集就相對比較麻煩了，當(dāng)然用虛擬事件也可以解決問題，代價是每增加一個會場就得維護虛擬事件，靈活性很差。這時候用屬性去限制活動的好處就凸顯出來了。

2. 評估多方業(yè)務(wù)訴求

作為數(shù)據(jù)分析，我們要了解不同的業(yè)務(wù)方訴求。比如產(chǎn)品需要考量功能本身的使用情況和漏斗轉(zhuǎn)化效率，用戶運營同學(xué)會考量功能上線對用戶的后續(xù)影響，比如對用戶的后續(xù)留存是否有幫助，開發(fā)需要對產(chǎn)品性能和體驗做評估，比如會考慮埋點：應(yīng)用響應(yīng)時長，應(yīng)用崩潰率。

作為分析師，需要對各方訴求逐一了解并完成整合。

二、需求評審 & 開發(fā)階段

這一環(huán)，數(shù)據(jù)分析師可以先干點兒別的，需要咱們處理的不多。功能產(chǎn)品需要在需求評審給開發(fā)講解PRD和埋點需求，對于「能埋不能埋」/「需要換方案」的情況也做一輪反饋。

如果開發(fā)提出不能埋的埋點對業(yè)務(wù)很重要，數(shù)據(jù)分析也需要介入進(jìn)來，說明該埋點對于業(yè)務(wù)的關(guān)鍵性，推進(jìn)工作順利進(jìn)行。對于比較重要的功能改版，也可以考慮在需求評審階段就介入，協(xié)助產(chǎn)品經(jīng)理一起解答開發(fā)伙伴對于一些埋點的疑問。

三、埋點測試階段

等到開發(fā)自測完成，埋點就進(jìn)入灰度測試階段。通常開發(fā)會進(jìn)行一輪自測，而后交給測試小伙伴做測試。但因為目前一些測試的習(xí)慣還是以功能測試為主，對于比較重要的功能/項目，數(shù)據(jù)分析師也可以主動加入灰度測試。

不同公司在不同業(yè)務(wù)發(fā)展階段有不同的測試方式，這里援引迪普老師的總結(jié)圖如下：

而作為神策用戶，我們通常是在測試環(huán)境里直接在app里手動模擬真實用戶行為，去看用戶實時日志情況。通常我們需要做以下信息的驗收：

1）驗收用戶標(biāo)識在一系列事件中是否連貫過往我們就曾有用戶進(jìn)入某h5頁面其用戶標(biāo)識失效的情況。

2）驗收事件是否重復(fù)上報 / 漏報

3）驗收事件觸發(fā)時間 / 上報時機 / 上報順序是否正確主要是為了保障漏斗分析的可用性，本來用戶是進(jìn)了商品詳情頁才購買，你愣是先報購買才報進(jìn)商品詳情頁，這漏斗可就歇菜了。

4）驗收是否所有屬性都有上報

驗收上報的屬性是否符合預(yù)期，主要包括以下幾點：

• 內(nèi)容是否符合預(yù)期
• 字段格式是否符合預(yù)期
• 是否有空值

而后對上報有誤的信息做反饋。這個環(huán)節(jié)對于數(shù)據(jù)分析師來說往往是很折磨人的，既害怕驗不出問題（萬一沒驗出問題，上線才發(fā)現(xiàn)問題修改周期長），又害怕驗出問題（要反饋開發(fā)小伙伴修改，改完還得重驗）。

等到各方確定功能/埋點都沒問題了，產(chǎn)品順利發(fā)版。嚴(yán)謹(jǐn)一點的話，測試完成后最好設(shè)計一定的測試用戶白名單機制，在日志層面對測試用戶的信息做清除。

四、上線階段

發(fā)版以后是否就萬事大吉了呢？測試環(huán)境畢竟咱們只有有限的設(shè)備，對用戶變化多端的設(shè)備/網(wǎng)絡(luò)/以及其他復(fù)雜場景缺少預(yù)判，所以實際上線以后我們還要繼續(xù)緊盯數(shù)據(jù)，不可懈怠。

主要的監(jiān)控方向和灰度環(huán)節(jié)的驗收一致，但是會站在數(shù)據(jù)分析的視角來看，出現(xiàn)問題再去詳查具體數(shù)據(jù)，監(jiān)控的主要粒度和方式如下：

平臺（安卓，IOS等）：首先對平臺做拆分是因為很多場景下安卓/IOS的開發(fā)是由不同團隊負(fù)責(zé)的，發(fā)現(xiàn)問題便于反饋；此外，雖然兩端用戶行為有一定差異，但一端出問題另一端完好的情況下，也可以互為對比參考。

搭建漏斗檢驗關(guān)鍵流程是否順暢，對比漏斗各環(huán)數(shù)據(jù)情況和獨立事件實際觸發(fā)情況：這是作為數(shù)據(jù)分析師的主要武器，不但可以對事件的上報順序和時間做一輪驗證，也可以對用戶標(biāo)識是否連貫做驗證，同時也檢驗事件是否出現(xiàn)多報 / 少報。

舉個例子，一個通用的業(yè)務(wù)場景是，業(yè)務(wù)同學(xué)常常反饋「某事件作為獨立事件觸發(fā)數(shù)遠(yuǎn)高于在漏斗中的觸發(fā)數(shù)」，排除對起點事件的入口的窮舉不到位，大多由以上幾種原因?qū)е隆?/p>

之前檢驗出一個較為嚴(yán)重的bug，就是通過漏斗分析發(fā)現(xiàn)的，大意是沒有點擊tab的用戶也觸發(fā)了該tab頁面曝光，后來經(jīng)過數(shù)據(jù)產(chǎn)品同學(xué)幾輪精細(xì)排查，才發(fā)現(xiàn)是因為安卓端tab兩端頁面存在預(yù)加載現(xiàn)象，比如tab順序為a,b,c時，用戶點擊tab b，a和c也會觸發(fā)曝光埋點。還有一個case是業(yè)務(wù)反饋付費用戶數(shù)在漏斗中大幅下降，但付費用戶數(shù)未見明顯下滑，后來發(fā)現(xiàn)當(dāng)日出現(xiàn)了大量日志堆積現(xiàn)象，導(dǎo)致了上報時間混亂影響了漏斗數(shù)據(jù)。

檢驗事件屬性值的分布情況：主要是為了排查屬性內(nèi)容是否符合預(yù)期，是否上傳大量空值。一個case是運營同學(xué)反饋某個內(nèi)容的播放數(shù)據(jù)后期出現(xiàn)暴跌，后來發(fā)現(xiàn)是某一天后臺修改了該內(nèi)容的名稱，所以當(dāng)屬性名稱本來應(yīng)該有a,b,c，哪天突然變成a,b,d，我們也應(yīng)該引起警覺

在數(shù)倉日志層面做檢查，主要分成以下幾種維度：檢查重復(fù)數(shù)據(jù)條數(shù)，總?cè)罩緮?shù)波動情況，區(qū)分「具體事件」和「具體屬性」的數(shù)據(jù)波動情況。

主要排查是否出現(xiàn)大量重復(fù)上報，注意重復(fù)上報的數(shù)據(jù)也未必是一條數(shù)據(jù)長得一毛一樣，有時候可能是大體一致但個別字段有差異，這種情況仍然值得我們仔細(xì)排查原因。對于埋點健康，在數(shù)倉層面，我們也可以設(shè)計一定的指標(biāo)去做監(jiān)控，比如事件屬性錯誤率（根據(jù)埋點文檔約束的實際期望內(nèi)容），事件屬性新增字段占比，字段非空占比，重復(fù)值個數(shù)等，好對異常情況進(jìn)行報警。

另外，除了本埋點的驗證，我們還需要做好關(guān)鍵指標(biāo)的回歸測試，即判斷新埋點上線有沒有影響核心埋點的數(shù)據(jù)上報。關(guān)鍵指標(biāo)不宜太多，否則也會造成一定的人力浪費，關(guān)注app主路徑行為即可。

回歸測試主要是防止合并代碼過程中影響到核心埋點，這一塊常常被忽略，但出現(xiàn)問題往往后果又很嚴(yán)重，成熟的埋點平臺大多支持采用通用規(guī)則去進(jìn)行自動化的回歸測試。

埋點反饋「禮儀」

最后，提一下反饋問題的「禮儀」。也許我們未必要做到這么精細(xì)，但是有余力的情況下，做到這么精細(xì)解決問題的效率更高。

我們反饋埋點問題時不要只說現(xiàn)象，盡量自己先初步排查原因，縮小范圍，比如問題什么時候/什么版本出現(xiàn)的（幫忙定位出現(xiàn)問題的版本），什么平臺（ios/安卓）？提供案例用戶（如果兩端都有問題，最好ios和安卓各提供一個）和相關(guān)代碼，適當(dāng)看日志，結(jié)合數(shù)倉取數(shù)結(jié)果給出自己的猜想。

反饋問題不是把問題丟出去就完了，既然最終目標(biāo)是解決問題，想推動問題的解決，你就要深入了解問題如何發(fā)生，盡量幫忙一起解決問題。

有些問題的發(fā)現(xiàn)，本來就是一個小分析，對于提升我們的數(shù)據(jù)分析思維也是有裨益的。

當(dāng)然，埋點出現(xiàn)問題的場景非常多，錯誤方式也五花八門，沒有一套方法論能覆蓋掉所有問題，所以要求我們對平時出現(xiàn)的問題場景，有意識做沉淀和積累，提升解決埋點問題的效率。

Reference：

[1]愛奇藝埋點投遞治理實踐，i技術(shù)會

[2]嚴(yán)選埋點質(zhì)量保障體系建設(shè)，嚴(yán)選技術(shù)

[3]埋點系列-埋點數(shù)據(jù)質(zhì)量如何保障，迪普觀點