產品專注的市場領域不同，活躍使用者數天差地別。一款小眾的垂直領域產品和泛社交類產品，單純看活躍使用者數，你很難界定它們好壞。
好的資料指標，都應該是比例或比率。
我們設定乙個新指標，活躍率：某一時間段內活躍使用者在總使用者量的佔比。
按照時間維度引申，有日活躍率dau，周活躍率wau，月活躍率等mau。
例：月活躍，本月活躍使用者在截止月末的總註冊使用者中佔比。
一般而言：活躍使用者數，看的是產品的市場體量。活躍率，看的是產品的健康度。
實際得承認，不同產品，使用者需求（高頻或低頻）不同，活躍率也有差異。使用者運營更多的職責是監控活躍率的變化，並且提公升它。
看，我們的活躍使用者數上公升，活躍率下降，這對新產品來說很正常。你不能要求每乙個使用者都使用我們產品不是？
別急，我還沒補刀呢。
我們統計了註冊使用者數，那麼我們也可以統計出本月新增使用者數，很簡單，兩個月相減。
指標拆分後，我們發現老使用者的活躍率比預期低。
實際在產品早期、渠道投入資源推廣、或一次成功的病毒營銷後，因為新增使用者數量的暴漲，總是會帶動活躍數的上公升。
c產品獲得投資後，通過大規模的燒錢推廣，獲得乙個正向的活躍資料反饋。此時活躍有不小可能是由新增使用者撐起的。產品自身的打磨若不好，老使用者活躍率不會提高，這也是我們常說的留存概念。導致錢白白浪費不少。
產品進入穩定期後，有了一定使用者規模，新增活躍一般對活躍資料就不會有大的影響了。
那麼以新老使用者區分活躍統計就夠了？我們簡單定義三個場景：
使用者包含各種型別，反應了不同群體的特徵和想法。在使用整個產品的週期中，我們應定義更全面的指標：
流失使用者：有一段時間沒有再開啟產品，那麼我們就視為流失使用者，根據產品的屬性，可以按30天，60天，90天等劃分。
不活躍使用者：有一段時間沒有開啟產品，為了和流失區分開來，需要選擇無交集的時間範圍。比如流失使用者是60天以上沒開啟產品，那麼不活躍則是0～60天沒開啟。
回流使用者：有一段時間沒用產品，之後突然回來再次使用，則稱為回流使用者。回流使用者是活躍使用者，且是由流失使用者或不活躍使用者喚回而來。
活躍使用者：一段時間內開啟過產品。
忠誠使用者：也可以叫超級活躍使用者，長期持續使用產品，比如連續四周，或者乙個月內15天等。
現在我們發現，不論是活躍使用者還是不活躍使用者的維度，都一下子豐富了起來。
通俗的理解一下使用者活躍的變化
上文abc的三位使用者活躍路徑為：
a：新增—活躍—忠誠
b：新增－不活躍－回流－活躍－忠誠
c：新增－不活躍－流失
回到一開始那款產品的資料，我們將分解後的新指標統計出來。（定義忠誠使用者乙個月內有15天活躍；流失使用者為兩個月沒開啟過）
（以上資料以月末當天的統計為準）
你看，指標開始變得複雜了。產品有長期使用的忠實使用者，也有流失使用者。有使用者回來繼續使用，也有使用者不怎麼愛用產品。
資料是為了方便講解隨手編的。實際的情況可能會更複雜，可以根據情況靈活應對。
使用者活躍可以簡化為乙個最簡單的公式：新增使用者的數量要大於流失使用者的增加量。可以想成乙個水池，運營會一直往裡灌水，但是水池也會漏水，如果漏水速度太大，那麼水池就幹了。一款產品可能因為市場競爭、拉新乏力導致新增使用者數下降，也可能因為產品改動，運營策略失誤造成後續流失使用者變多。
將資料製作圖表：
(活躍使用者和不活躍使用者可以拆分出來，周活躍同理)
使用者運營們可以按照日、周、月維度維護三張報表，監控活躍資料的變化（建議花更多精力在周報表上）。
如果是乙個好的使用者運營，他會繼續思考：每天有多少活躍使用者變得不活躍？有多少忠誠使用者變得不活躍？又有多少流失使用者被我們喚回來等，並且分別是什麼原因引起的。
怎麼樣更詳細的監控活躍資料的變化呢？我們引入桑基（sankey）圖的概念。
這時，活躍資料比單純的**清晰多了，而且我們也能夠顯著觀察到不同活躍層的變化。萬千變化，存乎一圖。
有了資料和趨勢，我們應該聚焦更多精力到怎麼去應用在運營和業務上。
觀察忠誠使用者，發現他們有什麼特徵，為什麼愛用我們產品。同樣的道理，我們也能觀察流失使用者；
忠誠或流失使用者是否在推廣渠道上有顯著差異（配合新增留存資料）；
某一段時間回流使用者增加，是產品更新，市場推廣，還是活動營銷；
本週，變成不活躍的使用者比以前多，要不要做一次使用者訪談看下原因；
活躍的使用者用push營銷，流失的使用者用簡訊營銷，這是不是乙個好方法；
以上種種，皆是使用者運營需要考慮，也是要和各部門協同解決，貫徹整個產品一生的運營方向。
根據不同的使用者活躍狀態，依據產品的特性能採取很多運營手段。這是精準化運營的第一步。接下來則是劃分使用者層次等，進行更精準的運營，不過那是另外的話題了。
tips：
2.市面有許多第三方應用或sdk能達到類似的資料統計。不過我建議，若只能統計，不能拿到資料，為了後續運營還是辛苦點做一套活躍統計系統寫入資料庫吧。
3.下一期，我們可以引申出使用者運營的其他框架，或者怎麼用有趣的桑基圖，做更**的分析。
本文** 秦路 秦路
2016-09-04
活躍度的爬蟲開發（一）
爬蟲最簡單的實現就是乙個http連線request,然後解析resposne，最後根據樣式或者什麼規則，進行匹配，然後提取資訊，判斷是否鏈結其他頁面爬取資訊。我在git上面在寫了乙個關於通過關鍵字查活躍度，暫時在優化中，暫時支援cmd查詢。git位址是 基礎實現 public searchdto k...
如何利用推送提高App活躍度
因此，合理的推送，必須做到以下幾點 1.選擇合適的人 2.選擇合適的時間3.選擇合適的地點與場景 4.提高訊息的觸達率 除了前面所說的針對推送內容本身的精細化運作之外，對於使用者基數大的應用來說，如何保證訊息的觸達也是相當重要而又基本的問題。當推送的目標使用者群體數量較大，比如有重大活動需要全域性推...
Oracle官方併發教程之活躍度
乙個併發應用程式能及時執行的能力稱為活躍性。本節將介紹最常見的活躍性問題 死鎖 deadlock 以及另外兩個活躍性問題 飢餓 starvation 和活鎖 livelock 死鎖描述了這樣一種情景，兩個或多個執行緒永久阻塞，互相等待對方釋放資源。下面是乙個例子。alphone和gaston是朋友，...