chinesefreesexvideos高潮,欧美极品少妇性运交,久久久国产一区二区三区,99久久婷婷国产综合精品,成人国产一区二区三区

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1）每個(gè)會場的瀏覽和點(diǎn)擊都采用單獨(dú)的埋點(diǎn)事件，比如：活動(dòng)a_瀏覽，活動(dòng)b_瀏覽。

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

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

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

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

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

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

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

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

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

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

2）驗(yàn)收事件是否重復(fù)上報(bào) / 漏報(bào)

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

4）驗(yàn)收是否所有屬性都有上報(bào)

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

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

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

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

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

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

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

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

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

檢驗(yàn)事件屬性值的分布情況：主要是為了排查屬性內(nèi)容是否符合預(yù)期，是否上傳大量空值。一個(gè)case是運(yùn)營同學(xué)反饋某個(gè)內(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ù)波動(dòng)情況，區(qū)分「具體事件」和「具體屬性」的數(shù)據(jù)波動(dòng)情況。

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

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

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

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

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

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

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

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

Reference：

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

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

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

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

題圖來自 Unsplash，基于 CC0 協(xié)議

該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。