DAU下降了,怎么辦?

0 評論 4596 瀏覽 11 收藏 12 分鐘

編輯導語:DAU也就是產品的日活,每個業務模式的DAU都是不一樣的,要根據產品自身的調性確定DAU值;DAU值也會因為很多因素受到影響,如果發現DAU降低,要從內部和外部進行分析;本文作者對DAU下降進行了一些探索和擴展,我們一起來看一下。

某年某月某天早上,你打開數據看板一看,這數據曲線不太妙啊,DAU降低了很多啊,怎么辦怎么辦,開始方了。

不要方,數據下跌不可怕,可怕的是數據下跌了還不知道,甚至是知道下跌了都根本找不到原因。

本文想用一個數據下降的Case來討論下分析思路。

文章主要分為兩部分,一部分是針對DAU下降原因的一些探索,一部分是針對這種問題的拓展。

一、DAU下降了,怎么辦?

在我們討論這個問題之前,需要先明確一下DAU的定義:有的公司的DAU可能是啟動UV,有的公司可能是登錄UV,有的公司可能是發生了特定行為的UV。

在討論一個數據指標之前,需要先理清楚定義或者具體的計算規則、統計口徑,避免討論了很久,最后發現大家對這個指標的定義是不一樣的局面。

為了簡單分析,這里用的定義是啟動UV,分析思路是從外部原因和內部原因兩個方面入手。

1. 外部原因

首先需要明確的是數據是否準確,這可能是一個巨大無比的坑。

如果數據是依賴于客戶端埋點上報的,在發新版本,或者某些功能改版的時候,很可能會出現問題。

常見的問題比如埋點缺失、上報的數據存儲丟失、接口更換等;這種現象一般比較明顯,對應在數據上基本上是腰斬級別的異常。

如果數據是從BI的某些報表中取的,字段的增刪、數據表的更換,都可能帶來數據異常,但這些異常一般比較明顯。

其次是明確數據是否是周期性波動。

一些業務模式會有明顯的周期效應,比如有的業務模式是周一——周五是數據低谷,周末是高峰;有的業務模式是周一-周五是數據的高峰,周末是低谷。

在當前周期往前多對比幾個月的數據,基本能判斷出來是常規波動還是異常波動,有的可能需要對比一下去年同期的數據。

比如有的業務模式會受到季節的影響,在某些城市,一旦到雨季,共享單車這種出行類的App就會受影響,對應的打車類的App也會受影響。

另外就是最近是否有什么節日,有些節日對業務的影響是正向的,有些節日對業務的影響是負向的。

最后是運營和市場最近有沒有做什么活動,數據看起來下降可能并不是真的下降,也可能只是回歸正常,只是之前的數據是高于正常水平的,所以看起來像是下降了。

有的時候到此為止就可以定義到主要的原因了,有的時候上面這些可能都是正常的,那就需要繼續分解了。

2. 內部原因

有時候我們討論的是某個功能的DAU,甚至整個業務就是某個App中的一個功能模塊,這個時候,首先需要看的就是上級的入口流量或者整個App的DAU是否有變化。

我們可以通過某個公式,或者某個流程,找到所有相關聯的因子,然后再層層細分,直到找到原因。

一般來說,DAU=新增用戶DAU+老用戶DAU+回流用戶DAU

有些時候,可能沒有把回流用戶單獨拆分出來,不重要,那就只看前兩項就好。

把這幾個因子都往下拆分一個或者多個層級,就得到下面這樣一個基礎公式。

DAU下降了,怎么辦?

接下來我們需要對每個因子進行排查,確定異常因子之后,再往更下面的層級進行深挖。

假定是新用戶DAU異常的話,接下來就需要再往更深一層看是數量異常,還是留存率異常。

數量異常的話,可以按照渠道再往下一層拆解,看是單一渠道異常,還是多渠道異常:單渠道異常的話,是不是某個渠道的投放出問題了;多渠道異常的話,是不是削減投放預算了。

留存率異常的話,也是按照渠道再往下一層拆解,看是單一渠道異常,還是多渠道異常:單渠道異常的話,是某個渠道存在刷量的嫌疑,還是渠道投放的人群不匹配;多渠道異常的話,是不是更換了投放策略、投放素材、投放的落地頁等。

假定是老用戶DAU異常的話,接下來也是再往更深一層看是數量異常,還是留存率異常。

假定數量異常的話,往下再拆一層,看是安卓還是iOS異常,還是整體都異常,然后可以再按照版本進行拆分,看是不是最近哪個版本里改動什么東西了。

假定留存異常的話,也是一樣的,按照終端(安卓、iOS)、版本、手機類型再進行進一步的拆分,對比最近的版本,看有沒有什么改動可能會影響到。

假定是回流用戶DAU異常的話,接下來也是再往更深一層看是數量異常,還是留存率異常。

假定數量異常的話,接著看一下發送的召回的短信、Push的數量有沒有發生變化、到達的觸達率、點擊率有沒有變化。

假定留存異常的話,看一下推送的策略、推送的內容是否有變化,以及進來的落地頁承接有沒有變化。

經過這樣逐層的拆解,一般情況下是能找到一些異常點,然后需要做的就是針對這些異常點,進行不斷的拆分、細分;最終找到一些我們認為可能有影響的點,得出一些猜想,然后再進行調整、測試、迭代。

二、問題回顧,拓展

我們來回顧下上面那個問題中,我們是怎么做的,以及遇到這種通用問題的時候,我們可以怎么辦。

上面那個DAU下降了的問題,我們經歷了這幾步:

DAU下降——具體是誰下降——為什么會下降——要怎么辦。

那對應在一般的問題上就是:

發現問題——收斂問題——得出猜想——驗證猜想。

DAU下降了,怎么辦?

在發現問題的層面上,沒什么好說的,日??纯磾祿?,看異常的趨勢變化,看同比環比變化。

收斂問題是把問題的范圍不斷縮小直到找到問題,一般是先外部再內部,整體再局部,然后不斷的進行細分拆解。

外部原因就是先找找會影響當前問題的外部系統要素,有的時候可能系統本身沒什么問題,只是外部環境發生了變化。

針對內部某個異常的數據排查一般可以先找到一個公式,把關聯的因子都包含進去,然后再看是哪個因子異常,結合著不同的維度進行更細的拆分。

比如上面提到的DAU=新增用戶DAU+老用戶DAU+回流用戶DAU,或者是素材投放的激活數量=曝光量*點擊率*下載完成率*安裝完成率*啟動率*激活率。

常用的細分維度有以下這些:

  • 渠道;
  • 新老用戶;
  • 用戶關鍵行為次數;
  • 性別、年齡、地域;
  • 版本;
  • 終端等。

猜想一般都是在某些數據或者功能表現不好的情況下展開的,比如以下這些猜想:

  • 是不是推廣的渠道、方式、素材有問題,用戶來了之后發現和預期不符;
  • 是不是功能入口太弱,看不到;
  • 是不是宣傳的東西沒有讓用戶感覺到對自己的價值;
  • 是不是功能太復雜,路徑太長,用戶還沒感覺到價值就流失了;
  • 是不是功能雖然有價值,但與用戶預期不相符;
  • 是不是解決方案本身就有問題,不能滿足需求;
  • 是不是需求根本不存在。

這些都是基于以往的經驗,或者是對業務、對用戶的理解得出來的猜想。

猜想終歸只是猜想,需要進行證實或者證偽,接下來就是基于這些猜想,給出對應的解決方案。

由于只是猜想,所以最好能用最小的成本進行驗證,也就是我們說的MVP。

如何進行MVP驗證?

可以按照影響的范圍、影響的結果大小、影響的可能性、實現成本來按照性價比進行猜想驗證,最好進行單因素驗證,因素太多的話不好歸因。

最后就是基于這些猜想、數據變化來進行不斷的優化迭代。

簡單總結下全文:

  • 發現問題:看趨勢、看同比、環比;
  • 收斂問題:外部+內部,整體公式+不同維度細分;
  • 得出猜想:基于經驗,對業務、用戶的理解;
  • 驗證猜想:MVP、性價比、單因素驗證。

以上,就是本文的主要內容,歡迎斧正、指點、拍磚。

#專欄作家#

王家郴 ,公眾號:產品經理從0到1,人人都是產品經理專欄作家,喜歡網球和騎行的產品汪,目前奔走在產品的道路上,漫漫產品路,與君共勉。

本文原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 unsplash,基于 CC0 協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!