中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

首先來看一下一個埋點上線全流程及涉及的具體人員，我們可以看到一個埋點的上線通?？梢苑殖伤膫€階段：需求階段 → 埋點需求評審 / 埋點開發 → 灰度測試 → 正式上線。

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

一、需求階段

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

第二類則是伴隨產品功能迭代/新功能上線，也是實際工作場景中更為常見的一種。通常功能產品經理需要預先產出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]埋點系列-埋點數據質量如何保障，迪普觀點