一、概覽

首先和大家分享下業(yè)務(wù)場景和技術(shù)架構(gòu)。文中的Demo數(shù)據(jù)都是脫敏后的假數(shù)據(jù)，業(yè)務(wù)場景也換成了一些更通用的基于信息流和電商的場景，這些場景與各種互聯(lián)網(wǎng)場景都是適用的。

1、業(yè)務(wù)場景

用戶路徑是用戶在網(wǎng)站或APP中的行為路徑。上圖的上半部分是一個用戶路徑的例子，所有的互聯(lián)網(wǎng)場景在大的層面分為三部分：聚合頁、列表頁和正文頁，我們的用戶路徑其實就是在這些不同類型的頁面來回切換。

用戶路徑分析的價值主要體現(xiàn)在如下幾方面：

• 描繪用戶生命周期：作為數(shù)據(jù)從業(yè)者，常常需要看清某個業(yè)務(wù)或場景，除了BI工具以外，用戶路徑分析也是一個比較行之有效的方法，通過圖表能夠一目了然地看清流量走向。
• 識別用戶體驗問題：用戶增長成本高昂，由于各種體驗問題，造成大量用戶流失，在這中間能夠找到一些業(yè)務(wù)增長點。
• 提升數(shù)據(jù)質(zhì)量：除了被產(chǎn)品和運營提需求、被發(fā)現(xiàn)數(shù)據(jù)bug外，我們希望能夠主動地提升數(shù)據(jù)質(zhì)量。用戶路徑分析可以使業(yè)務(wù)展示更加清晰，能夠識別出用戶數(shù)據(jù)的各種問題；另外，當(dāng)把一個數(shù)據(jù)、場景或基于Event的日志式的數(shù)據(jù)結(jié)構(gòu)變成基于Session的數(shù)據(jù)結(jié)構(gòu)后，它就有了次序和關(guān)聯(lián)，這樣就很容易發(fā)現(xiàn)數(shù)據(jù)中的問題。

2、方案和技術(shù)架構(gòu)

整體的技術(shù)架構(gòu)由底層的數(shù)據(jù)集成、中間的存儲、上面的應(yīng)用和服務(wù)部分組成。這里重點分享下與Session有關(guān)的部分。

• 數(shù)據(jù)集成：底層數(shù)據(jù)集成中數(shù)據(jù)治理是非常重的，在這部分我們試圖對跨業(yè)務(wù)的場景做統(tǒng)一串聯(lián)，拼接用戶行為日志。因為大部分的互聯(lián)網(wǎng)產(chǎn)品都是模塊化開發(fā)，由內(nèi)容、電商、廣告等模塊組成，不同團隊的日志結(jié)構(gòu)很可能是不一樣的，因此要做好用戶路徑分析，數(shù)據(jù)治理是很重要的工作。
• 數(shù)據(jù)存儲：對于Session數(shù)據(jù)，先用Spark或Hive批處理，然后結(jié)合類似ClickHouse的OLAP方案可以很好地解決性能問題。該層還有一個方案是騰訊的開源圖數(shù)據(jù)庫，可以很好地展現(xiàn)路徑情況，是知識圖譜場景外的一個比較好的圖數(shù)據(jù)庫應(yīng)用場景。
• 應(yīng)用和服務(wù)部分：除了之后要介紹的開源方案，還有一個重要的部分，就是Jupyter Notebook部分。我們內(nèi)部做的很多場景中，都是先把做好的數(shù)據(jù)經(jīng)過數(shù)據(jù)治理之后放到ClickHouse數(shù)據(jù)庫中，然后用Jupyter直接去連ClickHouse數(shù)據(jù)庫，這樣可以很快得到一個結(jié)果。當(dāng)然Jupyter有它的性能問題，所以我們需要做抽樣，將抽樣數(shù)據(jù)放到Jupyter中，這樣做是非常快和高效的。這個流程是我們實踐過并且落地的，在相關(guān)場景中用的比較頻繁，可以快速驗證各種各樣的靈感和想法。
• 數(shù)據(jù)集市：開源方案也是一個自助式的分析工具。

二、業(yè)務(wù)實踐

接下來將分享我們的一些業(yè)務(wù)實踐，主要包括數(shù)據(jù)處理和算法挖掘兩大部分。

1、數(shù)據(jù)處理

（1）切分會話

上圖左邊是切分會話的方式，右邊是公開資料中的微信小程序的生命周期，其實左邊這張圖是右邊這張圖的技術(shù)變體。

我們從APP啟動-進入首頁-關(guān)閉-再啟動-瀏覽各種各樣頁面-各種各樣點擊-看短視頻-關(guān)閉APP，這其實是一個很長的過程。在一個類似信息流的地方，比較高頻的刷，每天的曝光少則幾十，多則人均曝光四五百。所以曝光日志加上各種各樣非曝光日志（比如APP生命周期的啟動、關(guān)閉及Push），整個鏈路是非常長的，如何去切分就非常關(guān)鍵，通常主要有兩種切法：

• 按照事件去切，比如按照啟動和關(guān)閉切分。
• 按照時間去切，右邊放的微信小程序給的方案是30分鐘一次，我們也是按照30分鐘一次去切的，是一個常見值。但是如果大家的APP更加高頻，時間是可以做調(diào)整的。這里只是一個例子，真正的業(yè)務(wù)場景中比較好用的數(shù)據(jù)集不止是切這種日志，還有最細(xì)粒度的行為層面的日志，我們可以30分鐘切一次，也可以1個小時或是1天切一次。

在業(yè)務(wù)實踐中，切分的方式有很多，也是很靈活的，比如可以基于首啟進行切分，每天用戶看的第一個內(nèi)容是什么，也可以基于Push切分，用戶每天點的第一條推送是什么，也可以基于最后一條記錄切分，用戶每天最后看的內(nèi)容是什么。

這里有兩點建議：

• 具體的切分方式按照業(yè)務(wù)場景確定，比如：看流失，可以看流失前的最后三條；看用戶增長，可以看漏斗的第一條；看下單，可以看用戶購物車的部分。
• 在過去幾年的實踐過程中，也有很多跟技術(shù)有關(guān)的迭代。實際中比較好的方式是在埋點SDK層面去做SessionId，就是將SessionId直接寫到埋點中，但是這種方式麻煩的地方就是各個不同模塊需要用同一個埋點SDK。在很多歷史比較久的企業(yè)或者迭代很多版本的地方可能很難做到統(tǒng)一的SDK，但是這里還是強烈建議統(tǒng)一的SDK。比較好的方法是，SDK分前端和后端，但是前端和后端SDK分別去報自己的Session_ID和Sub_Session_ID，將其全部保存至Kafka中。有一點需要注意，同一用戶的時間要保持一致，不同用戶的時間次序不需要完全對得上，比如一個人先看什么，后買什么這個時間次序要保證，但是不需要和另外一個人完全對得上。其實實踐中，對于性能和效率可以做很多取舍。

（2）數(shù)據(jù)處理

數(shù)據(jù)處理，主要包含兩部分內(nèi)容：

• 異常數(shù)據(jù)處理，將異常數(shù)據(jù)去掉才能得出一個相對比較中立的結(jié)論。
• 數(shù)據(jù)抽樣，無偏抽樣永遠(yuǎn)是做好數(shù)據(jù)分析的第一步。

在看所有的分析報告時，異常數(shù)據(jù)是非常值得關(guān)注的。這里有三點需要注意：

• 區(qū)分真實頁面日志。日志上報生成多條記錄，好多日志是多報并且重復(fù)的，這會讓整個場景變得非常的雜亂，所以該部分我們做了大量的工作去區(qū)分什么是真實的頁面和日志，在實踐中，我們將自己的所有行為全部錄下來，然后進行對比，看是否完全一樣，所以區(qū)分真實頁面是非常重要的。
• 合并重復(fù)頁面。用戶在首頁來回刷、來回滑動，會造成某些頁面大量的數(shù)據(jù)重復(fù)，合并后可以得到更清晰的結(jié)果。
• 剔除明顯異常用戶。我們是按照3σ原則進行剔除的。分析時大家不要去看這些異常日志，但是并不是丟掉，應(yīng)該將異常數(shù)據(jù)放在某個地方，專門去看異常用戶存在的原因。剔除這些異常用戶日志是為了分析，但是異常數(shù)據(jù)、異常用戶還是值得關(guān)注的。

數(shù)據(jù)抽樣是為了快速地分析。有兩種方法，一種是使用開源系統(tǒng)，另一種是使用算法挖掘。我們內(nèi)部的做法是將ClickHouse數(shù)據(jù)直接讀到內(nèi)存中，然后用Jupyter計算，在Jupyter中有很多挖掘算法，因此非常需要抽樣。

我們應(yīng)注意的是抽樣的合理性——無偏抽樣，這本身也是數(shù)據(jù)科學(xué)中非常重要的內(nèi)容?？闯闃邮欠窈侠碇饕幸韵路椒ǎ?/p>

• 分布應(yīng)該與大盤一致。
• 參數(shù)檢驗法，比如Z檢驗、T檢驗等，可以使用已有工具進行參數(shù)檢驗。
• 非參檢驗，類似于KS、KL檢驗等。

以上三個內(nèi)容可以做成模板或者包，這樣每次做數(shù)據(jù)分析的時候，跑一下這個流水線，結(jié)論就出來了。

（3）數(shù)據(jù)結(jié)構(gòu)

這里介紹下數(shù)據(jù)結(jié)構(gòu)，也建議大家直接將其做成流水線。

• 原始事件表：按照時間戳記錄用戶的所有行為及頁面曝光，互聯(lián)網(wǎng)常見是基于Event的日志表；
• Session明細(xì)表：就是某個人在某個時間做了什么，整理成Session表，Session表中有Session_ID，Session里還有Sub_Session_ID；
• 用戶Session表：將Session和用戶串起來，一行代表一個用戶，每個Session節(jié)點變成一列；
• 圖結(jié)構(gòu)數(shù)據(jù)表：按照From-To的方式存儲圖的邊和節(jié)點，這樣我們可以用圖算法去做數(shù)據(jù)挖掘。

在實踐過程中，這四大類型的表是我們做一個完整的基于Session的數(shù)據(jù)工程或數(shù)據(jù)平臺所必須的。從分析的角度，不建議非要全量，因為它算起來會比較麻煩，計算量非常大，我們應(yīng)該做抽樣。

一些垂類場景，比如搜索、信息流，本來就是一個非常強的基于時間次序的日志，應(yīng)用得很多。但是從搜廣推場景往外發(fā)展到跟產(chǎn)品相關(guān)的，Session日志相對來說沒有那么多的成熟應(yīng)用。我們看漏斗、用戶增長等還是比較偏原始Event日志。建議大家考慮下自己的業(yè)務(wù)場景有沒有可能把Session用起來，把Session之后的挖掘算法用起來。建議把一些與會話強相關(guān)的業(yè)務(wù)場景轉(zhuǎn)換為Session日志，將基于Event的日志串成Session日志，這樣更容易做分析。

2、算法挖掘

我們整理的數(shù)據(jù)，不能只靠業(yè)務(wù)直覺判斷，需要用算法進行正確的分析。接下來將分享算法挖掘的一些工作。

關(guān)于頻次挖掘，大家一定都聽說過“啤酒與尿布”的例子。這里分享一些與Session有關(guān)的頻次挖掘。

上圖中左上角是一個Session，瀏覽了頁面A、B、C、D，它天然是一個對話的句子，量化行為路徑的思路是：

• 把每個動作想象成一個詞，把這些詞串起來，每一個Session天生就是一個句子。這樣就可以用NLP相關(guān)的算法來解決這個問題。
• 用Word2vec計算各個頁面的n維向量。
• 對每個向量定制化權(quán)重，比如每個頁面權(quán)重都一樣1/n，或者用TF-IDF去做，也可以根據(jù)場景去設(shè)置權(quán)重。
• 用降維算法將n維向量降為2維向量，在實際中具體降到幾維可以根據(jù)具體情況確定，降維主要為了獲取特征向量。

上面已通過降維后的2維向量獲取到特征向量，就可以做聚類了。上圖的左邊是聚類的一個示例，不同顏色標(biāo)代表不同的人群。

下一步就是頻次挖掘。聚類后的人群是什么，這個是不知道的，因為它是一個Embedding的高維空間，所以需要用頻次挖掘的算法，將人群放到各種各樣的挖掘算法中，最后會得到分類。例如有薅羊毛的用戶、閑逛的用戶等。這樣做的好處是，用Embedding和NLP相關(guān)的算法挖掘，而不是依賴于純產(chǎn)品的預(yù)判去做數(shù)據(jù)分析，也可能看到讓我們驚喜的部分。

現(xiàn)在我們開始有大語言模型了，過去的做法是將其放到頻次挖掘算法中，未來或許可以讓GPT告訴我們用戶到底關(guān)注什么。下一步將嘗試用大模型取代Apriori、GSP等傳統(tǒng)機器學(xué)習(xí)的算法來解決問題。

接下來介紹圖挖掘算法，數(shù)據(jù)分析的關(guān)鍵就是我們想要看到平時想不到和未知的部分，這里介紹一個Louvain算法。上圖的例子是有一個非常復(fù)雜的頁面，如果將大量的頁面顯示出來，是無從分析的，根據(jù)這個算法聚類之后，用圖的方法就可以很快形成像右下角這個圖，就明顯很多。聚類有以下好處：

• 便于對路徑進行分類；
• 豐富用戶畫像；
• 便于定位問題，發(fā)掘優(yōu)化點。

這里用到了圖數(shù)據(jù)庫，因為圖數(shù)據(jù)庫本身有預(yù)處理的過程，性能要好很多。這里參考了騰訊云的KonisGraph解決方案，圖數(shù)據(jù)庫非常多，大家也可以用其他開源方案。

三、開源方案

下面分享SessionAnalytis這個開源方案，主要介紹工程實現(xiàn)和Demo示例。

1、工程實現(xiàn)

SessionAnalytics開源方案可以在GitHub中找到。該開源方案相對來說比較完備，有前端、后端、數(shù)據(jù)庫以及Demo數(shù)據(jù)庫，下載下來可以直接使用。該開源項目是將我們理解可以固化的部分盡量固化下來了，所以推薦給大家。

我們的項目架構(gòu)如上圖所示，主要包括：

• 數(shù)據(jù)集成：支持CSV上傳、支持mysql數(shù)據(jù)庫，做日志解析同時也有任務(wù)調(diào)度，系統(tǒng)可以自動去跑數(shù)據(jù)流水線。
• 數(shù)據(jù)計算：數(shù)據(jù)清洗然后做Session切分，切好后可以做結(jié)果表的聚合。
• 數(shù)據(jù)存儲：存在mysql中，后續(xù)計劃換成其他開源方案的，比如Neo4j這樣圖數(shù)據(jù)庫。
• 可視化：主要是基于Echats的，有許多對Echats的自定義的改動。
• 后端框架：SpringBoot，當(dāng)時開源的時候也是本著成本低、好上手并且好復(fù)用的方式去做的。

數(shù)據(jù)結(jié)構(gòu)為：

• 用戶行為日志表：最左邊的表。
• Session日志表：中間的部分，處理成Session日志的時候，會做兩個版本，一個版本是重復(fù)事件不合并，另一個是合并重復(fù)事件。
• 維度表和結(jié)果表：參考Kimball建模，生成兩種，一種是比較偏Session型的，一種是From-To式的圖數(shù)據(jù)庫。

接下來講下開源方案是怎么做的。左邊是例子，右邊是對應(yīng)的代碼供大家參考。數(shù)據(jù)導(dǎo)入后，可以指定用什么事件或什么時間間隔來切分。在這里，我們計算Session切割點，然后生成了Session_ID及Sub_Session_ID。

現(xiàn)在很多平臺都支持用戶路徑，但是使用過程中，發(fā)現(xiàn)很多不好用的地方。比如Echarts隨機生成桑基圖顏色。例子中“娛樂”的每層顏色是不一樣的，我們的解決方案是用顏色表，只要是相同的頁面，每層顏色都是一樣的，這是第一個優(yōu)化點。

第二個是層級一致性，Echarts自帶插件無法按照層級進行排列，數(shù)據(jù)顯示比較混亂，我們將相同層級放到同一列，這是另外一個定制。

第三個是全局篩選，在實際業(yè)務(wù)場景中，數(shù)據(jù)量比較大的時候，維度是非常多的，所以該開源平臺提供了全局篩選的能力。

第四個是聯(lián)動篩選，數(shù)據(jù)量太大了，不想影響用戶的關(guān)注，做了聯(lián)動篩選。

第五個是維度分布，點桑基圖的每一步，會彈出來一個框，顯示具體的人群是什么，展示了細(xì)節(jié)的指標(biāo)和分布，可以下鉆。

我們要更多地站在用戶的角度，去看為什么我們的數(shù)據(jù)平臺用不起來，它遇到的問題是什么，其實很多是跟交互有關(guān)的。用戶路徑是一個例子，原生的?；鶊D出來之后，是非常散的顏色都是亂的，大家沒法看，所以很多優(yōu)化是在可視化方面。

最后一個是跟性能有關(guān)的異步上傳，因為當(dāng)用戶量很大時，我們要離線跑流水線，不讓用戶等。

2、Demo示例

場景一是關(guān)于流量異動的，用它很容易看出來流量到底從哪兒變了。比如可能是Push帶來很多人，后來又流失了很多。其實在看?；鶊D之前，我們會有一個直覺的判斷，但是看到之后可能發(fā)現(xiàn)我們的直覺判斷是不準(zhǔn)的。尤其是像互聯(lián)網(wǎng)這種用戶增長，渠道分享到某個地方，或者某個地方來了很多黑產(chǎn)用戶，或者某個業(yè)務(wù)場景忽然吸引了很多人，這種都會引起流量非常大的波動。因為我們做一個產(chǎn)品，真正用戶喜歡什么，其實也很難完全百分百猜出來，通過這種?；鶊D，就容易確定問題和原因。

場景二與挖掘有關(guān)，舉例是開源平臺支持的時序聚類。在信息流或推薦系統(tǒng)場景中，一個很大的問題就是冷啟動，包括用戶冷啟動和內(nèi)容冷啟動。因為冷啟動的時候，我們沒有那么多的上下文信息，我們并不知道什么東西會被喜歡，我們遇到一個很大的問題是一個很好的文章或視頻就是分發(fā)不起來，或者一個不是很好的視頻忽然火了，很難知道原因。但是對于我們做推薦的人或者內(nèi)容分發(fā)的同學(xué)，就要去研究一個內(nèi)容起來或沒起來的原因。這種場景就比較偏愛時序聚類了，把維度換一下，用戶換成文章，UserId換為DocId，也可以做基于內(nèi)容的Session。所以遇到內(nèi)容冷啟動，也推薦使用時序聚類。

場景三與漏斗有關(guān)，這里分享一個關(guān)于用戶增長的例子：Push拉活進入APP之后，用戶莫名其妙的就丟了。

早期我們只看用戶增長的時候，只是說一個漏斗流下來，當(dāng)100個人漏到50個人的時候，后面的50可能來自另外100個人。但是現(xiàn)在有了時序和Session的好處是我們能夠明確這50個人是基于這100個人的，用Session將其串起來是有明確價值的。

建議大家有了Session挖掘的框架之后，可以根據(jù)具體業(yè)務(wù)場景進行替換。

• 我們的用戶路徑User Session可以換成Doc Session，變成內(nèi)容路徑。
• 可以將點擊日志和曝光日志換成時長日志，就可以看出這100分鐘怎么變成20分鐘的，100分鐘與20分鐘之間是斷的，加上漏斗是50%，但是它隔的時間不一樣，有些地方間隔很長，間隔時間特別長的地方也有可能有很大的業(yè)務(wù)價值。

該應(yīng)用可以發(fā)散出很多場景，維度和指標(biāo)都是可以換的，可以幫助我們發(fā)現(xiàn)很多想象不到的現(xiàn)象。

四、對比

很多數(shù)倉是基于Event的，基于Session的正慢慢興起。在有些場景中，Session變成至關(guān)重要的日志。這里從多個角度對比，基于Session的用戶路徑分析與基于Event的用戶事件分析，能夠提供的額外價值。

• 業(yè)務(wù)和日志：Session可以很好地反映用戶的行為次序。在統(tǒng)一的用戶Id體系中，將各場景的行為日志統(tǒng)一，并按照時間次序分析關(guān)聯(lián)和影響。
• 可視和交互：可視化方法多樣，交互分析強大：基于桑葚圖、和弦圖、樹狀圖等圖表，可以很容易將用戶看清。
• 統(tǒng)計方法：我們把日志換成不同格式之后，可以用NLP、Apriori和DTW等挖掘算法的智能分析。
• 分析效率：基于ClickHouse、Jupyter對海量數(shù)據(jù)進行快速分析。

五、Q&A

Q1：頁面曝光實際是有多個控件都需要上報嗎？具體時間是SDK做自動采集還是代碼埋點，如何保證上報邏輯一致？終端后臺是否session合并起來？

A：在實際做的過程中，我們是把能上報的盡量放到一起，能用的先用起來。因為數(shù)據(jù)團隊相對比較偏下游，對上游很難做到完全不遺漏的數(shù)據(jù)治理，所以盡量把那些能用起來的先用起來。對于保證邏輯一致，我建議兩種做法，一種做非常重的監(jiān)控，因為我們沒有辦法完全保證上游，所以做非常重的智能監(jiān)控，將各種各樣的都監(jiān)控起來，有問題后馬上去查；第二種建議考慮所有場景采用無埋點的SDK去解決這個問題，報上來的東西同一套標(biāo)準(zhǔn)，就可以比較好的解決這個問題。

Q2：key要選什么樣的trick，聚成幾類？

A：聚成幾類，可以按k-means做法中的手肘原則，或者有輪廓系數(shù)等參數(shù)。開源框架中會預(yù)先幫大家把手肘的那個圖畫出來，也會預(yù)先幫大家將輪廓系數(shù)算出來，在實踐中也是這樣參考的。

Q3：用戶路徑數(shù)據(jù)分析可用到推薦系統(tǒng)的方面有哪些？

A：跟推薦系統(tǒng)有關(guān)的有兩大部分，一個是跟算法關(guān)系特別強的，一個是比較偏運營的部分。主要還是看有次序的日志，算法本來就有類似LSTM等去串次序。除此之外，我們把用戶依次序來看，比如多次召回，之后又做多次Ranking，這中間的用戶和內(nèi)容的變化關(guān)系，是可以深入分析的。

Q4：策略產(chǎn)品可以做什么？

A：關(guān)于策略，這里分享兩個點，一個是用戶冷啟動，一個是內(nèi)容冷啟動。我相信做推薦的同學(xué)，經(jīng)常被靈魂拷問的就是一個內(nèi)容怎么推薦不來，好文章為什么起不來。內(nèi)容冷啟動，可以去看為什么起不來。在次序的角度去看內(nèi)容是特別多的場景。然后就是用戶冷啟動，那把日志串起來去看用戶的熱身過程。

Q5：可否具體介紹一下冷啟動？

A：用戶冷啟動就是在用戶畫像不足的時候，一個用戶進來到底推什么，有很多算法可以做，比方說MAB多臂老虎機，或者算法中這種E&E問題，關(guān)鍵還是用戶進來的前幾百條日志，也就是對前幾百個行為去更深地看細(xì)節(jié)。內(nèi)容冷啟動解決的問題是一個好的內(nèi)容怎么快速熱起來，因為通常來說一個經(jīng)驗值吧，一個好的文章進來，如果24小時起不來那基本就很難起來了。一個好的視頻進來，我的經(jīng)驗是2-3天起不來，那也就起不來了，那在這個時候會做很多工作去細(xì)看那些出不來是怎么樣。

Q6：怎么做渠道歸因？

A：渠道歸因有很多做法。通過不同渠道拉來的用戶都是不一樣的。很多快速做法是看首啟。比較智能的做法是，用機器學(xué)習(xí)和訓(xùn)練的方式來做，比如定義關(guān)鍵影響指標(biāo)為Y，在多重渠道X的情況下，去看每個渠道對最終結(jié)果的影響，相當(dāng)于每個渠道的權(quán)重系數(shù)是智能的。如果跟用戶路徑有關(guān)，可以結(jié)合次序定義參數(shù)，其實很多時候比較麻煩的是：今天買了一個商品，可能是因為看了一個短視頻，購物車逛了一下，又逛了下信息流，然后別人又給社交推薦，它有多個次序，單看單個動作是很難歸因的。這種用戶量級比較大場景多變復(fù)雜的時候，我們?nèi)ビ媒y(tǒng)計或機器學(xué)習(xí)的方法，就方便得出量化參數(shù)。

來源：DataFunTalk