資料治理丨埋點上線前中後，資料分析師的工作有哪些

一個埋點的上線，一般可以分成需求階段、埋點需求評審 / 埋點開發、灰度測試、正式上線這四個階段，在這些環節中，資料分析師的重要價值和工作內容是怎麼樣的呢？本文作者對此作出了分析，一起來看一下吧。

昨天面試了一個偏資料基建和治理的分析崗位，結合昨天的面試問題，對埋點全流程中，資料分析師的角色定位和主要做的事情做一個梳理，也對上個階段關於這部分的工作內容淺做一個總結~

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

當然每個公司人員分工會有細節上的不同，但是初心一定是提升埋點質量，更好的沉澱資料資產。

首先來看一下一個埋點上線全流程及涉及的具體人員，我們可以看到一個埋點的上線通常可以分成四個階段：

需求階段 → 埋點需求評審 / 埋點開發 → 灰度測試 → 正式上線。

接下來我們來看看各個環節資料分析師的主要價值和工作內容是怎麼樣的。

一、需求階段

這個階段通常會有兩種場景，一種是業務方/分析師自身需要統計某種資料於是找到分析師，分析師首先要判斷現有埋點是否能支援該需求，如不能且判斷需求價值高，可由分析師發起新埋點需求，或者對舊埋點做增補。

第二類則是伴隨產品功能迭代/新功能上線，也是實際工作場景中更為常見的一種。通常功能產品經理需要預先產出PRD和原型圖，做出初版的DRD（資料需求文件）。

因為每個人的埋點習慣不同，單單由功能產品負責這一環可能會出現漏埋錯埋，或者對歷史埋點不瞭解重複造輪子等現象，所以需要與資料產品進行一輪溝通，由資料產品來把控埋點是否可以和歷史埋點做相容。

對於較為重要影響面較廣的專案，資料分析同學也需要在這一環節提前參與進來，作為分析師，首先需要明確現階段埋點要統計的有哪些指標（尤其是確保功能的目標提升指標可以被統計到），其次要對未來有哪些資料分析需求預判，哪怕現在不需要，未來規劃中有需要的也要保留下來。

舉個栗子，比如某次某業務首頁做改版，使用者首次進入該業務需要選擇內容偏好標籤，後續分析首頁改版時分析師可能暫時不會對使用者的標籤做細節分析，而主要更關注首頁改版對使用者行為（比如內容滲透率，留存率）是否有正向影響，但是這類選擇資訊可以為演算法同學後續統計使用者內容偏好提供一定資訊，所以設計埋點時就需要統計到。

埋點設計過程中，我的習慣是先做加法，再做減法。首先力求能簡潔完整的概括使用者行為，對於後續分析不大可能涉及的屬性要敢於「斷舍離」。

資料分析師判斷埋點可以滿足業務需求，資料產品判斷埋點可以被很好的吸納到現有的埋點體系，功能產品回去「改作業」後二次確認，就可以進入需求評審環節了。

這一環，有兩個細節需要資料產品&分析師格外注意。

1。 埋點易用性

此外，埋點設計除了考慮到自身使用的易用性，也要儘量考慮到業務方的易用性，所以分析師除了要熟練使用程式碼語言查詢資料，也要儘可能讓埋點在資料工具（前司為例，使用神策）上更好用。

這也要求資料分析師對資料工具有比業務方更深的瞭解，不要只依賴一種方法解決問題，這樣做有兩點好處：

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

2）不斷幫助業務方提升自己使用資料工具解決問題的能力，確定好兩者邊界，才能騰出手來做更多隻有分析師可以做到的事情。

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

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

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

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

2。 評估多方業務訴求

作為資料分析，我們要了解不同的業務方訴求。比如產品需要考量功能本身的使用情況和漏斗轉化效率，使用者運營同學會考量功能上線對使用者的後續影響，比如對使用者的後續留存是否有幫助，開發需要對產品效能和體驗做評估，比如會考慮埋點：應用響應時長，應用崩潰率。

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

二、需求評審 & 開發階段

這一環，資料分析師可以先乾點兒別的，需要咱們處理的不多。功能產品需要在需求評審給開發講解PRD和埋點需求，對於「能埋不能埋」/「需要換方案」的情況也做一輪反饋。

如果開發提出不能埋的埋點對業務很重要，資料分析也需要介入進來，說明該埋點對於業務的關鍵性，推進工作順利進行。對於比較重要的功能改版，也可以考慮在需求評審階段就介入，協助產品經理一起解答開發夥伴對於一些埋點的疑問。

三、埋點測試階段

等到開發自測完成，埋點就進入灰度測試階段。通常開發會進行一輪自測，而後交給測試小夥伴做測試。但因為目前一些測試的習慣還是以功能測試為主，對於比較重要的功能/專案，資料分析師也可以主動加入灰度測試。

不同公司在不同業務發展階段有不同的測試方式，這裡援引迪普老師的總結圖如下：

而作為神策使用者，我們通常是在測試環境裡直接在app裡手動模擬真實使用者行為，去看使用者實時日誌情況。通常我們需要做以下資訊的驗收：

1）驗收使用者標識在一系列事件中是否連貫過往我們就曾有使用者進入某h5頁面其使用者標識失效的情況。

2）驗收事件是否重複上報 / 漏報

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

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

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

內容是否符合預期

欄位格式是否符合預期

是否有空值

而後對上報有誤的資訊做反饋。這個環節對於資料分析師來說往往是很折磨人的，既害怕驗不出問題（萬一沒驗出問題，上線才發現問題修改週期長），又害怕驗出問題（要反饋開發小夥伴修改，改完還得重驗）。

等到各方確定功能/埋點都沒問題了，產品順利發版。嚴謹一點的話，測試完成後最好設計一定的測試使用者白名單機制，在日誌層面對測試使用者的資訊做清除。

四、上線階段

發版以後是否就萬事大吉了呢？測試環境畢竟咱們只有有限的裝置，對使用者變化多端的裝置/網路/以及其他複雜場景缺少預判，所以實際上線以後我們還要繼續緊盯資料，不可懈怠。

主要的監控方向和灰度環節的驗收一致，但是會站在資料分析的視角來看，出現問題再去詳查具體資料，監控的主要粒度和方式如下：

平臺（安卓，IOS等）：

首先對平臺做拆分是因為很多場景下安卓/IOS的開發是由不同團隊負責的，發現問題便於反饋；此外，雖然兩端使用者行為有一定差異，但一端出問題另一端完好的情況下，也可以互為對比參考。

搭建漏斗檢驗關鍵流程是否順暢，對比漏斗各環資料情況和獨立事件實際觸發情況

：這是作為資料分析師的主要武器，不但可以對事件的上報順序和時間做一輪驗證，也可以對使用者標識是否連貫做驗證，同時也檢驗事件是否出現多報 / 少報。

舉個例子，一個通用的業務場景是，業務同學常常反饋「某事件作為獨立事件觸發數遠高於在漏斗中的觸發數」，排除對起點事件的入口的窮舉不到位，大多由以上幾種原因導致。

之前檢驗出一個較為嚴重的bug，就是透過漏斗分析發現的，大意是沒有點選tab的使用者也觸發了該tab頁面曝光，後來經過資料產品同學幾輪精細排查，才發現是因為安卓端tab兩端頁面存在預載入現象，比如tab順序為a，b，c時，使用者點選tab b，a和c也會觸發曝光埋點。還有一個case是業務反饋付費使用者數在漏斗中大幅下降，但付費使用者數未見明顯下滑，後來發現當日出現了大量日誌堆積現象，導致了上報時間混亂影響了漏斗資料。

檢驗事件屬性值的分佈情況

：主要是為了排查屬性內容是否符合預期，是否上傳大量空值。一個case是運營同學反饋某個內容的播放資料後期出現暴跌，後來發現是某一天後臺修改了該內容的名稱，所以當屬性名稱本來應該有a，b，c，哪天突然變成a，b，d，我們也應該引起警覺

在數倉日誌層面做檢查，主要分成以下幾種維度：

檢查重複資料條數，總日誌數波動情況，區分「具體事件」和「具體屬性」的資料波動情況。

主要排查是否出現大量重複上報，注意重複上報的資料也未必是一條資料長得一毛一樣，有時候可能是大體一致但個別欄位有差異，這種情況仍然值得我們仔細排查原因。對於埋點健康，在數倉層面，我們也可以設計一定的指標去做監控，比如事件屬性錯誤率（根據埋點文件約束的實際期望內容），事件屬性新增欄位佔比，欄位非空佔比，重複值個數等，好對異常情況進行報警。

另外，除了本埋點的驗證，我們還需要做好關鍵指標的迴歸測試，即判斷新埋點上線有沒有影響核心埋點的資料上報。關鍵指標不宜太多，否則也會造成一定的人力浪費，關注app主路徑行為即可。

迴歸測試主要是防止合併程式碼過程中影響到核心埋點，這一塊常常被忽略，但出現問題往往後果又很嚴重，成熟的埋點平臺大多支援採用通用規則去進行自動化的迴歸測試。

埋點反饋「禮儀」

最後，提一下反饋問題的「禮儀」。也許我們未必要做到這麼精細，但是有餘力的情況下，做到這麼精細解決問題的效率更高。

我們反饋埋點問題時不要只說現象，儘量自己先初步排查原因，縮小範圍，比如問題什麼時候/什麼版本出現的（幫忙定位出現問題的版本），什麼平臺（ios/安卓）？提供案例使用者（如果兩端都有問題，最好ios和安卓各提供一個）和相關程式碼，適當看日誌，結合數倉取數結果給出自己的猜想。

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

有些問題的發現，本來就是一個小分析，對於提升我們的資料分析思維也是有裨益的。

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

Reference：

［1］愛奇藝埋點投遞治理實踐，i技術會

［2］嚴選埋點質量保障體系建設，嚴選技術

［3］埋點系列-埋點資料質量如何保障，迪普觀點

本文由 @Ver 原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。