對于用戶端產品經理來說，監控處理日常的用戶端數據是必不可少的工作之一，轉化數據、用戶數據、交易數據等等，都應該是列入日常監控的數據指標。一般來說，這些數據都有固定的波動周期，每個周期內的數據變化應該是趨于穩定的，如果某天某周某月的數據不再符合預期的穩定變化，也就是我們所說的數據異常。這種情況下，我們需要去深挖數據異常產生的原因。雖然這種分析有點時候諸葛亮的意味，而且分析的過程往往無趣且極其耗費時間，對于那些認為產品經理的工作理應充滿挑戰和創新的人來說，這項工作簡直是最讓人厭惡的了。

但是數據異常的分析仍然是必要的，首先，對于產品的各種數據知其所以然，這是對產品經理的基本要求；其次通過數據異常分析往往能夠發掘未知的機會或風險，尤其難得的是這些機會和風險往往是我們平時忽略的（要不然我們也不會認為是“異?！保?，這對產品的持續優化具有重要意義。（雖然我明白其中的道理，不過說實話數據異常分析仍然是我最討厭的工作，沒有之一%>_<%）

那么如何才能做好數據異常分析呢？（或者換個說法：如何完成我們必須要做的煩人分析工作？）首先，當然是要求我們能識別和確認數據異常，其次就是細致的分析過程，如果想要很好的完成這個過程，我認為可以用八個字概括：大膽設想，小心求證。

識別和確認異常

既然是數據異常分析，那么我們必須能察覺到這些異常，然后還要確認數據異常是真的存在，否則只會在錯誤的道路上越走越遠。察覺數據異常最難也最簡單，最難是因為察覺的過程往往依靠豐富的經驗和對產品和業務的充分了解，我們稱之為產品經理的數據敏感。最簡單是因為我們一旦有了這種敏感性，只要借助基本的數據報表，就能夠風吹草動無微不察。數據敏感不是一個“硬”技能，也很難說有具體的操作步驟去提高數據敏感性，這種敏感一部分真的要靠天賦，有些人可能邏輯性強，通過數據本身的相對關系就能夠發現異常的存在，比如DAU和轉化率都有提升而交易額呈下降趨勢（這個異常相對明顯，原諒我一時舉不出需要更嚴密邏輯分析的例子）。另一部分，它需要產品經理對產品和業務有足夠的了解，這個是可以通過平時多加關注各種產品數據來逐漸加強的，比如養成仔細閱讀產品數據報告的習慣，然后對一些無法理解的數據進行詳細分析，經過長期的主動訓練，是一定可以提高數據敏感度的，這也是為什么Leader們（有經驗的產品經理）更容易發現異常的原因。

如果你已經具備了察覺或明顯或隱蔽的數據異常的能力，你或許有發現寶藏的興奮，迫不及待的想要去搞清楚所以然。但是我建議你在行動前最好確認一下這個異常是真的存在，簡單的說，就是確認下數據有沒有問題。這種事情很常見：我們經常會遇到數據服務、數據上報、數據統計上的BUG，然后數據報表中的數據就變得難以理解。所以，找數據報表的產品和技術同事確認一下是不是真的異常吧。

數據異常分析

如果數據異常經確認確實存在，那么你就要去找原因了。這個找原因的過程總結起來就是前面所說的“大膽設想，小心求證”，大膽設想就是對異常產生的原因做出合理的猜測，因為異常之所以為異常，是因為我們之前的忽視，所以在猜測的過程中需要腦洞大開，聯系所有你能夠想到的所有可能，回顧所有產品相關的信息，然后猜測一個可能造成數據異常的原因。小心求證是說在做出猜測之后，我們需要對自己的猜測負責，找到能夠支持（或者否定）這種猜測的數據。

大膽設想

那么，我們如何才能做到腦洞大開大膽設想呢？對新手產品經理（好吧，數據異常分析好像大多由新手來分析處理）來說，你可能會覺得兩眼一抹黑不知如何下手，下面有一個簡單的表格，可供參考。

* 如果你看到這個表格已經知道我要說些什么，那后面的內容你可以不用看了。

對于大部分已經產生的數據異常，大概可以從兩個維度來分類（個人經驗總結，可能不同產品有不同的分類方式，但是我堅持推薦這種通過分類來確定分析方向的方式）：

• 第一個是范圍維度，包括自己的產品、競對方面以及產品業務的大環境，這樣分類的原因是因為相互競爭的產品都處于大的產品業務環境之中，任何一方的變動都會造成自家產品的數據變化；
• 第二個是內容維度，包括產品、技術、用戶和運營，這幾個維度基本囊括了互聯網產品的重要構成，往往數據異常逃不過這幾個方面。反過來說，如果我們發現了數據異常并且要給出一個合理的數據異常原因猜測，那么不妨聯系實際選擇表格中的某一格。

我將已經遇到過的情況和一些覺得可能以后會遇到的情況填充到這個表格中，通過這些例子對這種分析（猜測）方法做出解釋。

產品層面，A1和B1兩種情況是指當自身的產品或者競對的產品因為功能變更造成的數據變化，比如自己產品因為增加了高價排序功能造成客單價升高，而競對將某些品類商品入口提前而造成自己App上這類商品的交易額降低；C1指大環境發生了變化，而造成自己的產品數據變化，比如我們可以猜想當微博興起時，人人網的產品經理會發現DAU持續下降。

因為大多數產品經理并非技術出身，所以技術上的問題往往是產品經理在分析數據時忽視的內容。比如A2，當我們的列表展示接口不夠穩定時，會造成列表頁點擊率降低，進而交易額等等都接連降低。比如B2，當2015.5.28，攜程因為系統故障而無法訪問時，其他OTA網站的交易量可預見是提升的。C2情況相對少見，比如2014.1.21，國內所有通用頂級域的根服務器出現異常，而當日國內大部分網站的數據毫無疑問應該是異常的。

用戶層面，當用戶整體特征逐漸變化時，產品數據也會逐漸變化。對于A3和B3情況，我們假設有一類產品，最初培養的一群用戶是學生，消費能力有限。如果這個產品黏性夠強，當這批學生逐漸步入社會，客單價可能會持續增長。C3情況，每年到11月，各OTA網站的DAU和交易額整體就會降低，而三亞地區的交易額逆勢上升，這就是大環境下旅游淡旺季的原因造成的。

對于需要支付的產品來說，所有運營活動都能影響市場的大小以及市場份額的分布，比如滴滴和快的在培育市場階段，任何一方的大額促銷都會提升自己的市場份額并侵占競對的市場份額（A4和B4），而當滴滴快滴合并之后紅包額度的減少，必然會造成App叫車用戶數量的降低（C4）。

小心求證

前面講了大膽設想的方法，如果只是停留個這個層面，那這個分析是沒有說服力的，下面還有一個重要的步驟是小心求證。小心求證是找到直接或間接的證據來證明你的猜想。對于大環境維度的數據異常原因猜測，一般可以獲取一些能夠反映大市場的數據來證明，比如OTA網站DAU在某月降低幅度很大，我們猜測是因為旅游淡季開始，這時候可以去百度指數看看“酒店”或“酒店預訂”搜索熱度的變化，或者查查往年此時的旅游消費數據，就可以驗證我們的猜測是否準確。

而對于自身產品和競對產品維度的求證，不二法寶就是細分，下面介紹一些常見的細分維度及其案例。

• 分步：假設某產品的轉化率數據出現降低的情況，而這個轉化率是多步漏斗轉化的最終轉化，我們可以細分每一步的轉化情況，查清是否因為某一步出了問題。比如微信支付服務器的故障會造成下單到支付的轉化降低從而造成轉化率降低，列表加載速度增加造成列表到詳情轉化率降低影響整體轉化等等。
• 分平臺/版本：假設某產品列表頁到詳情頁的轉化提升，我們猜測是iOS新版本中優化列表布局方式，我們需要分iOS和Android以及分iOS新版老版對比這個轉化數據來證明我們的猜測。
• 分區域/城市：假設某年8月31日某OTA的交易額呈現大幅增長，我們猜測是因為大學生開學造成酒店需求增加，這時我們可以選取部分高校較多的城市如北京、武漢、西安等城市的數據來對比其他城市來側面驗證我們的猜測。
• 分時間：假設某日某產品轉化率數據下降，我們猜測是10:00-11:00支付服務器故障造成的，那我們只需要分時間段和上一個波動周期同期的數據對比，如果當日這個時間段轉化率確實下降很大，就可以證明我們的猜想。
• 分用戶群體：假設某App新版上線之后新版轉化率低于舊版，經過用戶分析發現新版新用戶比例較大，我們猜測新用戶轉化率會比老用戶轉化率低，這個時候我們只需要看一下新老客戶的轉化率區別就能知道我們是否蒙對了。
• 分場景（本/異地）：假設某App在某假期內轉化率降低，已知異地用戶轉化率低于本地用戶轉化率，猜測假期轉化率降低是因為異地用戶較活躍造成的，這個時候，我們只要需要去看看本異地用戶占比的變化就可以驗證猜測了。
• 分Item：假設某OTA轉化率在某段時間內明顯提升，而這個時間段恰好是競對較少補貼促銷活動的時間，我們猜測是競對促銷活動終止對產品轉化率造成了正面影響，如果我們查看數據證實那些被競對取消促銷的Item轉化率提升明顯，那說明我們的猜測是對的。

關于如何做細分分析，這里沒有辦法窮舉，可以細分分析的維度實在太多了，但是我們需要記住這種分析方式，當猜測是某種原因造成數據異常時，只要找到該原因所代表的細分對立面做對比，就可以證明或證偽我們的猜測。當然，在分析的過程中，我們需要了解一些基本的統計學知識，這個將會在下周的推送中詳細介紹，敬請期待。

小結

當發現數據異常時或者接到數據異常分析任務時，我們可以聯系產品相關的信息，在范圍維度（自身、競對、大環境）和內容維度（產品、技術、用戶、運營）結合給出合理的猜測，然后通過查看一些大環境變化數據或者細分的產品數據來驗證我們的猜測。遵照這個流程，一般能夠找到數據異常的深層原因，當然，著需要花費大量的時間和足夠的耐心，但它能夠讓我們更深更全面的了解自己負責的產品的相關信息，并為未來的產品決策提供指導。對我們自己，這也能加強數據敏感度，讓我們能夠發現更多機會和問題，形成一個良性循環，成為一個能玩轉數據的產品經理。

本文由 @hihipm（微信公眾號：hihipm） 授權發布于人人都是產品經理?，未經許可，禁止轉載。