一種計算留存的思路

在一些統計系統中，為了觀察使用者的粘度，我們會計算一系列的叫做留存的指標——次日註冊留存、2日註冊留存...n日註冊留存，比如昨天註冊了1000名使用者中，在今天有300名使用者又登入了，那麼對應於昨天的註冊留存就是30%；如果再去細究，還可以去計算活躍使用者的留存情況，比如昨天登入的1000名使用者中，在今天，其中的100名使用者又活躍了，那麼對應於昨天的活躍次日留存就是10%。如果更細究下去的話，還可以去計算每個維度上的留存情況，維度組合的留存情況。

對於這種指標的計算，如果按照傳統的關係型資料庫的思維去計算，要進行一系列的聯接操作，對於大資料量的統計效能上可能就是個問題，並且沒法去實時地跟蹤這些資料指標。換一種思路的話，可能這些指標的計算就沒有那麼費勁了。這裡介紹一種基於實時流系統——storm——進行這些指標的計算。

從總體上看，這些指標依賴於3個核心變數——使用者的註冊時間、使用者上次登入時間記錄、以及使用者「此時（在流中）」的登入時間。以上的指標就是對每個使用者對應地這三個變數進行日期減法即可，以下是具體的思路:

12012-03-04

22012-07-08

32013-02-08

12013-01-06

22013-02-11

32013-03-12

dau_1_2013-03-13,dau_2_2013-03-13，dau_4_2013-03-13，reg_4_2013-03-13...... ------> 進入實時流處理系統

下面就以比較簡單的註冊留存來說明一下思路吧：

1. 首先，實時流處理系統接收到了reg_4_2013-03-13這樣乙個訊息（資料），當我們發現她是以reg開始的訊息時，我們明白，乙個新使用者來了，因此，我們要在我們儲存使用者註冊時間的表中加入這條記錄，當然，如果為了維護資訊的一致性，可以先檢查在現有的資料中是否有對應的使用者記錄，如果有的話，就應該以原有的為標準，當然如果有其它更好的措施來保證資料的一致性就更好了。下面我們的使用者註冊時間表就多加了一條，變成：

12012-03-04

22012-07-08

32013-02-08

42013-03-13

2. 緊接著，我們收到了dau_4_2013-03-13訊息，這是合理的，因為使用者剛剛註冊完成，可能要立即登入。在得到這條記錄之後，我們就要進行我們的註冊留存計算了：首先，我們從這條訊息中得到：登入的使用者是4，而後，我們通過這個使用者id，在使用者註冊時間表中找出使用者的註冊時間，對於使用者4來說，他的註冊時間就是2013-03-13。最後，我們要計算dau時間（2013-03-13）和使用者註冊時間（2013-03-13）之間的差值，並用這個差值和dau日期組合成乙個key，這個key對應的統計數字進行加1操作（如果原來沒有，就初始化成1）：

2013-03-13_01

3. 接著我們又收到訊息：dau_2_2013-03-13，同樣的思路，我們算出使用者2的最新登入時間（2013-03-13），與其註冊時間（2012-07-08）之間的差值（279），並形成key，對對應的key進行加1或初始化操作，得到如下：

2013-03-13_01

2013-03-13_2791

依此類推，當我們處理完dau_1_2013-03-13這條訊息之後，我們得到了：

2013-03-13_01

2013-03-13_2791

2013-03-04_405

1 如果今天又註冊了乙個使用者5，並登入了，那我們的結果表相應地更新成：

2013-03-13_02

2013-03-13_2791

2013-03-04_405

1至此，整個指標計算的流程已經完成，這是你會發現，對於某一天的那些註冊使用者，你能夠輕鬆地拿到他們的n天留存，n可以是任意數。你所要做的只是，拿出那天（比如2012-03-04）對應的總的註冊使用者數（比如說是200），如果想看3天留存，那麼就先計算出3天後的日期（2012-03-07），形成key:2012-03-07_3，拿出對應的值（比如說20），即是2012-03-04那天註冊的200人中，有20個人又在3天後登入了，即是2012-03-04的3日留存，留存率就好算了 20/200 = 10%。

其它的指標亦是如此思路計算。以上只是計算的思路，實現中還需要多多考慮細節。

一種計算留存的思路

HIVE SQL 計算留存率思路

使用者留存模型的一種設計方法

學習知識的一種思路

一種計算留存的思路

HIVE SQL 計算留存率 思路

使用者留存模型的一種設計方法

學習知識的一種思路

相關推薦

HIVE SQL 計算留存率思路