產(chǎn)品經(jīng)理需要了解的埋點(diǎn)知識(shí)

2 評(píng)論 4072 瀏覽 66 收藏 21 分鐘

為了更加有針對(duì)性、科學(xué)、客觀的對(duì)產(chǎn)品優(yōu)化迭代,產(chǎn)品經(jīng)理會(huì)進(jìn)行產(chǎn)品埋點(diǎn),期望通過分析上報(bào)的數(shù)據(jù)來(lái)獲得某種趨勢(shì)、特征的信號(hào)或者說(shuō)信息,最后,這些信息被用在產(chǎn)品優(yōu)化決策上。本篇文章中,筆者對(duì)產(chǎn)品經(jīng)理需要了解的埋點(diǎn)知識(shí)進(jìn)行了梳理,攻大家參考和學(xué)習(xí)。

產(chǎn)品經(jīng)理工作的三個(gè)常態(tài)就是寫文檔、溝通、看數(shù)據(jù)。畢竟辛辛苦苦寫完需求文檔還冒著被砍需求的風(fēng)險(xiǎn),好不容易說(shuō)服了研發(fā)開發(fā)上線后,總是要關(guān)注自己在研發(fā)面前吹上天的功能在上線后數(shù)據(jù)方面是不是有變化。

另外產(chǎn)品經(jīng)理的本質(zhì)工作是發(fā)現(xiàn)問題、分析問題和解決問題,寫文檔也好,溝通跟進(jìn)項(xiàng)目也罷,最終的目的都是為了解決問題,那怎么證明問題被解決了?

除了后臺(tái)反饋某個(gè)問題的聲音沒了以外,最直觀的就是負(fù)面數(shù)據(jù)降低了,正向數(shù)據(jù)升上去了。

產(chǎn)品經(jīng)理的價(jià)值除了實(shí)現(xiàn)用戶價(jià)值,解決用戶的各種問題痛點(diǎn)以外,還需要實(shí)現(xiàn)商業(yè)價(jià)值,畢竟老板給定的OKR既不會(huì)讓研發(fā)背也不會(huì)讓測(cè)試背,對(duì)結(jié)果負(fù)責(zé)的只能是產(chǎn)品了。

那產(chǎn)品怎么證明自己勤勤懇懇夜以繼日的工作是有收獲的呢?

數(shù)據(jù)是讓老板滿意最有效的方式,畢竟日活能從10w做到100w對(duì)企業(yè)來(lái)說(shuō)是完全不一樣的概念,直接的商業(yè)價(jià)值比如售賣的收入轉(zhuǎn)化從0.4%做到4%就有可能讓企業(yè)真正的存活下來(lái)。那數(shù)據(jù)從哪來(lái)呢?今天就好好說(shuō)道說(shuō)道埋點(diǎn)的全流程。

前面說(shuō)了產(chǎn)品經(jīng)理想看數(shù)據(jù)那就需要多方配合,既然自己需要數(shù)據(jù),除了用戶的行為會(huì)反映在數(shù)據(jù)上以外,想要直觀看到數(shù)據(jù)中間還是隔了不止一座山不止一片海(最近看了張嘉佳的《云邊的小賣部》各種華麗辭藻堆砌雞湯文不禁被帶了節(jié)奏),畢竟自己也沒法看到每個(gè)用戶的使用情況。那又該如何是好呢?「為何處境如此的像唐僧」

這里就需要我們?nèi)f能的研發(fā)了,不僅需要他們通過飛舞地敲動(dòng)鍵盤上的字母轉(zhuǎn)瞬間變成代碼,進(jìn)而將草圖上不堪入目的功能概念變成觸手可及的實(shí)用功能,也需要他們繼續(xù)飛指間將監(jiān)聽用戶行為的代碼也一同寫進(jìn)去。

研發(fā)能監(jiān)聽用戶的行為但畢竟這些東西都還是在代碼里,可視化的效果確實(shí)有點(diǎn)難,這里就需要數(shù)據(jù)分析的同學(xué)進(jìn)場(chǎng)了,產(chǎn)品經(jīng)理除了跟研發(fā)提數(shù)據(jù)需求,也需要跟數(shù)據(jù)分析的同學(xué)提需求,把監(jiān)聽到的數(shù)據(jù)變得可視化,易于直觀的看到自己想要的結(jié)果。

上面說(shuō)了這么多,那我們就正式的來(lái)說(shuō)每一步吧~

「埋點(diǎn)原理及方式」

首先是關(guān)于埋點(diǎn)的概念,畢竟做啥事能明白其中的原理還是很重要的。

埋點(diǎn)是指對(duì)目標(biāo)事件進(jìn)行捕獲、處理和上報(bào)的相關(guān)技術(shù)及實(shí)施過程,其主要目的是實(shí)現(xiàn)用戶對(duì)產(chǎn)品行為的監(jiān)控與數(shù)據(jù)收集。

具體來(lái)說(shuō)就是在定義的事件代碼中植入一段監(jiān)控代碼,用戶一旦觸發(fā)該事件就會(huì)上報(bào)埋點(diǎn)代碼中定義的需要上報(bào)的字段信息;通俗的說(shuō)就是實(shí)現(xiàn)了給每個(gè)用戶在使用自家產(chǎn)品時(shí)分配了一個(gè)產(chǎn)品經(jīng)理,用來(lái)記錄用戶都打開了哪些頁(yè)面,點(diǎn)擊了哪些按鈕,停留了多長(zhǎng)時(shí)間。

埋點(diǎn)可根據(jù)開發(fā)方式與埋點(diǎn)位置分為兩類,先是開發(fā)方式最常見的一種是代碼埋點(diǎn),即手工埋點(diǎn),顧名思義是研發(fā)將用于監(jiān)聽用戶行為的代碼提前手動(dòng)埋到觸發(fā)該事件的代碼中。

這種傳統(tǒng)且常見的方式優(yōu)點(diǎn)和缺點(diǎn)都極其明顯,優(yōu)點(diǎn)方面即可以自定義進(jìn)行數(shù)據(jù)采集,想采多少就采多少,想采什么數(shù)據(jù)就采什么數(shù)據(jù),哪怕是腦洞再大的產(chǎn)品經(jīng)理只要是提的數(shù)據(jù)需求合理,原則上都可以滿足并最終統(tǒng)計(jì)到想要的數(shù)據(jù)。

但同樣的缺點(diǎn)就顯而易見了,這種手動(dòng)人為的方式就會(huì)受到整個(gè)APP發(fā)版流程的限制,即不管是iOS端還是Android端每次升級(jí)都是要發(fā)版的,而每次發(fā)版都是封裝好當(dāng)前這版本的代碼,如有變動(dòng)只能更換提交到各大應(yīng)用商店的安裝包,如果頻率過多負(fù)責(zé)渠道的同學(xué)定會(huì)提著40米的大砍刀來(lái)找發(fā)版產(chǎn)品經(jīng)理了。

代碼埋點(diǎn)一旦存在問題進(jìn)而會(huì)引發(fā)什么問題呢?

試想新功能上線后老板某一天突然找到你要新版本的數(shù)據(jù),這時(shí)你找研發(fā)要埋點(diǎn)信息但對(duì)方告知你沒有埋上或者埋點(diǎn)信息異常,聽到這句話產(chǎn)品心里肯定涼半截,沒法交差了。

如非極其重要的數(shù)據(jù)只能眼瞅著等待下一個(gè)發(fā)版周期才能統(tǒng)計(jì)新功能的數(shù)據(jù)了。此外,流程上也會(huì)占用一定的人力,這點(diǎn)在后面的埋點(diǎn)流程中會(huì)細(xì)講。

當(dāng)一種操作方式有它存在的局限性,隨之就會(huì)有其他更便捷高效的方式出現(xiàn),畢竟事物是發(fā)展的,沒錯(cuò),近幾年一些第三方數(shù)據(jù)平臺(tái)或諸如bat這種互聯(lián)網(wǎng)公司已經(jīng)想出一種可視化埋點(diǎn)方式

——通常是指通過設(shè)備連接用戶行為分析工具的數(shù)據(jù)接入管理界面,對(duì)可交互且交互后有效果的頁(yè)面元素(如:圖片、按鈕、鏈接等),直接在界面上進(jìn)行操作實(shí)現(xiàn)數(shù)據(jù)埋點(diǎn),下發(fā)采集代碼生效回?cái)?shù)的埋點(diǎn)方式。

這種埋點(diǎn)方式極大的提高了人力成本,想想傳統(tǒng)的手工埋點(diǎn)方式需要產(chǎn)品給研發(fā)提埋點(diǎn)需求,研發(fā)需要在代碼中寫入監(jiān)聽的代碼,產(chǎn)品上線前還需要驗(yàn)證??梢暬顸c(diǎn)類似于前端網(wǎng)頁(yè)的形式,實(shí)時(shí)交互降低人力成本和出錯(cuò)成本。

既然可視化埋點(diǎn)這么好為啥并沒有完全普及或者成為各大互聯(lián)網(wǎng)公司的主流埋點(diǎn)方式呢?問題就在于既要輕量級(jí)就沒法完全自定義,對(duì)于一些基本的記錄某個(gè)頁(yè)面的展現(xiàn)和按鈕點(diǎn)擊可能沒問題,但是面對(duì)一些復(fù)雜的數(shù)據(jù)需求時(shí)這種方式便沒轍了。

比如需要區(qū)分來(lái)源的數(shù)據(jù)需求,帶各種參數(shù)的需求,需要和后端交互的數(shù)據(jù)需求就不太適合可視化埋點(diǎn)方式。

所以總結(jié)來(lái)看可視化埋點(diǎn)雖然很美好但僅限于一些簡(jiǎn)單的純客戶端埋點(diǎn)統(tǒng)計(jì),在復(fù)雜的數(shù)據(jù)采集需求面前行不通且準(zhǔn)確性較低,這也是影響它普及的最大因素。

除了可視化埋點(diǎn)還有一種無(wú)埋點(diǎn)方式,也叫全埋點(diǎn),即事先盡可能收集所有控件的操作數(shù)據(jù),然后再通過界面配置哪些數(shù)據(jù)需要在系統(tǒng)里面進(jìn)行分析。

相比于可視化埋點(diǎn)這種半自動(dòng)化模式,全埋點(diǎn)不僅繼承了可視化埋點(diǎn)的優(yōu)點(diǎn),同時(shí)解決了手工埋點(diǎn)和可視化埋點(diǎn)共同的一個(gè)缺點(diǎn)即數(shù)據(jù)回溯。

比如產(chǎn)品想要看某個(gè)按鈕的數(shù)據(jù),可視化埋點(diǎn)只能做到從此刻以后的數(shù)據(jù),在這之前的數(shù)據(jù)是沒有的。

但全埋點(diǎn)只要在一開始封裝的SDK就部署在代碼中即可以保留整個(gè)時(shí)間線的數(shù)據(jù),做到真正的所見即所得,通過點(diǎn)擊某一控件區(qū)域便能看到該區(qū)域的歷史所有數(shù)據(jù)。

但全埋點(diǎn)也繼承了可視化埋點(diǎn)的所有缺點(diǎn),所以這種的埋點(diǎn)方式同樣也無(wú)法做到全面普及。

上面說(shuō)的手工埋點(diǎn)、可視化埋點(diǎn)、全埋點(diǎn)是指按照開發(fā)方式劃分的,按照埋點(diǎn)位置還可以分為客戶端埋點(diǎn)和服務(wù)端埋點(diǎn)。即上面三種埋點(diǎn)方式都是在客戶端實(shí)現(xiàn)的,而有一部分?jǐn)?shù)據(jù)是可以直接通過服務(wù)端去埋點(diǎn)并上報(bào)所有數(shù)據(jù)。

比如統(tǒng)計(jì)某款社區(qū)產(chǎn)品每天的用戶發(fā)帖記錄,除了可以直接在客戶端埋點(diǎn)統(tǒng)計(jì),也可以直接提交至服務(wù)端的數(shù)據(jù)量級(jí)??蛻舳寺顸c(diǎn)和服務(wù)端埋點(diǎn)優(yōu)缺點(diǎn)又是什么呢?

對(duì)于客戶端埋點(diǎn)的優(yōu)點(diǎn)和缺點(diǎn)基本上就是上面介紹的那些,這里相比于服務(wù)端埋點(diǎn)存在的另一個(gè)缺點(diǎn)是數(shù)據(jù)上報(bào)有延遲且會(huì)存在漏報(bào)的情況。

而服務(wù)端埋點(diǎn)的優(yōu)勢(shì)便是數(shù)據(jù)上報(bào)無(wú)延遲,可以實(shí)時(shí)獲取到數(shù)據(jù),且整個(gè)操作較客戶端更簡(jiǎn)單便捷,缺點(diǎn)方面自然是沒法統(tǒng)計(jì)純客戶端的數(shù)據(jù),比如不需要跟服務(wù)端發(fā)生交互的用戶行為。

此外數(shù)據(jù)的收集會(huì)依賴網(wǎng)絡(luò)環(huán)境,這也是為什么同樣的統(tǒng)計(jì)目標(biāo)一般服務(wù)端和客戶端統(tǒng)計(jì)的數(shù)據(jù)有些許偏差。

這里正是因?yàn)榫W(wǎng)絡(luò)質(zhì)量的問題影響了服務(wù)端的統(tǒng)計(jì)。比如用戶提交某個(gè)數(shù)據(jù),在客戶端層面用戶已經(jīng)完成了這個(gè)行為,但網(wǎng)絡(luò)質(zhì)量不佳服務(wù)端可能就沒有采集到這個(gè)數(shù)據(jù)。

以上關(guān)于埋點(diǎn)的原理介紹和分類就已經(jīng)說(shuō)完了,下面開始埋點(diǎn)相關(guān)角色分工及埋點(diǎn)需求的流程,這里主要講的是當(dāng)前主流模式的客戶端手動(dòng)埋點(diǎn)流程。

埋點(diǎn)需求流程中包含的角色如上圖,包括產(chǎn)品經(jīng)理、研發(fā)、測(cè)試、商務(wù)智能和數(shù)據(jù)平臺(tái)。

  • 其中PM作為埋點(diǎn)需求的發(fā)起方,跟產(chǎn)品功能需求一樣全流程跟進(jìn);
  • RD的主要工作是開發(fā)埋點(diǎn)功能,即在代碼中添加監(jiān)聽用戶行為的代碼。但在不同的公司流程中有些RD還承擔(dān)定義埋點(diǎn)名稱和維護(hù)埋點(diǎn)資料的工作;
  • QA一般承擔(dān)著測(cè)試埋點(diǎn)功能的工作,即測(cè)試某個(gè)點(diǎn)是否埋點(diǎn)正確。但有些公司QA并不承接這個(gè)工作,那這個(gè)驗(yàn)證的工作自然就落在了PM身上。
  • 當(dāng)前面流程走完,埋點(diǎn)跟隨產(chǎn)品功能一起上線后PM就會(huì)跟BI同學(xué)提出數(shù)據(jù)需求,由BI同學(xué)將數(shù)據(jù)可視化。
  • 至于平臺(tái)這個(gè)角色需要看公司的在數(shù)據(jù)這塊的重視程度,雖然埋點(diǎn)流程需要以上角色但并不意味著每家公司的埋點(diǎn)流程都是這樣,具體來(lái)說(shuō)分為規(guī)范性流程與非規(guī)范性流程。

「埋點(diǎn)流程」

首先是非規(guī)范性流程,比如一些創(chuàng)業(yè)公司和小公司因?yàn)楣咎幱诎l(fā)展初期或業(yè)務(wù)對(duì)數(shù)據(jù)的依賴性不是太強(qiáng)的時(shí)候一般整體的埋點(diǎn)流程就會(huì)隨意一些。具體流程參見下圖:

如上面這張圖當(dāng)公司無(wú)埋點(diǎn)工具或數(shù)據(jù)平臺(tái)時(shí),埋點(diǎn)流程則相對(duì)人工化。

如果公司無(wú)BI這個(gè)崗位,一般由PM在需求文檔中提出埋點(diǎn)需求,在技術(shù)評(píng)審時(shí)提出自己的埋點(diǎn)需求,由RD在開發(fā)中自定義埋點(diǎn)名稱和參數(shù)(有些公司是由pm定義并維護(hù)埋點(diǎn)資料),并將這些信息埋點(diǎn)代碼中,并在公司某一平臺(tái)維護(hù)埋點(diǎn)資料,以便后續(xù)使用。

接著是QA測(cè)試環(huán)節(jié),一般埋點(diǎn)的邏輯性較為簡(jiǎn)單,所以有些公司QA并不介入埋點(diǎn)測(cè)試,上線前直接由PM進(jìn)行埋點(diǎn)驗(yàn)收。

這種人工式的埋點(diǎn)流程存在著較大的數(shù)據(jù)風(fēng)險(xiǎn),一是埋點(diǎn)名稱不規(guī)范不統(tǒng)一,對(duì)于一些參數(shù)的定義也較為隨意,這樣就容易造成后續(xù)的埋點(diǎn)名稱冗余且混亂,不利于后續(xù)的統(tǒng)一管理;二是流程中諸多環(huán)節(jié)均為口頭溝通PM驗(yàn)收較為繁瑣,某個(gè)版本漏埋點(diǎn)或埋點(diǎn)不正確的風(fēng)險(xiǎn)大大提高,對(duì)于數(shù)據(jù)的及時(shí)提供帶來(lái)較大隱患。

一般隨著公司的擴(kuò)大和流程的規(guī)范,數(shù)據(jù)平臺(tái)的建立將大大的提升埋點(diǎn)流程的規(guī)范性、時(shí)效性。具體參見下圖:

相比于無(wú)數(shù)據(jù)平臺(tái)的埋點(diǎn)流程,一旦有定制化的數(shù)據(jù)平臺(tái),埋點(diǎn)流程將變得完全不一樣。

此時(shí),仍是PM提出埋點(diǎn)需求但是整個(gè)流程將收歸至線上,即PM將高保真的頁(yè)面記錄在數(shù)據(jù)平臺(tái),并在數(shù)據(jù)平臺(tái)自動(dòng)生成埋點(diǎn)名稱及任務(wù)推送給對(duì)應(yīng)的RD,RD將根據(jù)由平臺(tái)定義好的埋點(diǎn)名稱和參數(shù)寫入對(duì)應(yīng)的代碼中。

此外數(shù)據(jù)平臺(tái)還支持測(cè)試埋點(diǎn),即PM可通過數(shù)據(jù)平臺(tái)在發(fā)版前安裝測(cè)試包測(cè)試埋點(diǎn)信息是否存在和正確性,極大的降低了風(fēng)險(xiǎn)性。

后續(xù)的數(shù)據(jù)可視化也直接在數(shù)據(jù)平臺(tái)查看,甚至能查看實(shí)時(shí)的數(shù)據(jù)大盤,諸如某個(gè)時(shí)間點(diǎn)的日活,訂單量等。

擁有定制化的數(shù)據(jù)平臺(tái)在埋點(diǎn)名稱的管理和維護(hù)方面將更加靈活且自動(dòng)化,特別是對(duì)于擁有多條業(yè)務(wù)線的公司來(lái)說(shuō)更是必不可少。

這里就不得不多提一些,對(duì)于多業(yè)務(wù)多終端的公司來(lái)說(shuō),數(shù)據(jù)的整理與維護(hù)工作至關(guān)重要,特別是對(duì)于現(xiàn)在的互聯(lián)網(wǎng)發(fā)展形態(tài)來(lái)說(shuō),數(shù)據(jù)的精細(xì)化可視化是指導(dǎo)業(yè)務(wù)規(guī)劃和業(yè)務(wù)決策的重要參考。

那這樣在埋點(diǎn)流程中埋點(diǎn)名稱的命名規(guī)則就需要考慮業(yè)務(wù)、終端、頁(yè)面的唯一性和可辨識(shí)度。

此外對(duì)于一些參數(shù)的定義也不再隨意,應(yīng)包含全局通用參數(shù)即所有業(yè)務(wù)所有終端所有埋點(diǎn)都需要統(tǒng)一攜帶的參數(shù)。

比如一家教育公司中年級(jí)、學(xué)科這種應(yīng)該就屬于全局通用參數(shù),這樣在統(tǒng)計(jì)多業(yè)務(wù)多終端時(shí)才能保證參數(shù)的統(tǒng)一性;業(yè)務(wù)公共參數(shù)是指某一業(yè)務(wù)下多終端所有埋點(diǎn)攜帶的參數(shù)需要一致;業(yè)務(wù)自定義參數(shù)即部分參數(shù)可僅屬于某一業(yè)務(wù)下某一模塊獨(dú)有的信息,可使用自定義的方式命名參數(shù),無(wú)需考慮其他終端其他業(yè)務(wù)。

當(dāng)功能上線后PM需要某些數(shù)據(jù)時(shí)可根據(jù)業(yè)務(wù)需要向bi或數(shù)據(jù)分析師提出數(shù)據(jù)需求,具體的數(shù)據(jù)呈現(xiàn)方式也可根據(jù)數(shù)據(jù)的重要性及查看頻率決定是建立數(shù)據(jù)報(bào)表長(zhǎng)期監(jiān)控還是一次性的將數(shù)據(jù)導(dǎo)出以Excel等形式展示。

在提出數(shù)據(jù)需求方面也應(yīng)以郵件的形式明確需求背景、所需數(shù)據(jù)時(shí)間范圍、數(shù)據(jù)統(tǒng)計(jì)邏輯和預(yù)期給到時(shí)間等。

「答疑」

以上便是埋點(diǎn)的全流程,每個(gè)公司的實(shí)際情況可能會(huì)有一定出入。但PM作為數(shù)據(jù)需求的發(fā)起方應(yīng)充分了解埋點(diǎn)的流程,盡量降低各環(huán)節(jié)因不規(guī)范性帶來(lái)的風(fēng)險(xiǎn)性,更好的讓數(shù)據(jù)服務(wù)于工作。

以下還有一些關(guān)于數(shù)據(jù)方面的常見問題:

Q:數(shù)據(jù)的全流程有哪些環(huán)節(jié)?

A:上面的流程中更多是埋點(diǎn)的業(yè)務(wù)流程,真正的數(shù)據(jù)流程包括數(shù)據(jù)采集、數(shù)據(jù)上報(bào)、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)加工、數(shù)據(jù)輸出等幾部分。

Q:一般可以采集到哪些數(shù)據(jù)?

A:按照采集位置可分為客戶端「交互行為」數(shù)據(jù)和服務(wù)端「接口請(qǐng)求」數(shù)據(jù)??蛻舳藬?shù)據(jù)包括頁(yè)面的展現(xiàn)、控件點(diǎn)擊、停留時(shí)長(zhǎng)等,服務(wù)端數(shù)據(jù)包括請(qǐng)求狀態(tài)、請(qǐng)求結(jié)果等。

Q:哪些原因會(huì)導(dǎo)致統(tǒng)計(jì)的數(shù)據(jù)不準(zhǔn)確?

A:首先是數(shù)據(jù)源異常,其中包含功能變動(dòng)后未提出埋點(diǎn)需求、埋點(diǎn)需求不明確不完整、溝通過程中需求方和執(zhí)行方理解有偏差等;同時(shí)在代碼層面可能會(huì)出現(xiàn)埋點(diǎn)位置錯(cuò)誤、參數(shù)缺失,或者因?yàn)榇a調(diào)整導(dǎo)致原有埋點(diǎn)代碼丟失錯(cuò)位等;

其次是數(shù)據(jù)上報(bào)異常,包括上報(bào)數(shù)據(jù)格式不規(guī)范,沒有按照規(guī)定格式上報(bào)或者各業(yè)務(wù)的埋點(diǎn)數(shù)據(jù)格式不統(tǒng)一;因網(wǎng)絡(luò)質(zhì)量不佳和服務(wù)器壓力過大會(huì)導(dǎo)致數(shù)據(jù)上報(bào)延遲;數(shù)據(jù)上報(bào)地址的錯(cuò)誤也會(huì)導(dǎo)致無(wú)法準(zhǔn)確統(tǒng)計(jì)數(shù)據(jù);

最后數(shù)據(jù)輸出層面也會(huì)影響數(shù)據(jù)的準(zhǔn)確性,比如數(shù)據(jù)需求未將統(tǒng)計(jì)邏輯考慮周全,需求方與統(tǒng)計(jì)方溝通理解的偏差性,數(shù)據(jù)產(chǎn)出延遲等。

Q:數(shù)據(jù)有問題,可以找哪些同學(xué)解決?

A:首先是與bi或數(shù)據(jù)分析同學(xué)確認(rèn)數(shù)據(jù)上報(bào)和產(chǎn)出是否存在延遲問題,其次再確認(rèn)統(tǒng)計(jì)方式與自己的需要的數(shù)據(jù)統(tǒng)計(jì)邏輯是否一致,如若不一致則由數(shù)據(jù)產(chǎn)出方修改SQL語(yǔ)句即可;當(dāng)統(tǒng)計(jì)方式?jīng)]問題時(shí)再去和rd同學(xué)確認(rèn)埋點(diǎn)信息、參數(shù)信息在代碼中是否埋上且位置準(zhǔn)確,上報(bào)地址否準(zhǔn)確等。

Q:在哪些環(huán)節(jié)可以避免數(shù)據(jù)問題?

A:產(chǎn)品、運(yùn)營(yíng)、研發(fā)加強(qiáng)并培養(yǎng)數(shù)據(jù)意識(shí),更深入了解并提升數(shù)據(jù)相關(guān)能力。產(chǎn)品、研發(fā)、數(shù)據(jù)分析等同學(xué)在埋點(diǎn)流程中保持較高的嚴(yán)謹(jǐn)性和專注度,避免在執(zhí)行層面犯低級(jí)錯(cuò)誤。全流程中各環(huán)節(jié)各方負(fù)責(zé)人均需加強(qiáng)自測(cè)和驗(yàn)收,在需求上線前及時(shí)發(fā)現(xiàn)問題。借助工具的能力,將諸多流程從線下人力遷移至線上流程,減少因人力維護(hù)和輸入輸出導(dǎo)致的一些錯(cuò)誤。

 

作者:我呀way ;個(gè)人公眾號(hào):鄭重心流,歡迎來(lái)撩~

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

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

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 建議表述的更清楚、更規(guī)范一些

    來(lái)自北京 回復(fù)
  2. 學(xué)習(xí)了 ??

    來(lái)自重慶 回復(fù)