国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

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

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

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

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

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

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

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

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

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

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

上面說了這么多，那我們就正式的來說每一步吧~

「埋點原理及方式」

首先是關于埋點的概念，畢竟做啥事能明白其中的原理還是很重要的。

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

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

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

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

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

代碼埋點一旦存在問題進而會引發(fā)什么問題呢？

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

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

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

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

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

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

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

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

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

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

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

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

但全埋點也繼承了可視化埋點的所有缺點，所以這種的埋點方式同樣也無法做到全面普及。

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

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

對于客戶端埋點的優(yōu)點和缺點基本上就是上面介紹的那些，這里相比于服務端埋點存在的另一個缺點是數(shù)據(jù)上報有延遲且會存在漏報的情況。

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

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

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

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

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

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

「埋點流程」

首先是非規(guī)范性流程，比如一些創(chuàng)業(yè)公司和小公司因為公司處于發(fā)展初期或業(yè)務對數(shù)據(jù)的依賴性不是太強的時候一般整體的埋點流程就會隨意一些。具體流程參見下圖：

如上面這張圖當公司無埋點工具或數(shù)據(jù)平臺時，埋點流程則相對人工化。

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

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

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

一般隨著公司的擴大和流程的規(guī)范，數(shù)據(jù)平臺的建立將大大的提升埋點流程的規(guī)范性、時效性。具體參見下圖：

相比于無數(shù)據(jù)平臺的埋點流程，一旦有定制化的數(shù)據(jù)平臺，埋點流程將變得完全不一樣。

此時，仍是PM提出埋點需求但是整個流程將收歸至線上，即PM將高保真的頁面記錄在數(shù)據(jù)平臺，并在數(shù)據(jù)平臺自動生成埋點名稱及任務推送給對應的RD，RD將根據(jù)由平臺定義好的埋點名稱和參數(shù)寫入對應的代碼中。

此外數(shù)據(jù)平臺還支持測試埋點，即PM可通過數(shù)據(jù)平臺在發(fā)版前安裝測試包測試埋點信息是否存在和正確性，極大的降低了風險性。

后續(xù)的數(shù)據(jù)可視化也直接在數(shù)據(jù)平臺查看，甚至能查看實時的數(shù)據(jù)大盤，諸如某個時間點的日活，訂單量等。

擁有定制化的數(shù)據(jù)平臺在埋點名稱的管理和維護方面將更加靈活且自動化，特別是對于擁有多條業(yè)務線的公司來說更是必不可少。

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

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

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

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

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

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

「答疑」

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

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

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

A：上面的流程中更多是埋點的業(yè)務流程，真正的數(shù)據(jù)流程包括數(shù)據(jù)采集、數(shù)據(jù)上報、數(shù)據(jù)存儲、數(shù)據(jù)加工、數(shù)據(jù)輸出等幾部分。

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

A：按照采集位置可分為客戶端「交互行為」數(shù)據(jù)和服務端「接口請求」數(shù)據(jù)?？蛻舳藬?shù)據(jù)包括頁面的展現(xiàn)、控件點擊、停留時長等，服務端數(shù)據(jù)包括請求狀態(tài)、請求結果等。

Q：哪些原因會導致統(tǒng)計的數(shù)據(jù)不準確？

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

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

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

Q：數(shù)據(jù)有問題，可以找哪些同學解決？

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

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

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

作者：我呀way ；個人公眾號：鄭重心流，歡迎來撩~

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

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