日志采集這部分內容惧辈，其實在上一篇文章 大數據之路讀書筆記 里面多多少少已經提到了一些。不過正如前文提到的磕瓷，這部分內容盒齿，從技術的角度來說，未必有多么高深困食，但是從業(yè)務角度來說边翁，要做到完善卻也很難，特別是在分析用戶行為鏈路的場景下硕盹，所以這篇專門來討論一下這一塊的內容符匾。

所謂用戶行為，就是用戶在你的網站或者APP上所做的動作瘩例，比如：搜索內容啊胶，瀏覽頁面，觀看視頻垛贤，購買商品焰坪，收藏，評論等等南吮。

那為什么要采集和記錄用戶的行為呢琳彩？吃飽了沒事干，窺探用戶的隱私么部凑？

當然不是露乏，說好聽點，是為了提高產品服務質量涂邀，提供個性化服務瘟仿，說直接點呢，本質上還是為了更好的賺錢唄比勉。在流量換金錢的互聯網商業(yè)模式下劳较，尤其是下半場階段驹止，流量的價值，無庸置疑观蜗，來之不易的流量臊恋，當然需要珍惜了。所以搞清楚你的用戶在自己的網站／APP上到底都做了什么墓捻，想要做什么抖仅，可以被"拐騙"去做些什么，也就至關重要了：）

要搞清楚這些砖第，當然要有數據撤卢，所以，你需要采集和分析用戶的行為梧兼，而行為日志放吩，無疑是最主要的數據來源。

記個日志有什么難的羽杰？

要想把用戶行為分析得徹底渡紫，那就需要全方位的采集數據，“全方位”這幾個字忽洛，實際上就是在類似我司這種業(yè)務鏈路復雜的電商環(huán)境下的系統中腻惠，日志采集最大的難點所在了。

全方位欲虚，意味著不能遺漏集灌。這實際上又包括了幾層涵義：

首先，頁面全覆蓋复哆。類似我司這類業(yè)務場景的系統欣喧，用戶交互界面繁多，用戶交互的行為也是多種多樣梯找。商品搜索唆阿，圖墻瀏覽，資訊分享锈锤，收藏驯鳖，加購，下單久免，支付浅辙，評論。阎姥。记舆。而這些行為的載體也是多種多樣，PC端呼巴，移動端泽腮；H5御蒲，native；IOS诊赊，安卓厚满；應用內打開，微信小程序內打開等等豪筝。

每個業(yè)務痰滋，每種載體摘能，每個渠道续崖，可能都是由不同的開發(fā)同學負責的，那么如何做到全覆蓋呢团搞？完全靠每個開發(fā)同學自己埋點严望，顯然不太現實。時間和工作量不是最大的問題逻恐，要保證數據的統一和不遺漏才是最大的麻煩所在像吻。

其次，是流程上的全覆蓋复隆。用戶的行為是有前后關聯關系的拨匆，獨立的用戶行為的采集統計固然重要，比如PV／UV這種用來騙取投資的用戶流量類數據挽拂。與此同時惭每，完整的用戶行為鏈路的分析也是必不可少的，比如購買決策鏈路亏栈，會場活動效果分析台腥，廣告流量來源去向統計等等。

這時候绒北，往往就需要在行為日志的采集過程中黎侈，附加必要的關聯信息來實現行為的串聯。

你可能會想闷游，那就讓所有的業(yè)務用統一的框架接口來采集日志峻汉，需要什么用于關聯業(yè)務的信息，自己記錄不就好了唄脐往，聽起來也沒多難休吠。

確實如此，事實上钙勃，各種各樣的流量入口平臺蛛碌，第三方網站／應用統計服務提供商等也都提供了類似js腳本，日志服務接口辖源，日志采集SDK等手段來標準化這件事蔚携。比如Goggle analytic希太，百度統計，Talking Data酝蜒，Growing IO等等誊辉。從這個角度來看，這種方案本身亡脑，還是比較標準的堕澄，你自己開發(fā)起來，模式也不會偏離太多霉咨。

但是蛙紫，大方向沒問題，不代表實現起來也很容易途戒。要做到前面所說的全覆蓋的能力坑傅，JS也好，SDK也好喷斋，就得做到盡可能的降低對業(yè)務代碼的侵入唁毒，特別是基礎的頁面瀏覽類日志，最好能做到無需業(yè)務方主動調用相關代碼邏輯星爪。因為但凡需要業(yè)務方主動配合浆西，開發(fā)代碼才能完成的日志采集方案，就有可能因為各種原因顽腾，遺漏（忽視）開發(fā)這部分代碼近零，造成統計的遺漏。

而業(yè)務流程的串聯崔泵，也不僅僅是附加關聯信息那么簡單秒赤。舉個例子，比如想要做頁面來源跟蹤憎瘸，有很多種方案入篮，比如植入Cookie，然后在具體頁面采集cookie信息判斷初始來源幌甘，比如在入口或落地頁面生成一個唯一標識ID潮售，然后將這個ID作為參數向后傳遞等等。這些方案锅风，在某些場景下也的確是可行的酥诽，但是一旦遇到多條業(yè)務鏈路可能有交叉，或者鏈路邏輯變化頻繁的情況皱埠，這些方案的邏輯就有可能隨時被打破了肮帐。

因此，通用，可靠训枢，維護代價低托修，這三者在日志采集的方案設計中，通常是最重要的考量因素恒界。當然睦刃，實際情況下，在一些業(yè)務場景中十酣，這三者可能很難同時做到涩拙，也就不排除某些鏈路需要定制化處理的可能性。

此外耸采，還有很多問題兴泥，這里先不單獨提出來討論了，在下面介紹我司的一些實踐和方案的過程中一并闡述洋幻。

我司的用戶行為日志采集方案

整體流程

我司日志采集的整體流程也很標準：頁面瀏覽類日志郁轻，在Web端使用js采集頁面信息，然后向日志服務器特定URL發(fā)起一次http請求文留，將采集到的數據作為參數傳遞過去。日志服務器響應請求竭沫，記錄信息燥翅，落盤。服務端日志采集Agent收集日志蜕提，再匯總發(fā)送給下游鏈路森书，比如Kafka消息隊列之類。

為了減少對業(yè)務代碼的侵入和保障頁面的全覆蓋谎势，js腳本是在服務器后端通過模版嵌入到每一個頁面的凛膏。

而用戶點擊交互類日志，還是需要業(yè)務方自行處理業(yè)務邏輯脏榆，然后調用標準接口發(fā)送給日志服務器猖毫。

APP端則通過SDK提供接口給業(yè)務方，封裝底層組件的差異和日志Log方式的具體實現须喂，降低開發(fā)難度

日志埋點的管理

不論是瀏覽類日志還是點擊交互類日志吁断，都會打上特定的事件ID進行標識，便于后續(xù)統計坞生，細節(jié)后面再說仔役。

這些ID標識，瀏覽類的是己，大多都是按規(guī)則自動生成的又兵，也有重點頁面是通過注冊預先指定的(比如商品詳情頁什么的）。而點擊交互類日志的事件ID卒废，則都是通過后臺沛厨，統一注冊登記管理乘盼，生成唯一ID后，再由業(yè)務開發(fā)方通過SDK記錄下來的俄烁。

在Web端绸栅，埋點的實施是即時生效的，服務器端代碼修改以后页屠，在客戶端瀏覽器里下一次加載頁面時就能生效（當然粹胯，如果你有CDN靜態(tài)資源緩存的機制，還要考慮如何淘汰舊的緩存資源）辰企。

而在APP端风纠，往往需要通過版本發(fā)布的流程才能更新代碼，所以埋點的實施牢贸，需要提前規(guī)劃竹观，也無法動態(tài)更新。這時候就有人提出動態(tài)埋點的技術了潜索，多數情況下臭增，絕大多數所謂的動態(tài)埋點技術，也就是先全部無差別的把所有可能的埋點位置先埋上代碼竹习，先不啟用誊抛，需要的時候再帶開開關。

我司在APP端目前也還沒有做到動態(tài)無痕埋點整陌，所以交互類日志埋點的全覆蓋拗窃，還是依靠業(yè)務上線前預先規(guī)劃統計需求试和，制定埋點方案瓮增，注冊管理，測試驗證這樣的流程來保證的潭枣。在業(yè)務快速變化的過程中震放，這么瑣碎的事務宾毒，光靠人工來保證也是比較困難的。為此澜搅，我司也針對性的開發(fā)了專門的管理后臺來串聯相關工作流程伍俘。

PV UV和獨立交互類事件統計

PV UV 類的獨立頁面統計分析，理論上來說勉躺，通過頁面訪問記錄癌瘾，獲取URL進行正則匹配來做也是可以的。但是這樣做也會存在很多問題饵溅，比如正則匹配的計算效率比較低妨退，大量頁面的情況下URL正則匹配的規(guī)則難以管理，規(guī)則之間互相之間會不會重疊？一些動態(tài)生成的頁面咬荷，URL甚至可能無法通過正則匹配進行合理的歸類冠句，新業(yè)務的頁面URL如何保證不和原有業(yè)務的匹配規(guī)則不沖突等等⌒移梗總之懦底，通過URL進行正則匹配，雖然可行罕扎，但是維護代價極高聚唐。

所以，更好的方式是給各個頁面賦予一個唯一的ID腔召，當然考慮到統計的需要通常是按一類頁面進行統計杆查，所以這個唯一ID一般也是賦予同一類頁面，而不是每一個具體的頁面實例的臀蛛。（比如搜索圖墻亲桦，每次用戶搜索生成的數據都是不一樣的，當然沒辦法也沒有必要給每個搜索結果頁面一個唯一的ID標識）

而用戶點擊交互類的日志浊仆，也是如此了客峭，交互事件當然可以有可描述的文本，但是從統計的角度來說氧卧，還是賦予每個事件一個唯一ID比較靠譜一點桃笙。

有了ID，在后續(xù)統計中沙绝，對各個ID，進行分組聚合就好了鼠锈。

用戶瀏覽行為鏈路跟蹤方案

相比通過獨立的單條日志就能完成的簡單匯總類統計來說闪檬，用戶瀏覽行為的鏈路跟蹤，就麻煩很多了购笆。比如想要知道用戶是如何到達一個特定的商品頁面的粗悯，是通過首頁的廣告位，還是通過會場活動同欠，抑或是首頁／圖墻／商鋪／詳情這樣的瀏覽鏈路過來的样傍，這就需要串聯多條日志才能完成相關的分析工作。

舉一個實際的場景例子铺遂，作為電商類平臺衫哥，往往需要跟蹤一個訂單的下單鏈路，也就是所謂的訂單來源分析襟锐，做什么用呢撤逢？用途也很多，和錢掛鉤的，比如要統計CPS廣告推廣的費用啊蚊荣。

這種業(yè)務場景初狰，透過URL匹配或者單純的頁面ID來做就會比較棘手，因為用戶的瀏覽行為可能是反復隨機跳轉的互例，可能存在重復的瀏覽行為路徑奢入。如何鑒別他是通過哪條路徑過來的呢？ 對日志做一下時間排序可能是一種解決方案媳叨，但是日志如果存在亂序到達腥光，或者丟失的情況，如何能夠發(fā)現呢肩杈〔裎遥總之，做也是可以扩然，但是代價和可靠性都會是比較大的問題艘儒。

當然，也并不是所有的鏈路分析場景都需要進行多跳分析夫偶，傳統的頁面轉換率分析這種群體行為的聚合統計類分析界睁，只涉及到一次頁面跳轉的來源去向兩個頁面，與具體跳轉鏈路無關兵拢，還是容易處理的翻斟。

對于類似訂單來源這種多次跳轉類行為的精確分析，很容易想到的一種方式就是在作為可能來源的入口頁面说铃，埋下一個唯一標識访惜，然后一路透傳到最后的訂單頁面為止，這樣事后統計分析時腻扇，省去頁面跟蹤的過程债热，直接獲取這個標識就好了。

理論上幼苛，這也是可行的窒篱，關鍵是怎么透傳這個參數？比如通過cookie記錄舶沿，或者生成一個唯一的TraceID墙杯，然后一路通過URL傳參往下游發(fā)送。對于cookie來說括荡，一方面種cookie的代價比較高高镐，另一方面?zhèn)€數也是有限的。而對于URL傳遞TraceID參數這種方式來說一汽，意味著業(yè)務鏈路上的所有頁面都要特殊處理這個參數避消，繼續(xù)往下游傳遞低滩，一來代價更高，二來用戶的瀏覽行為很隨意岩喷，三來業(yè)務的流程也隨時可能變更恕沫，因此這種方案的維護代價和可靠性也是堪憂的，而且如果需要跟蹤的業(yè)務流程類型越來越多纱意，這種ID和Cookie的方式也是無法擴展的婶溯。

所以，個別業(yè)務鏈路這么處理可能可以偷霉，作為通用的解決方案還是不行的迄委。

那么怎么做呢？ 我司當前的方案是仿照阿里的SPM編碼方案类少。 這個方案叙身，阿里對外的文章都是語焉不詳的，我估計稍微有點敏感硫狞，畢竟需要考慮刷流量作弊等問題信轿，不宜過多宣傳，原理介紹得太多残吩，不是要被人鉆空子么 财忽；）不過其實有心人真想分析一下也是不難的。所以大概說一下我覺得也沒有什么大不了的泣侮。當然即彪，還是不要以我司為例了，以阿里的SPM方案為例吧：

SPM編碼是用來跟蹤頁面模塊位置的編碼活尊，早期的spm編碼由4段組成隶校，采用a.b.c.d的格式，后來添加了e字段蛹锰，所以總共5個字段組成惠况，你可以在阿里系幾乎所有的業(yè)務頁面中看到spm參數，具體怎么用這幾個字段其實還是根據不同的業(yè)務場景來劃分的宁仔，并不完全一樣。不過峦睡，對于多數的業(yè)務場景來說翎苫，大致相同，比如榨了，以下面這個在淘寶首頁點擊中間Banner廣告的行為為例

在點擊廣告打開的頁面的URL上煎谍，你會看到 spm=a21bo.50862.201862-1.d1.5dcec6f7XFdlFJ 這樣的內容，其中：

• a字段代表的是站點或者你可以認為是一個大的業(yè)務龙屉，這里a21bo應該就是淘寶了（相對天貓這種業(yè)務而言呐粘，具體a字段的值满俗，有時候也會變，這個看淘寶的心情了吧）
• b字段代表了這個業(yè)務下的頁面ID作岖，比如這里的50862就是淘寶首頁了
• c字段代表了具體的一個鏈接在頁面中的模塊唆垃，你就理解為是為了再拆分頁面的層次結構就好了，這里的201862-1痘儡，201862指的是首頁正中的Banner廣告位模塊辕万，-1是為了進一步定位這是這種輪播位置的第一個坑位。
• d字段代表的是點擊的鏈接在模塊內部的索引位置沉删，這里d1就是第一個位置了（Banner位特殊渐尿，只有一個位置）
• e字段是一個按特定規(guī)則生成的UniqueID，比如這里的5dcec6f7XFdlFJ矾瑰，用來區(qū)分不同的Session或者點擊的砖茸，具體實現也和業(yè)務有關，你可以理解為為了區(qū)分同一個鏈接在不同的瀏覽鏈路實例中的點擊之用殴穴。區(qū)分這個有什么用呢凉夯？理論上可以有太多用途了，比如反作弊等等推正，有些敏感恍涂，不便細談 ；）

到這里植榕，可以看到SPM就是一個分層級的定位體系再沧，這么做的好處很多，比如根據不同的統計粒度需求尊残，可以摘取特定字段進行匯總炒瘸，匯總的規(guī)則也非常標準，與具體業(yè)務幾乎無關寝衫。

比如需要按頁面類型統計PV顷扩，那么取a.b兩個字段分組聚合就可以了。如果要統計具體頁面模塊的流量慰毅，那么統計到a.b.c字段就好了隘截。要精確定位某一個推薦欄位的效果，就需要用到a.b.c.d四個字段汹胃。這里只是舉例婶芭，實際一些業(yè)務如何規(guī)劃這幾個字段的層級，也不完全是絕對映射這種關系的着饥，重要的是理解這種分層的目的和收益犀农。

所以，分級定位的方式簡化了普通聚合匯總類分析的難度宰掉，但是SPM和用戶的瀏覽行為鏈路又有什么關系呢呵哨？

前面看到赁濒，SPM參數唯一標識了特定站點頁面模塊內部的一個鏈接，這個參數實際上是在用戶點擊該鏈接的時候孟害，自動生成并附加在目標鏈接的URL地址上的拒炎，所以在一個頁面的URL上的SPM參數，實際上表示的不是這個頁面的SPM參數纹坐，而是這個頁面的點擊來源的SPM參數枝冀，也就是上一個頁面中打開當前頁面所用到的鏈接的位置參數。所以URL中SPM的abcde五個字段都是上個頁面的信息耘子。

至于當前頁面的SPM信息果漾，你還沒有點擊鏈接呢，cd這兩個和具體點擊位置相關的字段自然是沒有的谷誓，但是ab這兩個和頁面綁定的字段是存在的绒障，e這個session判斷標識也是可以提前確定的。

所以捍歪，在頁面打開以后Log的日志里面户辱，我們可以記下URL中鏈接來源SPM的5個字段，以及當前頁面SPM的abe三個字段糙臼。這樣通過abe三個字段在頁面之間就可以形成一個鏈表關系庐镐，通過追蹤這個鏈表我們就可以還原用戶的瀏覽行為鏈路了。 如果要具體統計模塊位置的流量变逃，再把來源頁面的cd字段補上就好了必逆。

這個邏輯是不是有點繞？ 的確如此揽乱，所以此前在開發(fā)過程中名眉，每次和我司的各種客戶端開發(fā)同學討論這個方案的時候，都要費不少的口舌凰棉。

不過這大概也算是鏈路跟蹤里相對靠譜的方案了损拢，這個方案，阿里系的網站已經沿用和發(fā)展了十幾年了撒犀，模仿這個方案的還有比如美團的MTT參數福压。當然也有更多的大公司沒有采用這種方案，不知道是沒有在意過這種方案呢或舞，還是有其它解決手段隧膏，抑或只是依靠URL來解決問題。

我猜可能兼而有之嚷那，畢竟這套方案實施起來要全站貫穿，全端實現杆煞，如果有歷史包袱的話魏宽，代價確實也是很高的腐泻。而URL匹配的方案，雖然計算效率差一些队询，存在這樣那樣的維護問題派桩，但是如果不是特別注重個體鏈路的精確分析的話，輔助以其它手段蚌斩，絕大多數的業(yè)務場景铆惑，也還是能找到一些解決辦法的，不是完全無解送膳。

SPM的原理很簡單员魏，就是用格式化的字段分層定位唄，那么SPM方案的難點在哪里呢叠聋？

難點還是在于這幾個字段具體值的規(guī)范化撕阎，如何盡可能減少對業(yè)務方代碼邏輯的侵入。參數已經細化到每一個鏈接碌补，自然不可能手動維護每個字段的值虏束，這就需要盡可能自動化的生成這些參數，而對于特定的頁面或者模塊還要保留自定義的能力厦章，以備特殊用途之用镇匀。

如何自動化生成各字段的ID信息，這就不是一件簡單的事了袜啃，不同的字段汗侵，不同的客戶端環(huán)境：Web／IOS／安卓，不同的控件對象囊骤，如何生成唯一的ID標識晃择，又不需要業(yè)務方太多的干預或者配合，這就要各顯神通了也物。宫屠。。

隨便舉一些例子：

A字段好說滑蚯，畢竟站點／業(yè)務 級別的種類不會太多浪蹂，直接預定義好，寫入頁面的后臺公共模版就好了告材。

B字段呢坤次？比如在Web端，可以采用后臺具體頁面模版的URL的Hash值斥赋，找一個不容易沖突的Hash函數基本就可以了缰猴。

那么C字段呢？C字段的ID疤剑，通常只需要頁面內部唯一滑绒，所以ID值本身自動生成一個問題不大闷堡，倒是如何確定一個模塊的范圍是比較大的問題？可行的方案疑故，比如在Web頁面模版中杠览，可以通過對頁面標簽添加特定屬性的方式來標識模塊范圍，然后在點擊時再自動為這個標簽生成一個固定的ID纵势，然后再根據這個標簽的范圍計算模塊內部鏈接的D字段索引值踱阿。

但是，也不是所有的模塊ID都只需要頁面內唯一就沒問題了钦铁，有些模塊是跨頁面共享的软舌，這種場景是預定義一個特殊ID加以標識，做到全局唯一育瓜，還是依然只考慮頁面內唯一葫隙，那就看業(yè)務統計的需要了。

簡單來說躏仇，就是既要保留自定義的能力恋脚，又要在不打算自定義的場景下，找到一個自動生成唯一且固定的標識的途徑（UUID這種純粹隨機焰手，每次生成結果都不一樣的值當然是不行的）糟描，以免業(yè)務方需要自己生成和維護ID列表。

而植入和串聯這些ID的過程书妻，也有各種各樣的問題要解決船响，特殊定制化處理都不難，難就難在要以通用的方式躲履，標準化的處理见间，總之，一切都是要圍繞著降低維護代價來考慮工猜。

其它問題

上一篇的讀書筆記在討論阿里的日志采集鏈路的過程中米诉，其實也已經提到了一些問題。

比如用戶在客戶端進行的頁面回退行為的識別篷帅，需要對這種行為加以識別和篩選史侣。PC端問題少一點，因為可以同時打開多個頁面魏身，用戶回退的行為會少一些惊橱。而在APP端，通常只能同時打開一個頁面箭昵，所以比如從詳情頁回退到商品列表頁面税朴，再次打開另一個詳情頁，這種情況就會很普遍。很顯然掉房，要分析頁面轉化率茧跋，你不能認為商品列表頁面的來源是上一個詳情頁吧，所以肯定要對這種行為進行修正處理卓囚。至于怎么識別和修正這種行為，細節(jié)就不討論了诅病。

Hybrid混合模式的處理：H5和Native頁面混合使用的場景越來越普及哪亿，雖然用戶未必能夠感知，但是從原理上來說贤笆，這兩種頁面的日志采集方案通常是兩套架構蝇棉，互相之間的日志流程也往往是隔離的，但是在鏈路跟蹤的場景下芥永，他們的日志必須要統一處理才能正確的復現用戶的行為路徑篡殷。

所以通常是要自動識別H5頁面的運行環(huán)境，并且打通H5跳轉到Native和Native跳轉到H5兩個方向的頁面數據傳遞埋涧，否則在Hybrid場景下板辽，行為鏈路的日志就會被打斷了。

再有棘催，比如當存在頁面301/302 重定向的行為時劲弦，鏈路參數怎么處理？當要跟蹤訂單成交鏈路時醇坝，用戶是先加了購物車邑跪，過后，再從購物車里下的訂單呼猪，又怎么追蹤原始成交鏈路画畅？還有更多的類似問題，都是用戶行為日志采集過程中需要解決的宋距。雖然每一個點轴踱，單從技術的角度來說，都未必很難乡革，但要做到通用寇僧，完善，可靠沸版，卻不是一兩天可以搞定的事情了嘁傀。因此用戶鏈路行為跟蹤和分析的日志采集，會是一個隨著業(yè)務的發(fā)展视粮，需要持續(xù)改進的工作细办。

小節(jié)

我司在用戶行為鏈路跟蹤分析方面，日志的采集方案主要參考了阿里的SPM的思想。前前后后實踐了也有快三年的時間了笑撞，原理和思想本身并不復雜岛啸，但是在方案完善的過程，包括歷史方案的兼容遷移過程中茴肥，還是花費了不小的力氣坚踩，填補了各式大坑小坑。

總體來說瓤狐，該方案瞬铸，在各種精確鏈路追蹤，來源分析础锐，活動統計等業(yè)務場景中都有不錯的表現嗓节，不過，在應用模式上皆警，我司的實踐還不夠充分拦宣。不光是從標準化自動化的角度來看，也包括業(yè)務的應用場景和相關鏈路數據價值的進一步挖掘方面信姓，都還有很大的發(fā)揮和改進空間鸵隧。

常按掃描下面的二維碼，關注“大數據務虛雜談”财破，務虛掰派，我是認真的 ；）