編輯導語：在進行資料分析之前，需要先進行一些階段性的準備工作，先拆解好指標，再進行後續做功能與打點取數。作者從怎麼分析資料結果、怎麼作出直觀的圖表和指標的持續監控分享如何設計打點和實驗。

上半部分文章主要圍繞指標，包括選定關鍵指標（主要指標VS次要指標），從關鍵結果指標拆解出過程指標，並定下階段性目標。

這些是資料分析的基礎工作，在沒有做好之前，不建議直接就開始做功能、打點取數等等。如果這部分已經做好了，那麼可以看接下來的文章（如果沒有建議戳上半篇）。

接下來講一下有了指標之後到底怎麼去設計打點和實驗，包括怎麼分析資料結果、怎麼作出直觀的圖表和指標的持續監控，還是比較實用的技能。

一、設計打點詳解

打點和實驗是同步設計的，因為這兩者會互相影響。有些童鞋對DAU、交易額、轉化率等大指標監控比較重視，但是拆分到某個頁面、某個功能的打點就設計得大條了一些，導致經常要等資料結果出來了，才發現還需要補一些打點。

所謂巧婦難為無米之炊，如果打點沒打好，連資料來源都沒有，資料分析能力再強也沒用。

打點分為前端（客戶端）打點和後端（服務端）打點兩種。

先介紹常用的前端打點，這類打點主要是用來記錄

使用者行為

的，也就是當用戶和你的頁面產生了互動之後（比如點選了某個按鈕或者打開了某個頁面），本地產生一條包含很多欄位的資訊（相當於xls的一行），等到一定的時間之後上傳到伺服器上，然後透過資料清洗、入庫等等，就能提取出來進行資料分析了。

前端打點必須包含的欄位型別（相當於xls的表頭）有以下三大類：

1。 基礎資訊

比如使用者的

渠道、平臺、作業系統、手機型號、使用者身份唯一標識（uuid、token）、頁面id

等等，以便後續做一些基本的分析。

也可以再進一步，根據業務特性加上一些欄位：比如一個LBS的App可以把城市、經緯度也加到基礎資訊中，比如一個交易平臺可以把使用者瀏覽商品的sku id或下單的order id帶上，只要使用者有和商品id、下單相關的操作，這兩個欄位就都可以記錄上。

這麼做的好處是不需要產品/運營每次額外提需求，預設每條打點都會帶上這些欄位，這樣不容易漏。

2。 事件資訊

事件也就是使用者的一次操作行為，是前端打點中最重要的部分。

首先，我們要給每個事件起一個

唯一的名稱

。

比如使用者和banner發生了一些不得不說的互動（比如點選），這個事件可以叫“banner”，有些公司用的是隨機生成的字元比如“5x_aswed”，看上去像是貓咪在鍵盤上隨便按的，也有些公司用的是中文名稱比如“中通”（不是快遞，是中間通欄的意思），這個不打緊，只要是唯一標示都可以。

其次，我們需要（一個欄位）記錄

這次操作的型別。

一般來說有這4種：頁面/模組

載入→

模組

展示

（載入完畢）

→

模組

點選→

提交

成功。

比如使用者開啟某電商App首頁，這時候首頁已經開始載入了（1），過了0。01秒之後首頁的banner載入完畢且第一幀展示在使用者的面前（2），然後過了2妙輪播到第二幀（3），使用者點選第二幀（4）。

這其中（1）就是載入事件，（2）、（3）都是展示事件，而（4）是點選事件。

這時候（4）的UV/（3）的UV才是第二幀banner的UV轉化率，而不是（4）/（1）或者（4）/（2），因為發生（1）和（2）事件時，這一幀banner根本沒有展示在使用者的面前。

截圖摘自淘寶App

那麼提交事件是什麼時候記錄的呢？

因為點選banner之後會直接進入活動landing頁面，所以不需要記錄提交。

但在某些情況下，比如使用者在某件衣服的商品詳情頁點選了“領券購買”，彈出了選顏色和選尺碼的半窗，此時使用者再點選半窗上的的“領券購買”（5），會出現一個請選擇尺碼的提示，選好了之後，再點選“領券購買”（6），這才“購買”的這個行為

成功地提交

了，此時系統還會進行一個自動領券的操作，然後推進到下一個頁面（7）。

所以這時候（5）是點選事件（點選了，但是沒有成功提交），（6）才是提交事件。如果選擇顏色、尺碼的樣式沒設計好，就會導致點選

→

提交的轉化率不佳，所以只記錄點擊顯然是不夠的。

截圖摘自淘寶App

那麼有些童鞋可能會問，那直接看下一個頁面的UV，也就是（7）的展示量不就行了嗎？

其實也不然，如果網路不佳會導致使用者沒有推進到下一個頁面（特別是在雙十一的時候，網路擠爆了），所以從上個頁面提交（6）

→

下個頁面載入（7），當中還可能漏掉一部分使用者。

因此在這種情況下，提交的事件型別就很有必要了。當然，這種情況相對複雜，大部分時候我們記錄頁面的展示、模組的展示和點選，是夠用的。

最後，除了事件名稱、事件型別，我們要記錄一些事件相關的

附加資訊

。

比如剛剛說的banner的第幾幀，如果每一幀都作為一個獨立事件重新命名，那就非常麻煩了（比如banner_1，banner_2……萬一有10個banner呢）。

這時候我們再加上一個欄位index，在banner展示和點選的時候都記錄下一個額外的數字，比如1、2、3等，用來記錄第X幀（當然程式設計師小哥哥/小姐姐可能會和你說從0標起）。

如果banner在某段時間裡面是不固定的，或者千人千面的，比如小明在第一幀看到了減脂餐的banner，小剛在第一幀看到了連衣裙的banner，那我們可以再記錄一個欄位title，把banner的活動名稱記錄下來，那麼小明點選banner就會產生事件名稱“banner”，事件型別“click”（點選），index“1”，title“減脂餐”這四個欄位了。

3.

歸因資訊

只記錄基本資訊和事件資訊，還是沒有辦法統計出在文章上半部分提到的——根據路徑（比如首頁不同的模組）去拆解訪購率（下單UV/模組訪問UV），因為我們知道使用者下單的前一個頁面是商品詳情頁，再前一個頁面可能是商品列表頁，但並不知道使用者到底是不是從首頁的哪個入口進來的。

當然，你可以去近似，比如點選過banner的使用者在X分鐘內訪問了商品詳情頁，但是這個時間是很難把控的，導致不夠精準。

這時候我們需要加上一個歸因資訊的欄位，也就是標識出使用者的關鍵行為到底是透過哪個路徑產生的。

比如我們可以把某橘色電商App的模組簡單分為搜尋框、icon位、運營位、輪播banner、猜你喜歡等，那麼我們需要一個欄位來記錄本次購買到底是哪個模組帶來的。

原理其實也很簡單，就是在使用者從每個模組點選到下一個路徑的時候帶上這個欄位就行了，比如使用者在點選了banner之後可能會進到各種類似的頁面，不管是活動頁、商品詳情頁還是店鋪頁，只要使用者產生任何互動（只在關鍵的頁面記錄也可以），我們就把使用者“banner”這個資訊記錄在歸因的欄位上，直至最後下單。

如果使用者在下單前，又回退到了其他首頁的模組，比如點選了搜尋框，那麼同理，我們只需要在這個時候把“搜尋框”之後的任何使用者行為（直至下單）都在歸因欄位記錄下“搜尋框”就行了。

這樣，我們就可以分析出，首頁各個模組的訪購率到底是什麼水平了。

前端的打點介紹得差不多了，後端打點一般是在伺服器的一些技術打點，比如用來統計95線、98線、端到端響應速度等效能，一般策略產品會接觸得多一點（比如搜尋產品），原理也是類似的，在使用者和服務端發生互動的時候做記錄。

如果前端打點的資料取出來非常難以置信，但是研發小哥哥/小姐姐又覺得“我這裡是好的”，那麼除了請喝TA奶茶之外，也可以前後交叉對比下，比如我們把支付提交成功的前端打點和伺服器收到支付成功請求的打點做個對比，誤差如果穩定在百分之幾的話，那麼基本上沒有問題啦。

講了這麼多，學姐再舉一個栗子加深印象吧，看一個列表頁功能打點的文件，為了閱讀方便，打點就都用中文寫了。

*除了基本資訊不需要贅述外（包括使用者手機型號、平臺、頁面id等等），在每次使用者提交的時候我們還會記錄一個Query_id，用這個id可以去服務端的日誌中檢視本次搜尋的詳細情況（相當於後端打點），包括各種使用者本次搜尋的各種輸入資訊和我們輸出給使用者的資訊（比如到底展示了哪些商品等等），用於後續搜尋策略的最佳化。

總之，打點要有詳有略，既能保證使用者的每一個步驟的重要資訊都要能有效提取到，又要善於巧用單獨的欄位來減輕後續資料分析的工作量。

另外，打點設計完之後，別忘了和相關同事（運營、BI等）確認是否能滿足所有想看的指標，不同崗位關心的指標會有側重點不同，大家要確保萬無一失哦～

二、 科學設計實驗

有了打點之後，我們可以統計到一些功能的詳細資料，用來驗證這個功能/專案對關鍵指標是否真的有幫助，或者是否還有提升的空間。

影響關鍵指標的因素是很多的，比如節假日、淡旺季、廣告投放等等各種情況，所以我們還需要對想要分析的專案設計“實驗”來獲取更精準的資料，常見的有以下幾種方式：

1. A/B測試

這類測試比較適合

資料隨時間波動較大

的垂直類目，比如快消、服裝品牌等。

A組就是空白組——原方案，B組是實驗組——最佳化後的方案，這樣做為了要排除季節、突發事件、新的商品、宣傳活動等等各種情況對產品資料造成的波動。需要注意兩點：

確保流量切分的時候儘量是均等的，一段時間內，A組和B組的UV/PV幾乎相同，這個誤差如果接近10%，實驗的可信度就會大大降低，說明在分流量的時候有bug。

確保流量切分的時候不存在任何使用者畫像上明顯的差異。比如A組女性更多，B組男性更多，就會影響實驗結果。很多時候程式生成的“隨機”其實是偽隨機，所以一定要警惕切的時候並沒有做到真正的隨機。

如果試驗結果看上去比較異常，我們可以做AA實驗來確定下資料的準確性，即A組和B組都用原方案，來看下資料是否相同。

2. 灰度測試

灰度釋出和A/B測試的原理相同的，但是流量不會均勻分配，一般是切某個比例的流量給到B組，比如5%，10%等。

比較適合量級大、有影響力的核心頁面

，比如淘寶首頁改版就會小範圍先切一部分流量做灰度測試，這也很適合淘寶這樣強運營的App。

運營可以透過灰度測試的結果對策略進行調整，避免直接全量上線影響整個App的指標。這種方案適合有一定研發能力的平臺，因為對流量的切分提出了更高的要求，所以大廠用得更多一些。

3. 直接發版

直接進行釋出新功能/新版本，分別看老版本和新版本的資料，計算某個固定時間段內平均值的提升。直接發版適合資料比較穩定的平臺，且對釋出的產品功能很有信心。

比如產品之神張小龍就很少搞什麼A/B測試、灰度測試啥的，很多改版就是直接上（比如微信7。0神馬的），當然我們都不是產品之神，如果不能確保這段時間資料比較穩定的話，還是乖乖做AB或者灰度先～

如果是透過更新客戶端來進行版本釋出（服務端釋出、小程式等不用考慮），要注意

等新版本覆蓋大部分使用者了之後再看資料會比較準

，因為先更新的使用者往往是對平臺比較忠誠的使用者，只看這部分使用者，資料會偏高。

比如我們發現新版本釋出後兩週，80%的使用者都更新完了，那麼就可以對比新版本釋出前老版本1個月資料的均值，和新版本釋出之後第3周到第7週數據的均值（也是1個月），來進行對比。

其實像微信出的“炸shi”之類的小彩蛋，其實很多時候是為了去催促使用者更新到新版本～

三、分析資料結果

經歷了設計打點和實驗，又等待了一下版本更新覆蓋率之後，我們終於取到了資料，然而結果往往充滿了驚喜（嚇）。就算資料非常符合預期，在彙報的時候有資料和圖表的那幾頁往往需要費勁去解釋。下面就教大家比較實用的幾招，從此彙報資料無煩惱。

1. 排除干擾項

說到彙報資料，往往是資料跌了慘兮兮，資料漲了又要趕緊解釋原因，不然等到下週環比跌的時候又要解釋了。

記得之前學姐遇到過幾個月DAU瘋漲，當時分析了半天沒找到原因（當然現在知道啦），當時老闆打趣說唯一的變化就是前任老闆離職了，可以說是甜蜜的負擔了。

資料總是有這麼多幹擾項，像玩劇本殺一樣，我們會發現很多看上去可疑的線索，其中大部分都是干擾項，要排除這些才能找到真正的“兇手”。

比如學姐的一個童鞋小超因為好玩做了一個扔手機的App（不建議大家下載，很費手機），這個月突然發現App中廣告的曝光量跌了三分之一，收入也隨之跌了。

仔細一看，發現不是這個月跌了，而是上個月有幾天資料猛漲。

再進一步拆解，發現是某個安卓商店的下載量在那幾天激增，於是發現自己的App在那幾天被這個安卓商店推薦了一下下。排除這幾天後，資料看上去就這麼誇張了。

大家在分析資料時，最直接的就是先按照時間畫出資料曲線，看看有沒有異常的點，把異常點排除之後再去看資料。

定位了時間段（點）之後，就像鎖定了“殺人兇器”，接下來只要找到是誰使用的就行了。

我們可以進一步拆解（不知道怎麼拆解的可以看文章的上半部分），看是否有天氣、城市、渠道、廣告、銷售、其他產品功能、運營活動等等各因素的影響，當然這些因素和業務有關，如果你完全沒有頭緒，可能需要更進一步去了解業務了（比如問問相關部門的同事）。

技術原因也會影響到產品資料，比如某個伺服器在某天的超時的訪問特別多，那自然會影響產品的轉化率了。

如果這些因素都沒有變化，我們可以更跳脫去考慮，比如是否有政策、人口、經濟是否對整個行業的大盤產生了影響，從而進一步影響到了自己的業務。

2. 選擇最直觀的圖表

自己好不容易推理出了“真兇”，但是一起玩劇本殺的小夥伴竟然沒聽懂你的推理，還反手投了你？

這就和分析完資料之後，覆盤彙報時同事不能理解這些資料一樣苦惱。到底選擇什麼樣的圖表來表達資料才能做到清晰、高效？

開啟Excel我們會發現有N種圖表（截圖有點醜大家不要介意），咱就講幾種常用的：

（1）柱形圖&條形圖

柱形圖的一般用於表達某個指標隨著時間（或者某個變數）的變化，比如每個季度的銷售額、MAU均值等。

如果變數的文案比較長，我們也可以用橫過來的條形圖去呈現（柱子之間文字太多擠不下），比如首頁每個模組的點選率。

總之，柱狀圖更強調趨勢變化，條形圖更強調比較（左圖的單位是萬，忘記標註了，下同）。

左圖為柱形圖，右圖為條形圖

（2）柱形圖+折線圖

折線圖和柱形圖類似，也強調趨勢變化。

一般用於更細的資料，比如分天、分小時的資料，MAU按照每個季度平均一下還能用柱形圖，但是如果過去一個季度DAU的資料，那用柱狀圖肯定就畫不下了，這時一般就用折線圖了（比如上面一章提到的分天曝光圖）。

既可以表達絕對數值，又可以表達出趨勢，學姐個人還蠻喜歡的。

比如兩年內

每個季度的MAU均值（柱狀）和其年同比（曲線）

，這樣我們不僅可以看出每個季度數值和變化趨勢，也可以看出年度的變化趨勢。

（3）餅圖

強調佔比。比如我們要統計不同路徑下單量的佔比，這時候就可以用餅圖了。很多童鞋在這個時候還是用普通的柱形圖/條形圖，這樣不如餅圖直觀。

(4）漏斗圖

顧名思義在表達漏斗的時候比較好用。比如對比新使用者和老使用者（或者不同渠道、平臺等）在開啟App→商品詳情頁→下單成功每個漏斗的UV，不過轉化率需要自己標註下，學姐覺得這圖和直接用表格的直觀程度其實也差不多。

如果是表達兩類使用者轉化漏斗的對比，倒還不如用兩個條形圖拼一起（左邊這個需要選中兩個座標軸然後對刻度線選擇逆向類別）。

稍微複雜一些的圖表其實也就是一些基本圖表的組合，比如百分比柱形圖，有鄰居的柱狀圖等（官方名字是簇狀柱形圖？好拗口），大家可以根據需求去選取。

比如我們要表達每個季度的運營成本，和各項成本佔營收的比例時（比如市場營銷成本、研發成本、行政管理成本），就可以用前者，強調趨勢+佔比；表達兄弟部門每個季度銷售額PK的時候，就可以用後者，強調趨勢+對比。

摘自B站財報

兄弟部門業績PK圖表舉例

選擇圖表型別有點像 “互動”，那麼學姐再分享幾個作圖的小技巧，相當於圖表的“視覺”，可以有效提升溝通效率：

（1）適當標註

預設的圖表設計很高階，完全沒有數字，但是我們為了要彙報的效率，還是要把關鍵的資料標註上去，比如交易額、DAU、同比等。

另外，文字也要儘量標得清晰，比如餅圖的預設樣式經常是把圖例標註在餅圖下方，這樣看起來很累，而且投屏的顏色有變化或者圖例的顏色很像，很容易對錯，可以選擇文字直接在餅上的樣式。

（2）強調重點

如果某個資料很出彩或者需要重點關注，我們可以把相應的數字加粗加大，比如餅圖的某塊餅就可以單獨放大，比如柱子的顏色改一改，就能成功引起大家（老闆）的注意，摘自B站財報（每季度增值服務營收），猛男粉太醒目了叭。

摘自B站財報

（3）座標軸範圍合適

預設的座標軸經常會最小值不是零，而且座標值最大值比我們資料的最大值大很多。

好的座標軸應該是從零標起，並且最大值只是略大於我們資料的最大值，這樣不容易放大資料波動，並且又能在把圖表的柱形或者條形展示得比較清晰。

如果有特殊情況要用某個非零的數字作為座標軸的起點，一定要非常謹慎地標註清楚。

（4）備註口徑

每個公司都對不同指標都有不同的定義和叫法，一般比較明確的指標我們不需要額外備註，有些用得少的指標我們還是要把計算口徑標得很清楚，包括數字從哪裡取來的、時間段、版本，計算公式等等。

來，學姐給一個圖表的Before & After效果圖，當然如果不需要強調2020年的資料就不需要像學姐這樣把柱子的顏色改成紫色了（低調一點～）。

左圖為預設圖表，右圖為最佳化後

四、持續監控——資料產品的型別及其適用場景

其實從打點到分析結果之間，還有一個步驟是

使用資料產品取數

。

不同的資料產品的適用場景不同，這幾年“資料產品經理”這個概念也蠻火的，可見其重要性。雖然我們不是專業的資料產品和BI，不過為了日常資料分析工作可以順利進行，我們需要對一些指標進行重點監控，所以也需要了解資料產品的基礎知識。

常見的資料產品有這幾種型別：

（1）SQL語句

想怎麼查數就可以怎麼查，適合低頻個性化需求，比如某個新功能上線之後，往往會把資料看得詳細一些，以便更全面瞭解功能的使用情況。

缺點是容易存在安全隱患，比如有一些機密、敏感的表格不適合給全部產品開放許可權，比如公司內部人員的薪資、年齡，使用者的電話號碼、其他部門的營收等等。

所以在大公司往往會花精力去搭建一套比較完整的許可權體系，避免洩漏商業機密。

有些產品童鞋不太會寫SQL，學姐建議大家可以買本大學的SQL教科書看看，跳過建資料庫這一塊，直接學習一些常規的查詢就好了（基本的Select from，join之類），這樣方便自己直接去查資料。

（2）取數工具

就是把某些中頻使用的SQL查詢語句固化下來。產品可以自己輸入日期範圍、類目等去查詢交易額等。

如果不懂SQL的產品可以找BI或者BA幫忙寫一個取數工具，自己定義一些可以輸入的欄位就行了。

（3）視覺化後臺

適合一些中高頻監控的過程指標、常見的路徑漏斗等，在靈活度方面稍微欠缺一些，但是勝在可以輸出圖表，易操作、直觀，是大家比較常用的。

除了大廠是自研的資料品臺之外，很多公司用的都是第三方提供的視覺化資料後臺。

（4）自動化報表

適合高頻監控的關鍵結果指標和過程指標，一般會用表格或圖表的形式每日自動傳送至郵箱或IM。

包含環比、同比、MTD（本月到今天為止）等，方便大家及時發現數據波動，避免大家做月報、週報的時候看到想半天不知道問題出在哪兒。

當然，這種日報模版調整頻率會更低一些，因為監控的都是最關鍵的資料。

關鍵指標以每日為維度監控只能發現一些產品、運營、銷售相關的波動（比如跌了百分之十之類的），如果遇到一些技術性的問題，可能資料一落千丈，等到第二天才發現就已經讓公司損失幾個億了。

所以一般還會對關鍵指標有實時監控，比如過去一小時內，訂單量比上週同期跌掉一半，就會報警發到手機上，這樣及時發現線上bug。

作者：海貝學姐；公眾號：海貝學姐

本文由 @海貝學姐 原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基於 CC0 協議