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

上半部分文章主要圍繞指标，包括選定關鍵指标（主要指标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 協議

,