宏觀數據指標簡介（上）：「新增」與「卸載」究竟怎麼看
筆者基於自己工作中遇到的一些產品數據分析問題，與大家分享其對於數據分析的見解與感悟。期望以簡單易懂的文字讓產品數據分析小白，能通過改文章對數據分析有一定的瞭解。
一直想把產品工作中遇到的數據分析問題做一個系統的總結，但因爲種種原因一直沒有下筆。前些天詳細梳理了一番，打算通過幾篇文章將產品工作中的“數據分析”說清楚，文章儘量用通俗易懂的言語闡述。
對於這些文章，我心裏有一個小目標：讓一個毫無基礎的人，看了這幾篇文章也能對產品的數據分析有一個初步的瞭解。
廢話不多說，我們開始吧！
一、宏觀指標
宏觀指標會從：新增、卸載、留存、活躍，四個維度來進行介紹，當然每個維度又有具體的細分。
宏觀指標通常出現在數據面板（Dashboard）中，用於日常數據的監測，來判斷產品的異常與否。
因爲文章篇幅限制，本篇文章只會介紹前兩個指標：『新增』『卸載』，剩餘的部分會在接下來的文章裏面進行闡述。
二、統計的基本單位
在正式介紹數據指標之前，我們要明確一個概念：用戶數量統計的基本單位。
實際上，目前市面上常見的數據數據統計平臺，還沒有能力真正識別一個真正的人。
回顧一下國家是怎麼統計人口的：是爲每個人分配唯一的一個身份編號，這個編號不僅僅保存在戶口本與身份證上，還保留在國家的統計局裏。
但是，如果一個人有兩個不同的身份證號，其實從國家的角度來看，就是完全獨立的兩個人。
對於產品統計平臺來說，也是如此。
數據統計平臺也是通過爲用戶分配唯一編號的形式進行確認的，目前常見的方式有三種：
- 社會屬性賬號，例如：手機號碼，微信號，郵箱……
- 設備標識，例如：每個手機都有一個唯一的id，可以通過手機id來區分。
- 應用標識，其實每個應用也有唯一的一個id，這也可以用於區分不同的用戶。
不同的應用對於用戶單位的定義也不盡相同：對於擁有賬號體系的應用，一個用戶特指註冊的賬號，但是對於沒有賬號體系的應用，多數使用的是應用id作爲用戶數量的基本單位，而設備id通常作爲補充。
這裏補充一點：接下來所有的案例均以應用id作爲基本單位進行闡述。
在明確了用戶數量的『基本單位』後，我們正式進入產品數據核心指標的闡述部分。
所謂的核心指標指的是：能夠衡量產品狀態的數據標準。
通過這些指標就能很直觀的判斷：產品整體表現的好與壞，局部改動的得與失。
其中核心指標主要分爲兩類：宏觀指標與微觀/功能指標。
宏觀指標主要衡量產品的整體狀況，而微觀指標則能夠精準的呈現產品中某些功能的使用情況。
爲了方便，我們先憑空造出一個App，名爲：示例App。
接下來所有的數據指標都來源於『示例App』。
三、新增
新增顧名思義，指的是：沒有使用過示例App的用戶。
如果這用戶開始使用了，那麼該用戶便是示例App的一個新增用戶。
如果從職責劃分的角度，新增指標更多的屬於運營指標。因爲產品功能上的改動，往往對新增數據的影響不大。新用戶的獲取屬於流量獲取行爲，更多的的歸因於宣傳活動、廣告投放、產品ASO的優化等。
如果籠統的說新增這個指標，上面那段文字的描述就已經足夠了，但是如果你想細緻的瞭解，那可以從以下幾個維度進行細分：
1. 新增究竟是什麼
傳統行業中的新增用戶很好定義——就是個體的人。
例如：某個餐館開張，第一天來了100個顧客，那麼這一天的新增用戶就是100人。
但是對於手機App來說，這個維度就顯得有些粗了，舉個幾個例子：
- 用戶甲有兩個手機，並且都安裝了示例App，那麼對於示例App究竟甲算究竟作一個用戶還是算作兩個用戶呢？
- 如果在示例App能夠在一臺手機上進行重複安裝，用戶甲在自己的手機上安裝了兩個示例App，那麼又該怎麼算呢？
- 如果一個用戶甲第一天安裝了示例App，然後第二天進行了卸載，第三天又重新安裝了，那在第三天的時候，甲算不算新增用戶呢？
- 如果用戶甲第一天安裝了示例App，然後在第二天進行了升級/更新，那甲算不算新增用戶呢？
或許看完了以上四個問題，你心中充滿了困惑，這裏建議你再重新看一次『用戶數量的基本單位』的闡述——如果我們以App id爲基本單位，則一切以App的時機數量爲準。 所以，前兩個問題的答案就迎刃而解。
對於第三個問題，用戶卸載了App又進行了重裝，那麼這個用戶還算不算新增用戶？
這裏給出的答案：依然是新增用戶。
舉個例子，『員工甲』在自己的『A公司』辦理了離職手續，幾個月後又重新入職，那麼對於A公司來說，員工甲算不算是公司新人呢？
原則上肯定是公司新人，雖然之前員工甲對於A公司愛過、痛過，但畢竟現在是重新來過！
對於最後一個問題：升級的用戶，對於新版本來說算不算是新用戶？
一般來講，應該不算是新用戶的。
接着上面的案例說：員工甲在A公司努力工作，職位升了，對於新到的部分來說，可能算是新面孔，但是對於公司來講，肯定不算是新員工了。
當然，上述文字只是說了最一般的情況。其實最終對於新增單位的定義還要看具體數據統計平臺自己的定義，至於關於數據統計平臺的闡述，這就是後話了。
2. 新增的關鍵事件
定義完了新增的基本單位，接下來要說新增的觸發時機了。
發生了什麼行爲的用戶算作是新增用戶呢？
這裏有兩個關鍵的操作：安裝與首次打開。
一般情況下，還是默認爲：只有發生了首次打開的事件纔會被認爲是有效新增。因爲只有用戶打開了示例App，才能體驗示例App的提供的服務（功能或內容），同樣只是安裝但是一直沒有打開，那基本上等同於無效安裝。
繼續以員工甲與A公司爲例：如果員工甲在A公司只是提交了入職材料，但是一直沒有來公司上班。那麼，對於A公司來說，員工甲基本上算是無效員工，只有員工甲爲A公司真正工作了、服務了，這樣的員工纔算是一個合格的員工。
所以，我們一般情況下定義的新增用戶，指的是：安裝並且打開過示例App的用戶。
3. 描述新增的時間範圍
如果按照時間範圍這個維度來劃分新增用戶，一般可以分爲『單位時間新增』與『累計新增』。
單位時間新增又可以分爲：每日新增、每週新增、每月新增、每季……
當然最長用的還是每日新增。
最開始提到過：新增是衡量運營同學工作的核心指標之一。
這裏要更加精確一些：『每日新增』纔是衡量運營同學工作非常的核心指標。
至於累計新增這個指標，可能對外提到的會多一些，例如：全中國一共有XXX用戶用過我們的軟件這樣的描述，無論對於吸引投資還是展示公司的形象，都是挺管用的。
四、卸載
一直再考慮要不要加上『卸載』這麼一個指標，糾結的原因主要在於：
首先卸載是衡量一個產品好與壞非常直觀的指標，所以非常的有意義；
但是，卸載這個指標非常的難以統計到，以至於市面上主流的統計平臺只有Google的Firebase統計平臺才能獲取。但是，國內的互聯網環境你們也懂，很多國內的Android系統內置的Google服務被閹割了。所以，主要面向國內市場的互聯網公司根本就拿不到。
但是，抱着內心中僅存的一絲幻想：萬一將來Google又回來了呢？
所以關於卸載仍然要說上幾句。
卸載指標從時間連續性上可以分爲兩個類型：『卸載率』與『卸載曲線』。
卸載率指的是：截止到某一時刻，某批新增用戶中，卸載用戶的佔比。
而卸載曲線則是：卸載率在時間這個維度上的動態變化。
1. 卸載率
再次重申一下『卸載率』的定義：
某一批的新增用戶中，截止到某一時刻，卸載用戶佔據新增用戶的比例。
舉個例子：如果今天的新增用戶有100人，這100個人中，有30人在首次打開示例App後的24小時內，把示例App卸載了。那麼可以定義：今天示例App的24小時卸載率爲40% 。
其實單純的看卸載率所獲取的信息是遠遠不夠的。
因爲很多時候，我們不僅僅要看某一刻的卸載率，還要觀測一段時間內，示例App的卸載率的變化，所以通常情況下，我們更多的是查看「長期卸載率」。
2. 長期卸載率
長期卸載率指的是：在一段時間內（一般以天爲單位），每天前XX分鐘/小時的卸載率的集合，如下圖所示：
上面兩條曲線分別代表：對照組與實驗組在15天的時間裏，前24小時的卸載率的變化曲線。
給人最直觀的感受是：實驗組的卸載率顯著低於對照組。
所以，很容易得出結論：實驗組要好於對照組。
雖然結論很容易得出，但是真的就這樣結束了嗎？
試想這樣一個場景：實驗組和對照組唯一的區別就是實驗組砍掉了A功能。
通過數據可以看出：砍掉功能A後，卸載率降低了，但是我們真的能斬釘截鐵的說用戶不喜歡功能A嗎？
如果是因爲功能A的存在，導致了用戶安裝1小時之後會有極大的概率出現嚴重的bug，而用戶實際上非常喜歡功能A，只是因爲忍受不了這個bug而被迫進行卸載，那麼這個時候僅僅通過長期卸載率是無法歸結出正確的原因的。
更確切的說：如果App從被打開到使用了1個小時的過程中，實驗組的卸載率要遠高於對照組。但是1個小時之後，對照組的卸載率纔開始反超實驗組。
所以，這個時候只盯着固定時刻的卸載率，很容易導致我們的誤判。如果這個時候能夠結合着『卸載曲線』去分析，就會避免這樣的問題。
3. 卸載曲線
關於卸載曲線，純粹用文字解釋可能比較麻煩，所以先給大家看一個示例圖：
這張圖展示的就是：示例App的卸載曲線。
- 橫軸代表着：距離首次打開事件的時間間距（單位爲分鐘）；
- 縱軸代表着：某一時刻的卸載率。
現在我們可以給卸載曲線下一個定義：指的是在指定的時間段內（一般以分鐘爲單位），每個時刻的卸載用戶數佔新增用戶數的比例的集合。
從圖中我們可以看到：無論是實驗組，還是對照組，其卸載曲線在前幾分鐘內急劇的上升，然後有急劇的回落，最終逐漸的平穩，直至趨向於一條直線。
從卸載曲線的示意圖中，我們可以明顯的看出：實驗組的卸載峯值高度明顯低於對照組，而且峯值時間也要比對照組晚一些。
這說明：實驗組確實要比對照組好很多，那麼可以進一步證明A功能確實不受用戶的待見。
而實際上的卸載曲線的峯值會更快與更高，因爲一個普通的新用戶對於一個陌生App的耐受程度是非常低的。在使用App的前幾分鐘內，如果覺得不爽，那就會毫不猶豫的刪除掉，這關鍵的幾分鐘也被稱之爲：新手窗口期。
這意味着在設計產品的時候，要儘量讓用戶在剛打開App的時候，就能看到該App的特色/優勢。如果將這些功能藏着掖着，待用戶自己發掘，結果很有可能是這些功能根本沒有展示的機會，就胎死腹中！
當然了，能不能把兩張圖結合在一起來看呢？
或許『累計卸載率』能滿足這樣的要求。
4. 累計卸載率
累計卸載率指的是：在指定的時間段內（一般時間範圍爲1天），單位時刻（一般單位爲分）的累計卸載率。
如下圖所示：
每個節點代表着截止到某一時刻爲止，總的卸載率。
而某段時間內卸載率的變化趨勢/斜率，則代表着：這段時間內用戶的卸載速度。
累計卸載率既能體現出卸載的過程，又能直觀的看到每個時間節點的累計卸載率。
五、結語
這篇比較詳細的說明瞭『統計單位』『宏觀指標』『新增』『卸載』的概念。
雖然種類不多，但深究起來，也足以值得細細品味，不再多說，下期見！
作者：MING，個人公衆號：MING的大航海，知乎專欄：產品見知錄
本文由 @MING 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議。