數據分析實際案例復盤
本篇文章主要適合這一人群:能夠接觸到業務數據并且需要通過數據指導工作,但是在分析業務數據時,經常用抓瞎的方式,而非系統性的思考。
內容簡介:復盤之前工作中的一次數據分析過程。
具體內容
數據分析可以說是產品的基本功之一了,網上也有很多相關的文章對數據分析做了非常詳盡的講解,包括各種各樣的思維方式、拆解模式等等。
但是在實際工作中,我們有時候不一定能夠意識到如何去使用這些方式方法。
因此,我以自己在實際工作中遇到的問題為例,介紹一下這些方式方法如何在實際工作中使用。
1. 問題背景
不知道大家是否遇到過這樣的場景,產品的某個頁面有一天突然出現流量大幅降低的情況,而且還是核心流程上的關鍵頁面。
比如說我有一次在走查數據的時候發現,一個產品核心頁面的昨日流量突然下降了20%以上。
2. 解決過程
在這種情況下需要找到事故發生頁,以該頁面作為方向進行分析。
技術角度:
首先需要排除是否由BUG、技術故障等等因素造成,如果是技術上的原因導致的,需要進一步拆解原因,看下是內部因素還是外部因素。常見的內部因素有APP崩潰、卡死,網頁上有400系和500系錯誤等等;常見的外部因素有第三方接口報錯、運營商網絡問題等等。
根據找到的不同問題,去看到底影響了多少用戶,是否與數據表現一致。
另一方面,也需要及時開始處理問題,內部出錯盡量當天溝通、解決;外部原因也需要盡早反應,同時一定要告知客服團隊或者運營團隊問題所在,以免出現用戶反映問題時,還沒有準備好相關的話術以及解決方案。
同時,搭建一個相對比較完善的錯誤通知系統,能夠大大提高確認問題的效率。
業務角度:
其次,在排除技術上的問題之后,需要看看是否為業務層面上面的問題導致。
舉個例子:有一次我發現,一個主推商品的詳情頁面流量大幅度下滑,因此我找到了事故頁查看,但是在進入事故頁的時候,原因就已經很明了了。
因為在4月份時,市場部門在做一個折扣比較大的活動,原價99的商品,活動價為9.9,同時配合了各渠道的推廣,流量漲的很快,但是就在前幾天,由于一些內部原因,市場人員將價格從調整回原價,同時也減少了推廣力度,因此帶來了流量的突然下降。
所以,這邊建議大家一定要跟市場部門的同事溝通好,如果在業務上發生了一些調整,產品需要盡早獲知,不然在不知情的情況下比較容易浪費自己的時間。
同時,技術問題和業務問題的排除優先級,需要視完成的效率而定。
比如說如果先排除技術問題,會比較容易一些,那就先去排除出現BUG等情況的可能;反過來,如果在確認業務是否有調整上更加容易,那就可以優先排除業務上的問題。
流程角度:
在流程上去尋找問題也是一種很常見且有效的思路。比如說開頭我舉的例子中,我在回到流程上看的時候,發現事故頁面本身的情況是正常的,但是之前一個頁面的退出率從百分之幾,增加到了百分之二十多。
顯然,問題出現在了前一個頁面上,不過為什么這個頁面的退出率會突然增加呢?這個時候可以分析該頁面(后稱問題頁)在流程上的作用,具體流程如下:
經過分析,問題頁在流程中主要是讓新用戶完成一個動作后進入事故頁,而用戶也必須完成這個動作才能進入事故頁。
因此上一個問題也可以轉化為:為什么用戶沒有在問題頁去完成需要進行的動作,反而直接退出。
用戶角度:
這一步其實就可以對用戶進行分類分析。
在問題頁的用戶從新老屬性來看,都屬于新用戶,也就是說只有新用戶才能進入到問題頁,在問題頁完成操作之后,就直接進入事故頁。之后再回到這個產品的時候,也不會再進入到問題頁,而是直接到事故頁。
因此,該問題主要是發生在新用戶上,那么相比于之前的新用戶,昨天的新用戶為什么不愿意完成操作呢?
為了解決這個問題,可以對用戶分類進行進一步拆解:昨天的新用戶和昨天之前的新用戶有什么區別?
其實乍一聽,這個問題很奇怪啊,都是新用戶,哪有什么區別?
但其實這兩者是有區別的,不過由于涉及到具體業務,我就不詳細說了分析過程了,直接說結論吧:和運營溝通后發現,對于這個產品的推廣在前天已經結束。推廣渠道主要是公眾號文章,文章內容包括了對產品的解釋和說明,因此昨日之前的新用戶對于要在問題頁完成一個操作才能進入事故頁是有預期的。
而結束推廣之后進入的新用戶,由于對產品不了解且沒有清晰的說明,所以才造成了退出率突然提高。
解決:
因此,在找到了原因之后。解決問題的方向也就有了。不過限于篇幅,這里就不細說了,主要還是從流程上思考,在流程上解決——比如說在這個例子中,我就是通過修改問題頁前的著陸頁文案,提供給用戶一個預期,從而解決了這個問題,目前問題頁的退出率也維持在個位數。
總結
其實在面對不同的場景還可能有不同的方案,有時候從流程角度分析會更加準確,但是有時候需要先從用戶角度去分析。
比如說假如一個商品的訪問流量下降,通過對業務流程圖的分析可能沒有發現問題,但是如果對比兩個時間段的新老用戶占比,可能會發現老用戶的流量下降影響到了整體的數據。
導致這個問題的原因有很多,比如說召回——郵件進入用戶垃圾箱、短信發送失敗或者APP&微信推送發送失敗……
同時,代入本文的場景中,在核心頁面上通過新老用戶的時間段流量差異去發現問題也是可以的。不過需要注意的是,我前面提過推廣已經減少,因此在新用戶量上肯定存在波動,這對在實際情況中的分析上也容易起到誤導作用,所以在這個時候如果能夠對數據的波動有一個大致準確的預判,會減少分析過程中的干擾。當然,我自己暫時還做不到這一點……
這篇文章主要分享的是我自己在實際工作中針對流量下滑時是如何分析的,分析的過程總得來說是優先排除技術故障和業務調整,然后再通過流程角度和用戶角度去分析、發現問題。
同時,我個人認為不需要太執著于那些看似高大上的分析方法和分析工具,發現問題、找到問題、解決問題才是更加需要關注的主題。
作者:許珂誠,微信公眾號:XKC的123
本文由 @許珂誠 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
針對流量下滑時是如何分析的,分析的過程總得來說是優先排除技術故障(內部bug或者是外部技術問題)和業務調整(市場部推廣方案的變更),然后再通過流程角度(建立漏斗模型,找出問題頁)和用戶角度(通過區分用戶類型,新舊,男女,地域等)去分析、發現問題。
分析的過程總得來說是優先排除技術故障和業務調整,然后再通過流程角度和用戶角度去分析、發現問題。