數據反饋，不僅能驗證我們的產品是否符合市場的預期，而且還能為我們優(yōu)化產品，迭代產品提供需求，建立產品的優(yōu)化飛輪。

因此，數據分析是形成整個產品工作閉環(huán)中，必不可少的一環(huán)。 

去年我們團隊上線了一個新的產品，上線后，由于一直招不到合適的數據產品經理，因此團隊讓我先暫時支持下數據產品的基礎工作。

于是，在這期間，我成了半個數據產品，在支持了一段時間的數據工作后，也建立了對數據的基本認知。

所以今天，我先從埋點開始，介紹下數據埋點工作過程中要了解的要點，同時補充介紹下，在數據分析工作中，可以直接應用一些分析框架和工作方法。

01 埋點與事件管理

1、什么是埋點、事件、參數 

埋點，是通過在程序中植入代碼的方式，記錄用戶在軟件（web、app、小程序）上的操作行為的技術手段。

事件，是記錄用戶在軟件中操作行為的標簽，如，用戶在首頁的曝光事件、按鈕的點擊事件等。

而在事件中，為了進一步區(qū)分事件的范圍，更好地進行數據分析，會增加事件的“參數”，用來框定某個范圍內的數據。如，時間參數、城市參數，就是用來篩選某個區(qū)間內事件上報數據的。 

假如，我們要看到3月20日的產品首頁曝光人數。

我們首先可以在首頁中增加帶有“時間”參數的“曝光”事件埋點。 

在查詢時，可通過代碼在數據庫中找到“首頁曝光”這個事件，并在時間上選擇“昨天”這個時間參數。 

就可以得到昨天在首頁曝光的用戶數。 

2、事件分類

事件是通過用戶在軟件中留下的痕跡，來進行統(tǒng)計和上報的。

因此，從用戶痕跡獲取的維度上來看，事件可分為：基礎事件和行為事件

（1）基礎事件是用戶的屬性標簽，可用來建立用戶畫像的。如，用戶id、城市、地址、年齡、經緯度、設備、ip地址、運營商、網絡等信息，都屬于基礎事件。

（2）行為事件就是用戶在軟件上的行為標簽。如，曝光pv/uv、點擊pv/uv、停留時長等，都屬于行為事件。而根據用戶操作的行為，行為事件又可進一步細分出以下三類： 

• 點擊事件。指用戶在軟件中的點擊，如用戶在某個按鈕、某個功能的點擊，都記錄為一次點擊事件；

• 曝光事件。指用戶打開頁面的行為，如用戶在某個頁面上曝光一次，記錄為一次曝光事件；

• 頁面事件。指用戶在頁面中的操作，如，通過統(tǒng)計A用戶在B頁面停留時長；

3、埋點的方式

介紹完事件分類之后，我們再來看下埋點的兩種主要方式：

（1）私有化部署，全部功能都自己開發(fā)，在代碼中寫入事件和上報邏輯，并搭建起相應的查詢后臺，埋點后，事件上報到對應的平臺即可進行可視化呈現。 

私有化部署的優(yōu)勢是：數據安全性高；且可根據業(yè)務需要，定制埋點邏輯；

但缺點也同樣明顯，就是不論是埋點開發(fā)還是可視化平臺的搭建，所耗費的成本都比較高； 

所以，一般只有大廠或相對成熟的產品，才會選擇私有化部署的方案。

（2）第三方統(tǒng)計工具，如使用友盟、神策等平臺工具進行埋點、統(tǒng)計和上報。 

這么做的話，優(yōu)劣勢和自行開發(fā)剛好相反：通用化的方案，帶來的結果是可自定義程度低，但成本也會相對較低。 

所以，一般中小型企業(yè)或新產品，都會選擇此方式，滿足業(yè)務的基本數據訴求。 

4、埋點工作流程

從工作流程上來說，埋點需要業(yè)務方先從拆解需求核心流程開始梳理，提出埋點需求；

開發(fā)團隊根據埋點邏輯進行開發(fā)，開發(fā)完成后，測試團隊進行上線前的測試；

上線之后，產品將數據的事件維護到表格中，而后，業(yè)務方才方便根據反饋的數據，定義數據，進行數據分析或可視化呈現。

因此，埋點也是數據采集和分析的基礎。而在埋點開發(fā)到上線過程中，我們要注意以下幾點：

（1）埋點方案，要保證埋點需求的合理性

隨著數據維度的健全，所需的數據量也增大，因此需要埋點的事件也會越來越多，這是必然的趨勢。 

但因為埋點的本質是代碼中加入代碼，因此如果埋點的事件增多，也必然會導致軟件加載速度變慢，影響用戶體驗。 

所以，埋點需求一定要仔細審核，否則就是給后面工作挖坑。 

因此，一般我在收集埋點需求時，都會讓業(yè)務方在文檔中盡可能明確的闡述，每一個埋點的意義和價值（尤其是曝光事件），否則不予上報。

以此來減少產品代碼壓力，提升產品使用體驗。

（2）埋點測試，驗證每一個埋點和參數的上報情況

測試，是保證需求上線后能夠正常運轉的最后一道關卡。

所以埋點開發(fā)完成后，除了測試要驗證埋點是否上報上報之外，產品人也必須親自確認，看數據是否正常上報、相關參數是否正常加入埋點。 

（3）事件管理，要建立建全的統(tǒng)計維度

在埋點需求上線之后，我們也要建立事件管理的表格，以便后續(xù)在進行數據分析時，快速得到數據源

如上圖所示，我們團隊就是用表格中的這幾個維度，來對所有事件進行維護和管理的：

• 場景id和場景名稱：在哪個頁面執(zhí)行的埋點——id是代碼層面的統(tǒng)計，名稱則是后續(xù)查詢的時候方便識別；

• 位置id和位置說明：在頁面中的哪個位置寫入埋點上報事件；

• 行為id和行為說明：主要是曝光、點擊、停留時長等行為，用來區(qū)分用戶的操作；

• 事件英文和事件中文：埋點的具體事件名稱，我們一般是“場景”+“0”+“位置”+“0”+“行為”；

（除了“0”之外，也可以用“_”來連接，但不可用“-”，因為代碼無法識別這個字段）

• 參數（key）：用來進一步區(qū)分當前事件下的不同維度，如表中所示，time代表時間——用來區(qū)分這個事件下曝光時間點，city代表城市——用來區(qū)分這個事件下的城市維度； 

通過上述方式對事件進行管理之后，團隊成員就能在文檔中，快速查詢到對應事件。

（4）事件更新同步 

事件都寫入維護表格之后，還有很重要的一步，就是一定要和各相關方，尤其是和業(yè)務關聯的核心產品或運營團隊，同步上報事件邏輯。

否則，在一定時間內，你的工作重心就變成天天幫他們找事件，解釋每個事件意義...

一般在版本發(fā)布后，我們團隊產品、研發(fā)和運營都會組織個上線會，同步版本新增功能，而我一般也會趁這個機會，給大家同步數據事件的更新情況。

在埋點正常上報之后，我們就需要通過定期查看上報數據，來判斷產品的數據表現情況。

1、核心指標：北極星指標 

在進行數據分析之前，我們得先了解產品的核心指標，也就是“北極星指標”。 

北極星指標，是產品在某個階段內最關鍵的唯一指標，因為它像北極星一樣指引著前進的方向，通過它能反映當前團隊對產品核心價值的追求的指標。

因為每個團隊業(yè)務不同，要關注的核心數據也不同。 

如，電商產品，北極星指標或許是交易筆數，又或許是成交量；而社交產品，北極星指標是活躍用戶數； 

所以，北極星指標的制定，通常是由數據團隊，產品團隊，運營團隊共同定義出來的指標。

并由此出發(fā)，進一步量化，并最終拆解成各團隊的業(yè)務考核指標。 

所以說，我們在工作中，也需要要時常關注團隊的北極星指標，以此來判斷我們的工作方向是否正確。

除此之外，同行業(yè)的產品在不同的發(fā)展周期，要關注的核心數據也會有所不同。

業(yè)務前期，目的是搶占市場，所以，業(yè)務要關注用戶對產品的認可度，此時的北極星指標可從產品的使用量出發(fā)。

如，在微信上線初期，北極星指標是每日成功發(fā)送的消息數。 

業(yè)務中期，目的是為了驗證產品能否解決用戶需求，所以，業(yè)務更應該關注用戶結構，優(yōu)化用戶結構，此時的北極星指標可從用戶活躍度出發(fā)。

如，Facebook就曾把月活躍用戶數，作為北極星指標。

業(yè)務后期，目的是變現能力和市場份額，所以，業(yè)務核心是要關注產品轉化量和收益，那此時的北極星指標，就可從營收情況出發(fā)。

如，愛奇藝當前的北極星指標，就應該是付費會員數；

2、發(fā)現問題：異常數據排查四步法

在產品基礎數據能力搭建完成，且業(yè)務團隊也定義了本階段的北極星指標后，產品人要養(yǎng)成查看數據的習慣。

首先先關注產品每日核心數據是否出現異常，并嘗試分析定位問題，這樣才能及時發(fā)現產品問題，找到產品突破點。

剛支持數據業(yè)務時，我經常被我領導diss。

主要是因為我在定位異常數據時，沒有掌握系統(tǒng)的方法，不能及時解決問題，導致產品隔三差五就會被用戶投訴。 

而在我定位了數十次數據問題后，終于總結出一套異常數據定位的方法論，主要分為以下四步：

（1）確認數據異常情況

如果有人告訴你說某個模塊數據出問題了，叫你排查，一定要先自己核實數據異常情況，千萬不能人云亦云。

其次，我們在定位問題時，要先嘗試初步判斷問題產生的原因。

可以先拉長時間維度，看是否是行業(yè)的淡旺季導致產品周期性變化，還是真的是產品數據出現異常了。 

所查看后，確認是近期才發(fā)生的數據驟增或驟降的情況，我們再從宏觀、中觀、微觀三個層次逐步排查。

（2）宏觀社會因素：假期、政策影響

宏觀的社會效應，是由于大環(huán)境的變換影響整個行業(yè)，導致產品數據突增或突降，如：

• 假期效應：國慶節(jié)，導致全國用戶出行暴增，從而導致攜程等旅游產品用戶數據暴增；

• 政策影響：深圳政府7.15房地產制度，提出購房指導價，對整個深圳的房地產都產生了不小的沖擊，進而導致貝殼買房app在2020年7月16日用戶訪問數據下降；

（3）中觀市場因素：熱點事件、大型活動、競品調整、城市因素 

中觀的市場因素，是由于行業(yè)變化或短期市場波動導致的，如：

• 熱點事件，今年315點名簡歷問題，導致智聯、獵聘等平臺品牌受損，用戶訪問量下降；

• 大型活動，雙11、618等活動導致電商平臺影響；

• 競品調整，競品上線新功能或新的運營能力，如愛奇藝上線超前點播功能，對優(yōu)酷、騰訊視頻用戶產生影響；

• 城市因素，如某城市突降暴雨，導致該城市打車用戶突增，滴滴的產品數據也猛然上漲；

（4）微觀內部因素：產品功能更新，運營策略、數據分析邏輯通路

如果宏觀和中觀都排除之后，通常就是產品本身出現了問題，如：

• 產品版本迭代，產品上了新功能模塊，導致某頁面訪問用戶增加或減少

• 運營策略，如運營做了產品推廣策略，導致一段時間內產品用戶突增，但運營沒有及時和我們同步活動的時間節(jié)點；

• 底層數據問題，如上報邏輯出錯，導致多渠道數據埋點未能正常上報；

根據數據異常排查的經驗來看，以上排查四步，可以有效解決90%的產品數據異常的問題。 

3、工作前置：建立告警

可在實際工作中，我們不能等同事發(fā)現并跟你提出了問題，才思考解決方案。

這樣不僅會打斷自己的工作計劃，而且無法從根本上解決問題。久而久之，我們就會變成整天忙于異常定位的救火隊員了。

所以，為了減少異常數據發(fā)展成更為嚴重的產品事故，也為了提高我們的工作效率，我們可以在產品的核心流程中，增加告警上報機制。

之所以只在產品的核心流程中設置，是因為如果告警太多，維護的開發(fā)遲早會麻木的。一旦麻木，就失去了設置告警的意義。

比如，可以在用戶支付流程中，對產生的報錯碼建立監(jiān)控體系。

我們團隊的規(guī)則是，當有大于5個用戶拉起微信支付失敗，即支付失敗報錯碼出現報錯次數大于5時，平臺就會出發(fā)告警，并觸達開發(fā)，讓開發(fā)去排查和定位問題。

從而減少由于小范圍的產品問題演變成影響大量用戶使用的產品事故。

4、鍛煉自己的數據感 

告警機制只能解決核心產品流程的問題，但產品的組成，除核心流程之外，還有很多其他的功能也需要我們時常關注。

所以，除了系統(tǒng)層面的解決方案之外，我們自己也要養(yǎng)成看數據的習慣。

數據感，是我們在分析事情，或說服他人的時候，都能用數據來證明自己的想法；在看到數據時，會去思考數據的合理性與準確性。

培養(yǎng)數據感和產品感一樣，都是需要我們長時間對數據的思考、沉淀和積累之后，實現從量變到質變的過程。

所以我們團隊也會要求每個產品人，每天都必須抽時間看看產品的數據表現，我一般是早上9點-11點的時候，看昨天的數據日報。

雖然說剛開始看數據時，數據工作確實是一個無聊且枯燥的工作。 

因為每天的數據無非就是突增、突降、正常，這三種情況，所以很多人會覺得很無聊。

可我們日常的數據分析就是要從這三種情況下，找到產品的優(yōu)化點和破局點：

如果是數據突增，產品要思考能否趁風而起，提升產品指標；

如果是數據突降，可以從更長時間周期進行分析，看是周期性環(huán)境變化、穩(wěn)步下降的產品原因、亦或是內部產品迭代導致的異常，進而提出優(yōu)化需求或策略。

即便是每天都一樣的數據，也能說明現在的產品策略，無法實現產品的穩(wěn)步增長，產品也可以進一步調整產品策略。 

因此，不論什么數據，都存在分析的價值和意義。

只有意識到這點，數據分析才算是真正入了門。