用戶行為分析模型實踐（四）—— 留存分析模型
一、背景需求
根據(jù)CNNIC的統(tǒng)計數(shù)據(jù)顯示，中國互聯(lián)網(wǎng)用戶已達10.79億人，互聯(lián)網(wǎng)普及率達到79.4%?；ヂ?lián)網(wǎng)雖然仍然在快速增長，但是用戶規(guī)模逐漸飽和，互聯(lián)網(wǎng)事實上已經(jīng)進入了存量用戶時代，整體的流量競爭也越來越激烈，用戶的留存的重要性也越來越高于拉新。因此，如何識別忠實用戶，了解目標用戶群的留存表現(xiàn)？如何分析用戶流失情況，優(yōu)化產(chǎn)品？如何分析目標用戶是否完成了期望的行為等等就是我們數(shù)據(jù)分析的重要課題，而留存分析模型就是我們解決這些問題的重要工具。
二、概述
2.1 概念介紹
留存分析模型主要用于分析觸發(fā)了起始事件的用戶在后續(xù)時間周期內觸發(fā)了后續(xù)事件（即回訪事件）的比率，該模型可以較好的反映出用戶的忠實度或者說是用戶的粘性。對于留存分析模型有幾個重要的概念要了解：
留存分析一般需要指定起始事件和回訪事件，但起始事件和回訪事件可以相同，也可以不同：
1、起始事件、回訪事件可以選擇相同事件，這種可以很直觀地看出觸發(fā)事件的忠實用戶量。
例如：在簽到過程中，起始事件為簽到成功，回訪事件也是簽到成功，在一段時間內，連續(xù)觸發(fā)該事件的用戶數(shù)量即可為忠實用戶量。
2、起始事件、回訪事件可以選不同事件，這種就是比較正常流程下的用戶留存數(shù)據(jù)。
例如：在某個活動中，從下單到成功支付的場景內，起始事件為下單，回訪事件為支付成功，這種在一段時間內，觸發(fā)這兩個事件的同一用戶為指定流程下的用戶留存數(shù)據(jù)。
2.2 分析思路
留存率作為一個產(chǎn)品的核心指標之一，我們提升產(chǎn)品力，改善使用體驗，分析目標用戶很大程度上也是為了提升這個指標。比如，我們可以通過計算N日的留存率，來評估某個迭代是否是正向的。如圖1所示，某應用優(yōu)化了首頁布局，推出了新版本A，就可以聯(lián)同舊版本B，分別計算每日的用戶留存率，它一般會組成一個衰減的留存曲線。曲線衰減的越慢，說明我們的留存率越高，也就能體現(xiàn)我們首頁的修改是有正向的效果的。當然有時留存的提升可能只有百分之零點幾，但是在一個很大的用戶基數(shù)的前提下，也可能產(chǎn)生一些質變的效果。我們也可以將特定的人群圈定為用戶組，針對不同的用戶組進行留存分析，挖掘更加忠實的用戶群體。
圖1 新版本A與舊版本B的留存對比
三、用留存進行的數(shù)據(jù)分析
了解了上面的關于留存模型的基本概念，我們看一下如何創(chuàng)建一個留存。
3.1 選一個起始事件、一個回訪事件
起始事件：打開瀏覽器。
回訪事件：退出瀏覽器。
3.2 設置留存天數(shù)
設置一個留存天數(shù)為3天。
3.3 確定留存的時間區(qū)間
這里的時間區(qū)間概念是指，你需要查看的日期區(qū)間,例如選擇時間區(qū)間為2023-01-06~2023-01-08，則是只計算2023-01-06到2023-01-08這3天，每天的當日留存，第1日留存，第2日留存，第3日留存。
3.4 留存數(shù)據(jù)的展示及計算邏輯
起始用戶數(shù) = 計算日期觸發(fā)起始事件用戶數(shù)。
- 當日留存用戶數(shù) = 當日觸發(fā)回訪事件的用戶與當日觸發(fā)起始事件用戶交集。
- 第1日留存用戶數(shù) = 次日觸發(fā)回訪事件的用戶與計算日期觸發(fā)起始事件用戶交集。
- 第2日留存用戶數(shù) = 2日后觸發(fā)回訪事件的用戶與計算日期觸發(fā)起始事件用戶交集。
- 第3日留存用戶數(shù) = 3日后觸發(fā)回訪事件的用戶與計算日期觸發(fā)起始事件用戶交集。
- 當日留存率 = 當日留存用戶數(shù)/起始用戶數(shù)*100%。
- 第1日留存率 = 第1日留存用戶數(shù)/起始用戶數(shù)*100%。
- 第2日留存率 = 第2日留存用戶數(shù)/起始用戶數(shù)*100%。
- 第3日留存率 = 第3日留存用戶數(shù)/起始用戶數(shù)*100%。
用戶留存數(shù)表（即表1）表示起始事件為“打開瀏覽器”、回訪事件為“退出瀏覽器”時，對應2023-01-06~2023-01-09每天的近3天的留存用戶數(shù)據(jù)。
表1 用戶留存數(shù)表
用戶留存率表（即表2）表示 起始事件為“打開瀏覽器”、回訪事件為“退出瀏覽器”時，對應2023-01-06~2023-01-08每天的近3天的留存用戶占比數(shù)據(jù)。
表2 用戶留存率表
以表1中2023-01-06日的數(shù)據(jù)為例，1月6日起始用戶數(shù)1000：是指觸發(fā)起始事件“打開瀏覽器”的用戶數(shù)；當日留存用戶數(shù)900：是指在觸發(fā)起始事件用戶中當日又觸發(fā)回訪事件為“退出瀏覽器“的用戶人數(shù)；
第1日留存用戶數(shù)500：是指1月7日觸發(fā)回訪事件且與1月6日中觸發(fā)起始事件的交集用戶數(shù)；第2日留存用戶數(shù)300：是指1月8日觸發(fā)回訪事件且與1月6日中觸發(fā)起始事件的交集用戶數(shù)300，以此類推到第3日，此時計算出來的2023-01-06這一天的3天的留存數(shù)據(jù)！
圖2：觸發(fā)起始事件、回訪事件對應3日內的留存用戶趨勢圖
四、整體功能設計及留存分析模型的實現(xiàn)
4.1（離線）功能整體架構設計
圖3 留存分析模型hive架構圖
整體架構主要分為配置、計算、存儲、展示四階段。
1. 配置
此階段主要是工程端的后臺服務實現(xiàn)。用戶在平臺按照自身需求設置起始事件及回訪事件、過濾條件、用戶群篩選、維度篩選等配置。后臺服務收到配置請求后，依據(jù)留存分析類型選擇不同任務組裝器進行sql任務的組裝。
2. 計算
平臺根據(jù)接收到的查詢方式，選擇離線查詢Spark引擎進行分析計算。離線計算結果同步到MySQL。
3. 存儲
離線結果集持久化到MySQL數(shù)據(jù)庫中，可通過后臺服務展示給用戶。
4. 展示
離線結果根據(jù)圖表配置ID查詢MySQL結果表數(shù)據(jù)進行展示，即時查詢通過配置后直接查詢展示結果。
4.2（離線）留存不同條件下實現(xiàn)SQL
離線通用執(zhí)行hive任務SQL
離線留存hive執(zhí)行SQL
select
'起始留存計算日期' as origin_day,
a.day as day,
datediff('起始留存計算日期', a.day) as diff,
count(distinct (a.uid)) as user,
count(distinct (case when b.uid is not null then b.uid end)) as retention
FROM
(
SELECT
day,
uid
FROM
abcd.test
WHERE
day >= if('起始時間' >= date_sub('起始留存計算日期', '留存天數(shù)'),'起始時間',date_sub('起始留存計算日期', '留存天數(shù)'))
AND day <= if('結束時間' <= '起始留存計算日期','結束時間','起始留存計算日期')
AND event_id = '起始事件')
) a
LEFT JOIN (
SELECT
s.uid
FROM
abcd.test s
WHERE
s.day = '起始留存計算日期'
AND s.event_id = '回訪事件'
GROUP BY
s.uid
) b ON
a.uid = b.uid
WHERE
day >= if('起始時間' >= date_sub('起始留存計算日期', '留存天數(shù)'),'起始時間',date_sub('起始留存計算日期', '留存天數(shù)'))
AND day <= if('結束時間' <= '起始留存計算日期','結束時間','起始留存計算日期')
GROUP BY a.daySQL 當中字段含義分別為：
【origin_day】：起始留存計算日期
【day】：最終留存計算日期
【diff】：第幾日留存
【user】：起始用戶數(shù)
【retention】：留存數(shù)
以上SQL含義：查詢起始留存計算日期分別到起始時間、結束時間這個區(qū)間段中的每天的詳細留存數(shù)據(jù)，不可一次性計算出時間區(qū)間內完整的留存數(shù)據(jù)，需經(jīng)過多天累計查詢，且此SQL執(zhí)行的結果在留存結果表中展示樣例為倒三角填充。
例如：我們定了起始事件和回訪事件后，去計算2022-05-01~2022-05-05的每一天的3日留存，此時，起始時間是2022-05-01，結束2022-05-05，留存天數(shù)3天。
針對此案例，起始留存計算日期開始日期應該為2022-05-01~2022-05-08，才能計算出2022-05-01~2022-05-05的每一天的3日留存。
第一步：計算起始留存日期 = 2022-05-01時，最終留存計算日期區(qū)間2022-05-01~2022-05-05日每天的留存數(shù)據(jù)，從時間上看，該起始留存計算日期只能計算出2022-05-01日當日留存，執(zhí)行后結果如下（表3）：
表3
起始留存計算日期2022-05-01在2022-05-01~2022-05-05區(qū)間內留存詳情數(shù)據(jù)
此時轉換后留存數(shù)據(jù)表格為（表4）：
表4
起始留存計算日期2022-05-01在2022-05-01~2022-05-05區(qū)間內轉換后留存數(shù)據(jù)表
第二步：計算起始留存日期 = 2022-05-02時，最終留存計算日期區(qū)間2022-05-01~2022-05-05日每天的留存數(shù)據(jù)，該起始留存計算日期可計算2022-05-01日的第1日留存用戶數(shù)及2022-05-02日當日留存用戶數(shù)據(jù)，執(zhí)行后結果如下（表5）：
表5
起始留存計算日期2022-05-02在2022-05-01~2022-05-05區(qū)間內留存詳情數(shù)據(jù)
此時轉換后留存數(shù)據(jù)表格為（表6）：
表6
起始留存計算日期2022-05-02在2022-05-01~2022-05-05區(qū)間內轉換后留存數(shù)據(jù)表
第三步：計算起始留存日期 = 2022-05-03時，最終留存計算日期區(qū)間2022-05-01~2022-05-05日每天的留存數(shù)據(jù)，該起始留存計算日期可計算2022-05-01日的第2日留存用戶數(shù)、2022-05-02日第1日留存用戶數(shù)據(jù)、2022-05-03日當日留存用戶數(shù)據(jù)，執(zhí)行后結果如下（表7）：
表7
起始留存計算日期2022-05-03在2022-05-01~2022-05-05區(qū)間內留存詳情數(shù)據(jù)
此時轉換后留存數(shù)據(jù)表格為（表8）：
表8
起始留存計算日期2022-05-03在2022-05-01~2022-05-05區(qū)間內轉換后留存數(shù)據(jù)表
第四步：以此類推，計算起始留存日期 = 2022-05-08時，最終留存計算日期區(qū)間2022-05-01~2022-05-05日每天的留存數(shù)據(jù)，該起始留存計算日期可計算2022-05-05日的第3日留存用戶數(shù)，執(zhí)行后結果如下（表9）：
表9
起始留存計算日期2022-05-08在2022-05-01~2022-05-05區(qū)間內留存詳情數(shù)據(jù)
最終數(shù)據(jù)展示完全后會是一個完整的表格（可得如下結果表10）：
表10
2022-05-01~2022-05-05的每一天的3日留存數(shù)據(jù)表
4.3 存在的問題與下一步優(yōu)化的方向
存在的問題：
用戶在平臺上進行報表創(chuàng)建后，在產(chǎn)出報表結果上耗時較長；當配置報表查詢周期長，數(shù)據(jù)量大的情況下，存在計算資源消耗過大的情況。
優(yōu)化方向：
為了優(yōu)化報表生成過程，可以考慮使用ClickHouse來處理數(shù)據(jù)。ClickHouse是一個高性能、分布式、列式存儲的數(shù)據(jù)庫系統(tǒng)，特別適合處理大規(guī)模數(shù)據(jù)和復雜查詢。
具體而言，可以采用以下ClickHouse特性：
- 將數(shù)據(jù)導入ClickHouse中，以便更快地查詢和計算。ClickHouse支持高效的數(shù)據(jù)導入和壓縮方式，可以大大減少數(shù)據(jù)的存儲空間和查詢時間。
- 利用ClickHouse的列式存儲和分布式計算能力，實現(xiàn)增量計算和數(shù)據(jù)預處理。通過使用ClickHouse的分布式計算能力，可以將計算任務分配給多個節(jié)點并行處理，從而加快計算速度。同時，通過使用ClickHouse的列式存儲能力，可以避免不必要的數(shù)據(jù)讀取和計算，提高計算效率。
- 利用ClickHouse的緩存機制，提高查詢效率。ClickHouse支持高效的緩存機制，可以將查詢結果緩存在內存中，以便更快地響應查詢請求。
- 利用ClickHouse的SQL查詢語言，實現(xiàn)靈活的數(shù)據(jù)分析和報表生成。ClickHouse支持SQL查詢語言，可以方便地進行數(shù)據(jù)分析和報表生成，同時也支持復雜查詢和聚合操作，可以滿足各種數(shù)據(jù)分析需求。
通過利用ClickHouse上述特性，進一步提高整個數(shù)據(jù)分析過程的效率和準確性。
五、基于ClickHouse的留存分析模型
5.1 利用ClickHouse查詢速度快的特性改造離線留存圖表產(chǎn)出方式
利用ClickHouse進行實時留存查詢
傳統(tǒng)的離線留存計算通常需要借助Hadoop、Spark等大數(shù)據(jù)處理框架，需要消耗大量計算資源和時間。而利用ClickHouse進行離線留存計算，可以大大提高計算速度和效率，可以實現(xiàn)秒級響應和高并發(fā)查詢。
具體步驟如下：
- 將用戶行為數(shù)據(jù)導入ClickHouse；
- 根據(jù)查詢配置數(shù)據(jù)組裝留存SQL用于查詢；
- 利用ClickHouse的高速查詢功能，實時查詢留存率數(shù)據(jù)。
利用ClickHouse進行留存圖表的產(chǎn)出
利用ClickHouse進行留存計算和查詢后，可以通過數(shù)據(jù)可視化工具對留存數(shù)據(jù)進行圖表化展示，從而更加直觀地了解用戶留存情況。例如：
- 利用數(shù)據(jù)可視化工具連接ClickHouse數(shù)據(jù)庫，查看留存率數(shù)據(jù)或者通過http請求查詢結果表數(shù)據(jù)；
- 通過數(shù)據(jù)可視化工具繪制留存圖表，并進行定制化設計和樣式調整。
結合hive、ClickHouse兩者優(yōu)點，可將架構做如下優(yōu)化，對于歷史較長時間日期的結果回溯進行hive查詢處理，可在ClickHouse中存儲的數(shù)據(jù)作為每天例行查詢存儲結果。
例行：是指創(chuàng)建一次圖表每日例行執(zhí)行報表任務，產(chǎn)出數(shù)據(jù)（例行可回溯ClickHouse中存儲日期的留存數(shù)據(jù)）。
手動：是指在指定時間范圍內執(zhí)行，執(zhí)行完成產(chǎn)出任務停止。
圖4 結合ClickHouse、hive后留存分析模型架構圖
5.2 主要函數(shù)介紹
Retention
該函數(shù)將一組條件作為參數(shù)，類型為1到32個 UInt8 類型的參數(shù)，用來表示事件是否滿足特定條件。任何條件都可以指定為參數(shù)（如 WHERE)。
除了第一個以外，條件成對適用：如果第一個和第二個是真的，第二個結果將是真的，如果第一個和第三個是真的，第三個結果將是真的，等等。
① 語法
retention(cond1, cond2, ..., cond32);
② 參數(shù)
cond — 返回 UInt8 結果（1或0）的表達式。
③ 返回值
數(shù)組為1或0。
1 — 條件滿足。
0 — 條件不滿足。
④ 類型
UInt8
ClickHouse查詢SQL
ClickHouse即時查詢留存SQL
SELECT retention_date,
USER,
IF(DATEDIFF('day', retention_date, NOW()) >= 1, retain0, NULL) AS retain0,
IF(DATEDIFF('day', retention_date, NOW()) >= 2, retain1, NULL) AS retain1,
IF(DATEDIFF('day', retention_date, NOW()) >= 3, retain2, NULL) AS retain2,
IF(DATEDIFF('day', retention_date, NOW()) >= 4, retain3, NULL) AS retain3
CONCAT(toString(ROUND(retain0 / USER * 100, 4)), '%') AS ratio0,
CONCAT(toString(ROUND(retain1 / retain0 * 100, 4)), '%') AS ratio1,
CONCAT(toString(ROUND(retain2 / retain0 * 100, 4)), '%') AS ratio2,
CONCAT(toString(ROUND(retain3 / retain0 * 100, 4)), '%') AS ratio3
FROM (SELECT b.retention_date,
COUNT(DISTINCT (uid)) AS USER,
SUM(ret[1]) AS retain0,
SUM(ret[2]) AS retain1,
SUM(ret[3]) AS retain2,
SUM(ret[4]) AS retain3
FROM (
SELECT j.retention_date,
uid,
retention(
j.day = j.retention_date,
j.day = j.retention_date + INTERVAL 1 DAY,
j.day = j.retention_date + INTERVAL 2 DAY,
j.day = j.retention_date + INTERVAL 3 DAY,
j.day = j.retention_date + INTERVAL 4 DAY
) AS ret
FROM (SELECT b.day AS retention_date,
b.uid,
t.day AS DAY
FROM (SELECT DAY, uid
FROM abcd.test2
WHERE DAY >= '開始時間'
AND DAY <= '結束時間'
AND event_id IN ('起始事件')
GROUP BY DAY, uid ) b
LEFT JOIN
(SELECT uid , DAY, event_id
FROM abcd.test2
WHERE DAY >= '開始時間'
AND DAY <= '結束時間'
AND event_id IN ('回訪事件')
GROUP BY DAY, uid, event_id) t ON b.uid = t.uid
) j
GROUP BY j.retention_date, j.uid ) b
GROUP BY b.retention_date)SQL 當中返回結果含義分別為：
retention_date：留存日期
user：起始用戶數(shù)
retain0：當日留存用戶數(shù)
retain1：第1日留存用戶數(shù)
retain2：第2日留存用戶數(shù)
retain3：第3日留存用戶數(shù)
ratio0：當日留存率
ratio1：第1日留存率
ratio2：第2日留存率
ratio3：第3日留存率
以上SQL含義：計算出指定時間區(qū)間內3日留存信息，可一次性查詢出指定區(qū)間內的所有3日留存數(shù)據(jù)，一個sql即可查詢完全。
例如：我們定了起始事件和回訪事件后，去計算2022-06-01~2022-06-04的每一天的3日留存，此時，起始時間是2022-06-01，結束2022-06-04，留存天數(shù)3天。
針對此案例，在不同的日期查詢數(shù)據(jù)完整性不一致，我們拿2022-06-04日和2022-06-07日兩日查詢舉例。
第一步：針對2022-06-04日進行計算2022-06-01~2022-06-04的每一天的3日留存，執(zhí)行后留存數(shù)據(jù)展示結果如下（表11）。
表11
2022-06-04日計算2022-06-01~2022-06-04的每一天的3日留存數(shù)據(jù)表
第二步：針對2022-06-07日進行計算2022-06-01~2022-06-04的每一天的3日留存，執(zhí)行后留存數(shù)據(jù)展示結果如下（表12）。
表12
2022-06-08日計算2022-06-01~2022-06-04的每一天的3日留存數(shù)據(jù)表
趨勢結果展示（圖5）：
圖5 留存分析模型趨勢圖
六、寫在最后
本文介紹的留存模型就是數(shù)據(jù)分析工具箱的核心分析模型，使用的范圍十分廣泛。它通過計算用戶在一段時間內的留存率，可以評估產(chǎn)品、服務或應用程序的用戶體驗和吸引力，提高用戶留存率和活躍度。在實際的生產(chǎn)中，業(yè)務可根據(jù)自身具體需求和用戶特征進行定制化設計，同時也可將通過留存分析得到的人群信息結合其他的數(shù)據(jù)分析方法進一步的深入分析。例如，從留存中得到的用戶人群信息，我們可以進一步的使用路徑分析的分析方法，分析用戶的訪問行為對于產(chǎn)品的影響。
數(shù)據(jù)分析的工具方法有很多，除了上面提到過得用于分析用戶在應用上的訪問行為的用戶路徑分析；也有衡量業(yè)務中關鍵事件之間轉化效果的漏斗分析；還有事件分析、歸因分析等等，他們共同組成的強大的數(shù)據(jù)分析工具箱，可以較為全面的分析用戶行為的潛在特征與規(guī)律，幫助產(chǎn)品或者決策者作為更加可靠的決策。
