產(chǎn)品經(jīng)理整理埋點(diǎn)需求的6個步驟
編輯導(dǎo)語:數(shù)據(jù)分析在一定程度上可以幫助梳理需求,進(jìn)而推動業(yè)務(wù)迭代優(yōu)化,因而對于產(chǎn)品經(jīng)理而言,了解與數(shù)據(jù)分析相關(guān)的內(nèi)容便尤為重要。其中,數(shù)據(jù)埋點(diǎn)需求應(yīng)當(dāng)如何梳理?本篇文章里,作者總結(jié)了產(chǎn)品經(jīng)理整理埋點(diǎn)需求的幾大步驟,不妨來看一下。
互聯(lián)網(wǎng)發(fā)展到現(xiàn)在這個階段,數(shù)據(jù)驅(qū)動已經(jīng)被很多人認(rèn)同甚至奉為圭臬,因為有效所以擴(kuò)散,觀察和分析數(shù)據(jù)是產(chǎn)品崗位的標(biāo)配了,所以對于一個產(chǎn)品經(jīng)理來說這是必備技能之一。
從市面上各種數(shù)據(jù)分析課程和python課程以數(shù)據(jù)爬取和分析為賣點(diǎn),數(shù)據(jù)熱潮可見一斑。人重要的是順勢而為,既然市場有需求當(dāng)然要會。
對數(shù)據(jù)的使用是分為采集、清洗、存儲、提取、挖掘、分析這些部分的,采集、清洗、存儲、提取是技術(shù)在處理,挖掘和分析一般是數(shù)據(jù)分析師和產(chǎn)品、運(yùn)營等在看,各有分工。
但是源頭還是需要產(chǎn)品或者運(yùn)營來梳理,因為技術(shù)通常并不知道要采集哪些數(shù)據(jù),所以就需要產(chǎn)品提供數(shù)據(jù)采集說明,也就是埋點(diǎn)需求的說明文檔。
那么埋點(diǎn)需求怎么梳理?
第一步,確定公共數(shù)據(jù)點(diǎn),主要是用戶屬性和設(shè)備屬性。
用戶屬性和設(shè)備屬性的樣例見下圖
公共數(shù)據(jù)點(diǎn)其實一般來說都是不變的,一旦確定之后很少修改,所以復(fù)制粘貼即可。
因為一般不會變化所以在第一次提的時候需要盡可能的提全面,因為如果是后續(xù)補(bǔ)充的話歷史數(shù)據(jù)是無法追溯補(bǔ)充的,分析的時候可能就會有維度缺失。
第二步,確定一下產(chǎn)品需求的范圍,也就是這次需求優(yōu)化了哪些地方,把需求涉及到的app端頁面全部梳理出來-不分原生或者H5,單列一個表格,每個頁面列成一條。
第三步,把頁面上涉及到的所有按鈕補(bǔ)充到對應(yīng)頁面的下方,也單列一條。譬如一個注冊頁面,一般會有獲取驗證碼按鈕、注冊登錄按鈕,每一個按鈕都需要單列一條。如果是二級頁面,左上角的返回按鈕可列可不列,一般也不重要。
第四步,把數(shù)據(jù)埋點(diǎn)需求表填充完整。這就是一個填充的過程,不遺漏就行,比較需要關(guān)注的是埋點(diǎn)由前端埋點(diǎn)還是后端埋點(diǎn),這個需要根據(jù)情況定一下,一般來說如果僅僅是時間譬如訪問和點(diǎn)擊這種就做前端埋點(diǎn),但是需要有結(jié)果的,譬如帖子發(fā)布成功這種的就做后端埋點(diǎn)。如果不確定可以和技術(shù)討論一下。
埋點(diǎn)需求的樣表是這樣的,大家可以做個參考。
第五步,埋點(diǎn)需求表理完之后最后需要做一下核對,看一下是不是完整了。怎么核對呢?根據(jù)數(shù)據(jù)統(tǒng)計需求去核對,看一下配套要做的數(shù)據(jù)統(tǒng)計報表能不能根據(jù)這些頁面埋點(diǎn)統(tǒng)計到,如果可以的話一般問題不大。如果有遺漏的補(bǔ)充一下。
敲黑板:這是最重要的一步。
校驗內(nèi)容你可以按照以下步驟去做:
1)看一下中英文的命名是不是正確,有沒有重復(fù)。正確一般不是問題,但是重復(fù)這個可能時間長了會有出現(xiàn),尤其是英文名,畢竟大家英文一般都不6,所以在命名的時候尤其是尤其要注意,取個巧的方法是拿著中文去百度翻譯成英文,如果重復(fù)換一個或者加001這種以示區(qū)分。
2)看事件定義完不完整,夠不夠清晰,如果是剛開始寫的可以拿公司的歷史文檔去比對,照著改就行。
3)事件觸發(fā)的時機(jī)對不對,如果是按鈕的話其實問題不大,就是個點(diǎn)擊事件,如果是頁面訪問一定要寫清楚是頁面100%加載完成。
4)埋點(diǎn)的前后端區(qū)分對不對,這個之前也有講,如果只是事件本身其實一般做前端埋點(diǎn),如果還要統(tǒng)計結(jié)果,譬如提交內(nèi)容成功這種的就需要做后端埋點(diǎn)。
5)屬性定義完不完整,屬性會包含很多東西,譬如類型、渠道之類的,會有多個,在這個時候一定要看一下是不是全部包含了,漏掉的話在統(tǒng)計的時候就會有問題,雖然技術(shù)后面可能還會來確認(rèn),但是少讓技術(shù)問比較好,人設(shè)靠譜。
第六步,給技術(shù)看一下,看看是不是有哪些地方需要進(jìn)一步細(xì)化說明,針對性地做補(bǔ)充說明。這個步驟一般就是細(xì)節(jié)沒講清楚,譬如頁面訪問,那么什么情況下定義為一次訪問,需要說明這個頁面100%加載成功了才算一次訪問。
埋點(diǎn)需求交付以后技術(shù)會排期開發(fā),開發(fā)完之后的驗收也是一個比較重要的環(huán)節(jié),根據(jù)我們的經(jīng)驗埋點(diǎn)通常會有遺漏或者采集不完整、采集不準(zhǔn)確的情況。
那么埋點(diǎn)數(shù)據(jù)怎么驗收呢?
如果你有技術(shù)背景,那么就去看操作之后相應(yīng)的數(shù)據(jù)字段有沒有入庫;如果沒有技術(shù)背景那么就去看統(tǒng)計報表上會不會反應(yīng)出來。譬如你打開一個頁面,就去看一下統(tǒng)計報表上這個頁面的訪問人數(shù)和訪問次數(shù)有沒有+1。
埋點(diǎn)驗收是需要一個一個頁面、一個一個操作看過去的,所以可以結(jié)合頁面驗收一起做。
那么驗收了之后就沒有問題了嗎?
不是的,實際上我認(rèn)為即便是做了驗收,也無法徹底解決數(shù)據(jù)不準(zhǔn)確的問題,因為會有數(shù)據(jù)污染的問題,單次驗收僅僅只是個例,而數(shù)據(jù)污染可能是個普遍性的問題。
從實踐經(jīng)驗來看也是這樣,大部分小廠都無法解決數(shù)據(jù)的準(zhǔn)確性問題,數(shù)據(jù)污染問題比較嚴(yán)重,如果是大廠那么就會相對好很多。
數(shù)據(jù)污染產(chǎn)生的原因比較復(fù)雜,可能的原因是采集的時候就不對,或者提需求的時候不夠準(zhǔn)確。大概率會需要一個逐漸修復(fù)的過程,而且是一個相對長期的過程。所以如果發(fā)現(xiàn)數(shù)據(jù)不準(zhǔn)確的話不要慌,一點(diǎn)點(diǎn)修復(fù)就行。說實話其實急也沒用,這種就是需要花時間做的東西,表面看不到的才更花功夫。
另外,如果說技術(shù)部門愿意做全埋點(diǎn)的話就不需要產(chǎn)品額外提數(shù)據(jù)需求,如果是這樣,那么必須感謝他們,因為他們?yōu)槟惚A袅烁嗟念^發(fā),不至于禿的那么快,頭發(fā)就是生命啊。
最后說一下并不是所有的公司都需要自己做數(shù)據(jù)這塊的,如果公司的業(yè)務(wù)還處在比較早期的階段,那么使用神策、Growing IO這些三方數(shù)據(jù)公司的產(chǎn)品也是一個比較好的選擇。畢竟這東西做起來耗時耗力,如果不準(zhǔn)的話頭會很痛。
以上是對數(shù)據(jù)埋點(diǎn)方面的分享,下回分享一下數(shù)據(jù)統(tǒng)計報表方面的內(nèi)容,算是做個銜接。
本文由 @代號道長 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自?Unsplash,基于 CC0 協(xié)議
- 目前還沒評論,等你發(fā)揮!