一、概覽

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

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

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

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

• 描繪用戶生命周期：作為數(shù)據(jù)從業(yè)者，常常需要看清某個(gè)業(yè)務(wù)或場景，除了BI工具以外，用戶路徑分析也是一個(gè)比較行之有效的方法，通過圖表能夠一目了然地看清流量走向。
• 識(shí)別用戶體驗(yàn)問題：用戶增長成本高昂，由于各種體驗(yàn)問題，造成大量用戶流失，在這中間能夠找到一些業(yè)務(wù)增長點(diǎn)。
• 提升數(shù)據(jù)質(zhì)量：除了被產(chǎn)品和運(yùn)營提需求、被發(fā)現(xiàn)數(shù)據(jù)bug外，我們希望能夠主動(dòng)地提升數(shù)據(jù)質(zhì)量。用戶路徑分析可以使業(yè)務(wù)展示更加清晰，能夠識(shí)別出用戶數(shù)據(jù)的各種問題；另外，當(dāng)把一個(gè)數(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ù)集成、中間的存儲(chǔ)、上面的應(yīng)用和服務(wù)部分組成。這里重點(diǎn)分享下與Session有關(guān)的部分。

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

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

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

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

（1）切分會(huì)話

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

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

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

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

這里有兩點(diǎn)建議：

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

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

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

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

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

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

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

我們應(yīng)注意的是抽樣的合理性——無偏抽樣，這本身也是數(shù)據(jù)科學(xué)中非常重要的內(nèi)容。看抽樣是否合理主要有以下方法：

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

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

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

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

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

在實(shí)踐過程中，這四大類型的表是我們做一個(gè)完整的基于Session的數(shù)據(jù)工程或數(shù)據(jù)平臺(tái)所必須的。從分析的角度，不建議非要全量，因?yàn)樗闫饋頃?huì)比較麻煩，計(jì)算量非常大，我們應(yīng)該做抽樣。

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

2、算法挖掘

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

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

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

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

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

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

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

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

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

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

三、開源方案

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

1、工程實(shí)現(xiàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

2、Demo示例

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

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

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

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

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

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

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

四、對比

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

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

五、Q&A

Q1：頁面曝光實(shí)際是有多個(gè)控件都需要上報(bào)嗎？具體時(shí)間是SDK做自動(dòng)采集還是代碼埋點(diǎn)，如何保證上報(bào)邏輯一致？終端后臺(tái)是否session合并起來？

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

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

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

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

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

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

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

Q5：可否具體介紹一下冷啟動(dòng)？

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

Q6：怎么做渠道歸因？

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