在網(wǎng)頁運營改版進程中，經(jīng)常有設計師或許運營搭檔有這樣的疑問：我的頁面到底發(fā)生了多大價值？這個頁面引導的用戶接下來拜訪了多少商品的頁面？有沒有發(fā)生交易？有沒有到我想讓用戶去的那些頁面？

假如運用數(shù)據(jù)庫查詢，固然能夠得到一些成果，但查詢進程過于雜亂，數(shù)據(jù)量大的網(wǎng)站查詢耗時太長，很難靈敏應用到一般頁面。本文提出一種相對簡略的剖析方法能夠解決這個問題。

每個用戶在網(wǎng)站上的拜訪軌跡在網(wǎng)站日志或許數(shù)據(jù)庫中，都是一串URL，有的只拜訪了一兩步，有的拜訪了成百上千步，如安在如此雜亂繁復的數(shù)據(jù)中找到用戶在拜訪某個頁面（例如服裝首頁）之前或許之后n步，有多少人拜訪過特定頁面（例如交易頁面）？

先拋開這個問題，咱們幻想這樣一個場景：在一個大會場中，熟人坐在某個座位上，假如咱們知道他們的位置，咱們的眼睛很簡略聚集到這幾個位置，自動疏忽其他座位的人，請參看圖1。相同，人們在調(diào)查周圍事物時，經(jīng)常會把精力聚集到自己關懷的事物上，下意識疏忽其他。咱們從前做過這樣的試驗，咱們的報告廳有4個很大的外置式擴音器，排列在兩側(cè)。注意不是那種不顯眼的內(nèi)置式，任何人只要稍微留神就會看到。而當咱們要求會場的人閉上眼睛回答會場有幾個擴音器時，很少有人能給出正確答案，由于大部分人會關懷更重要的東西，比方會議內(nèi)容，提問問題，乃至是怎么找個舒適的位子也比擴音器的多少更讓人關懷。

圖1

回到咱們網(wǎng)站碰到的問題，某個項意圖設計師關懷的頁面并非悉數(shù)，而僅僅幾個與之頁面有關的頁面和部分重要的方針頁面。因而咱們能夠去除相關性不大的頁面，只保存關懷頁面，然后縮短用戶途徑，大大提高核算功率。

別的，咱們把索引的思維引入剖析進程中，把網(wǎng)頁的URL按照必定規(guī)則（例如正則表達式）替換成簡略字符，把相關性不大的頁面核算替換為同一個字符（例如“0”），把一些過渡性的頁面替換成某個字符（例如”p”），如此以來，每個用戶的拜訪途徑就能夠表示為一個字符串，例如”a,c,0,0,0,a,p,p,c,0,c,d,0,0,0”。也有的用戶的拜訪途徑全為相關性不大的頁面，此時，途徑為0,0,0,0,0,0,0,0,0,0,0,0,0,0”，這表示用戶并未拜訪到方針頁面，假如不需求核算用戶比例或用戶分類，那么這樣的記錄咱們能夠刪除去。

假如需求保存其他的用戶信息，例如cookieid，登錄名，拜訪時刻等信息，這個字符串會愈加雜亂些。假如咱們研究意圖比較簡略，還能夠進一步處理，假如不需求對步長信息進行剖析，咱們能夠去掉相鄰重復的一些數(shù)據(jù)，把上式簡化為” a,c,0,a,p,c,0,c,t,0”。

這個進程請參看圖2中的①和②，由此咱們能夠得到多個用戶的途徑的字符串方法的文件。

圖2

得到這個聚集式用戶途徑文件后，咱們就能夠?qū)�這個字符串文件進行剖析了。例如，咱們需求核算a頁面后有多少個c頁面，需求能疏忽中心的翻頁頁面（p頁面）。在上例中的這個用戶的字符串中，便是1個用戶，2次c頁面。假如在拜訪了其他頁面之后再拜訪c頁面的行為也可核算入內(nèi)的話，那便是1個用戶，3次c頁面。

接下來便是剖析的樣本量問題。一般剖析進程中會考究“多而全”，但數(shù)據(jù)量大到必定級別，剖析1/10乃至1/100人群與剖析全樣本所得到的成果相差無幾，花費許多資源去提升一點精確度是一件很因小失大的工作。因而能夠酌情剖析小樣本量，節(jié)省剖析成本。

由于方針頁面業(yè)務的獨特性，每次需求剖析的方法也很個性化。途徑查詢器能夠靈敏應對各種查詢。例如，咱們需求核算a后面有t的人次，a后面緊跟著c的人次，行為契合某種形式的用戶數(shù)有多少等等。需求核算的形式在剖析算法裝備文件（圖2中的③）中進行裝備，查詢器會核算并導出最終成果。

別的，查詢器還支撐分類信息查詢，根據(jù)用戶途徑文件的裝備信息，對每種分類的人群分別查詢，或許導出契合某種形式的人群Cookieid，用戶名等，與其他數(shù)據(jù)存儲媒介聯(lián)接，取得這部分人群的其他信息，然后進行歸納剖析。

這種方法長處在于比較靈敏，假如網(wǎng)站的URL規(guī)則比較標準，在裝備進程中能夠多選用正則表達式，然后能夠發(fā)現(xiàn)更多有趣的現(xiàn)象。