為前端，和業務上下游交流數據的時候，經常會出現頁面 PV、UV、點擊率、轉化率等中英混雜不知所云的名詞。特別是在存量競爭的當下，數據更是頻頻出現在高層的目標和規劃中。

那么，當我們，一個前端同學，談起數據時，我們在談些什么呢？

追本溯源

我們先拋開 spm 這些埋點名詞，從一個行外人的角度來審視用戶的交互過程。

?為什么要看數據

讓我們先從一個頁面開始。

前端永遠是從一個頁面開始。

這個頁面可能是一個內容流如各大內容平臺的首頁，可能是一個詳情頁，可能是一個會場頁（如果你更容易理解的話）：

看起來有點花哨？沒關系，我們來抽象一下。這，就是我們的頁面：

當然，我們的頁面自然也不是孤立的。它與其它千千萬萬個頁面一起，互相聯系，構成了吞噬你我業余時光的時間黑洞：

作為頁面的開發者，最基本的，我們要做好頁面的渲染、功能的交互、跳轉的響應。

然后，就可以了，嗎？

如果作為一個獨立的博客網站，往互聯網里一丟，圈地自萌就好了。

用戶來了，玩了，爽了，走了，不帶走一片云彩。

但是作為一個商業公司，我們開發的頁面需要產生價值。

玩爽了是要給錢的。

怎么給呢？

淘寶，本身就是一個賣貨的場，從一個商品引流到另一個商品，從一個類目關聯到更多類目，從衛生紙一路買到電視機。

我們希望用戶在我們的業務里花更多時間，看更多東西，下更多訂單。

這個時候，我們的頁面更像是一個觀光車：從火車站招攬游客上車，拉他們去看彩色兵馬俑：

為了從商家拿到更多的回扣，出租車司機會主動去人流量大的場所拉客，旅行社會在簽約前給到足夠多的情緒價值，導游會不遺余力地把游客往玉石店里拉。

這個幾乎出于本能的循環有足夠強的自驅力，它能一直運行到市場監督管理局或央視的介入。

這個循環本身不需要數據。

數據的引入是為了優化這個循環。

?看什么數據

為什么要優化這個循環？

因為我們希望有更多的人進來，更少的人流失，更多的人到達目的地，買票參觀，這樣我們才能從景區手里拿到更多的回扣、返點。

用戶交互也一樣。

我們希望有更多的人來看我們的頁面，更多的比例引導到商品域，更多的人下單，從而收取更多的傭金。

為了追求這個目標，我們需要知道：

• 有多少人來了這個頁面
• 都是從哪里來的
• 在這個頁面里干了什么，去了哪里
• 最終有多少人去了我們的目標頁
• 有多少人通過我們的引導頁最終完成了購買

知道了這些，我們就能做有針對性的調整：

• 來頁面的流量很少，我們可以在對應流量域增加推廣
• 用戶在我頁面里停的時間很短，我要加些勁爆內容勾住他
• 用戶去目標頁面的人很少，也許是按鈕不夠醒目，我做大一點
• 哪個渠道過來的流量成交很多，我們可以擴大那個渠道的投放量

作為電商頻道，交易的絕對值是我們的終極目標。

這就是為什么，我們大多數業務都在致力于提升頁面的流量、用戶停留、轉化率。

而哪怕是一些與交易可能沒有直接關系的，比如螞蟻森林，只要能夠增加用戶的回訪和停留，我們也總有辦法從中獲取權益。

做出我們自己的數據產品

看到這里，你也許會詫異，原來我們的數據目標這么簡單而明確，為什么集團那么多花里胡哨的東西，看都看不懂！

剛好，我也是這么想的。不如我們另起爐灶！

先來明確一下我們的任務：

• 有多少人來了這個頁面 -> 頁面流量
• 都是從哪里來的 -> 頁面來源
• 在這個頁面里干了什么，去了哪里 -> 用戶交互、頁面去向
• 最終有多少人去了我們的目標頁 -> 頁面來源
• 有多少人通過我們的引導頁最終完成了購買 -> 頁面來源關聯成交數據

明確下來，只有三個內容：

1. 頁面跳轉路徑（從哪里來，到哪里去）
2. 頁面流量（有多少人訪問頁面）
3. 用戶交互（用戶在頁面里都干了什么）

So easy!

?如何感知頁面間的跳轉行為

整套數據產品里，最核心的就是，如何感知頁面的跳轉行為。知道這個，我們才有可能將成交和引導頁關聯起來，進而通過引導頁的優化來促進成交。

假設我們有這么個場景：用戶在瀏覽時，看到一條廣告，被引流到首頁，最終在商詳頁完成下單：

要感知頁面之間的行為，首先要認識頁面，給每個頁面獨一無二的標識。

• Web鏈接參數

先來快速科普一下。對于瀏覽器來說，頁面就是一條鏈接。www.taobao.com就是淘寶的頁面。（APP 里略有差異，不遵循 web 的網頁協議，但是原理是差不多的，也是一長串亂糟糟的字母。）

一條網頁鏈接通常長這樣，詳細可以看這里：

重點關注 Parameters 這部分，它的結構是用 & 符號分隔的鍵/值對列表：

這個叫參數，有了它我們就能在一條資源鏈接上實現更多玩法。

比如，通過拼接商品 id 的參數，就能實現不同商品的瀏覽：

https://item.taobao.com/item.html?id=1111111111111 和

https://item.taobao.com/item.html?id=22222222222 就是兩個不同商品的詳情頁。

那怎么知道一個頁面是從哪個頁面過來的呢？我們就可以通過約定一個 from 參數來傳遞：

www.item.taobao.com?id=1111111111&from=首頁

這就表示用戶從首頁過來，訪問了商品 1111111111。

我們的頁面只要從鏈接上讀到 from=xxx 參數，就代表用戶是從那個源頭過來的。

?具體實現思路

另一個關于網頁的小知識點是：鏈接后的參數可以隨意加，參數有沒有用取決于頁面有沒有使用到。

比如在 www.item.taobao.com 后加 id 參數有用，但是在 www.taobao.com 后加 id 參數就不起作用，因為首頁不消費 id 參數。

我們需要頁面去消費 from 參數。

因此，基于上述約定，我們還需要在頁面代碼側做具體的實現：

1. 流量上報：在頁面流量日志上報自身參數，以統計頁面流量信息
2. 來源上報：在頁面流量日志上報來源參數，統計頁面來源信息
3. 來源傳遞：當前頁向下一個頁面跳轉時，把自身的標識攜帶到頁面鏈接里
4. 下一個頁面做上報：下一個頁面需要識別來源參數，并做流量及來源上報

這樣，我們就能夠統計出如下信息：

1. 三個頁面各自的流量數據
2. 頁面 2 的流量中，有多少來自頁面 1，有多少去了頁面 3
3. 頁面 3 的流量中，有多少來自頁面 2

恭喜你，已經成功做出了丐版的 spm 和上報 SDK。

接下來就是數據任務了，將所有頁面繁雜的流量和來源日志處理成符合我們需要的數據結構。

最后，當我們給出一個頁面標識，就能查出這個頁面的流量、來源、去向。

但是我不會寫 sql……新和聯勝的計劃只能中道崩殂了。

重新認識一下集團的數據方案

?spm（埋點約定）

現在我們可以重新認識一下 spm了。

spm（Super Position Model，超級位置模型）是阿里埋點體系的重要規范，它的作用就是為每一個頁面添加了一個獨立的標識。阿里的spm位置編碼由A.B.C.D四段構成, 各分段分別代表 A:站點/業務, B:頁面, C:頁面區塊, D:區塊內點。

假設我們現在做羽毛球行業的業務，該業務下有許多頁面：

那么我們就能夠輕松確定各個頁面的 SPM 分別是 羽毛球行業.營銷頁、羽毛球行業.商詳、羽毛球行業.店鋪。

那么問題來了，既然 B 位代表了頁面，為什么我們還需要 A 位呢？

我個人的理解，引入 A 位的好處是 B 位的定義可以更加語義化且業務無關，也可以通過 A 位對業務下的多個頁面做統計分析。當然后者對業務同學可能更重要些。但作為前端同學，還是比較關心前者，畢竟命名真的是太難了。

既然 spmA.spmB 已經可以確定一個頁面的標識，后面兩位是什么作用呢？

讓我們稍微細化一下場景。

假如我們營銷頁現在有兩個活動，秒殺活動和場景購都導流到同一個商詳頁：

看起來沒有什么問題。

讓我們把視角放到商詳頁。你會發現它只能感知用戶是從營銷頁過來，而不知道具體哪個活動導流過來的。相應的，秒殺業務的同學也無法感知模塊的引導效率。

spmC 位和 spmD 位就是為了解決頁面精準定位的需要。

當用戶點擊了秒殺模塊的商品 2 時，商詳頁感知到的來源就是 羽毛球行業.營銷頁.秒殺.商品2，既有來源頁，又有來源頁的具體點擊位置。如果統計頁面維度的引導效率，可以只消費 spmA.spmB。如果有更細粒度的分析需求，也有相應的數據做支持。

• spm如何傳遞

spm 參數同樣是通過 url 參數傳遞的。如果大家留意一下正在看的這篇文章的鏈接，可能會發現這么個 spm 參數：

前兩位分別代表了 ata 業務和 2xxxxxx0 頁面。

spmC 和 spmD 位是 0.0，這是因為 ata 不關心模塊級的引導，給的默認值。

細心的同學可能注意到在 spmD 位之后還有一串亂七八糟的字符， SPM 官方解釋是這樣的：

看不懂吧。這描述確實太技術了，我來翻譯一下：

不關你事！莫挨勞資！

?上報工具

通過 SPM 規范，我們能夠定位到一個頁面中的任意位置。

不過就像前面說的，約定 just 約定，在沒有實現之前就只是概念而已。

前面提到，這套體系要運轉起來，需要所有頁面都統一動作：保證自己有一個 spm id，且在渲染時消費外部帶過來的 spm，跳轉時拼接自身的 spm。

從原理上分析，這就是個橫向項目，需要自上而下的推廣。

阿里集團側給出的方案是一套上報工具 SDK。頁面內集成這套腳本之后，它會做兩件事：頁面曝光上報、跳轉鏈接劫持等。

一個頁面有兩個 spm 相關的參數：

1. 鏈接上的 spm：標識來源頁的 spm_id
2. 頁面自身的 spm_id：當前頁面標識

頁面加載后，SDK 會做頁面曝光上報，攜帶自身 spm 和來源 spm。

對跳轉鏈接的攔截是通過對 a 標簽的點擊事件攔截實現的。它會自動往其 href 屬性上拼接頁面的 spmA.spmB，如果 a 標簽被包裹在區塊或點擊熱區內，還會進一步攜帶上 spmC.spmD，以標識該跳轉的點擊來源。

前端同學請注意

從 SDK 的實現原理不難發現，如果跳轉不是通過 a 標簽完成的，那這個劫持就失效了。進而，二跳頁就會失去當前頁面的來源信息。

因為 a 標簽的樣式問題和默認行為問題，以及點擊行為通常存在跳轉前的邏輯處理等，前端同學更傾向使用 js 方式跳轉頁面，這時就需要特別關注下，有沒有做好 spm 信息的手動拼接。

• 這套方案有缺點嗎？

因為 spm 參數是依賴網頁鏈接的，在這條鏈路下面沒有任何問題。

但是當某個頁面被分享出去時，分享鏈接里攜帶了 頁面1 的 spm。所有從該分享鏈接進入的流量，SDK 也會認為它是來自頁面 1 的，進而出現頁面 1 引導到頁面 2 的流量比頁面 1 本身的流量大的多的情況。

比如你把當前頁面鏈接分享出去：

別人通過你的鏈接訪問，由于 spm 的傳遞特性，SDK 仍會認為用戶是從首頁過來的，進而計入首頁的引導轉化。

• 來源頁的來源頁

在具體實踐中，除了統計頁面的來源頁面，還會統計頁面來源頁面的來源頁面：

還拿這個例子，頁面 3 不但知道用戶是從頁面 2 過來的，還知道用戶在此之前訪問了頁面 1。

是怎么做到的呢？

答案就是 Referer 請求頭：Referer 請求頭包含了當前請求頁面的來源頁面的地址，即表示當前頁面是通過此來源頁面里的鏈接進入的。

別忘了，我們的 spm 數據就藏在 url 上。

能拿到上一個頁面的 url，自然就能夠從當前頁面感知到上上一個頁面。

（對于一些拿不到 referer 請求頭的場景「比如小程序」，業務實現上會往 url 上加 preSpm 參數，實現對來源頁來源的感知）。

那么，你可能又要問了，為什么不統計來源頁面的來源頁面的來源頁面，乃至于無限套娃呢？

我個人理解，這一方面是技術問題，另一方面也是成本和需求的平衡：

成本上，我們是否需要記錄這么長的用戶路徑。因為考慮到存取的需求，路徑必然是可枚舉的。

技術上，有一個奧卡姆剃刀原理：如無必要，勿增實體。意思是不做無謂的復雜度升級。僅僅是往 url 上拼接 spm 參數，就已經需要集全集團之力，反復宣導，尚且常有漏報錯報。如果要再增加 preSpm，乃至 prePreSpm，系統的穩健性乃至數據結果的可信度必然要打折扣。

?用戶交互行為

除了關注頁面流量和跳轉情況，我們還是希望感知到用戶在當前頁面里做了什么。感知的其中一個目的，就是為了改善頁面的跳轉率。

當用戶進入頁面，到執行跳轉前，通常有一些必須的行為。我們就可以通過考察用戶在每個步驟中的行為情況，最終提高進入跳轉的用戶量：

頁面 pv 和黃金令箭埋點通常被認為是兩種東西。但從前端角度來看，它們都只是一個發向日志服務器的 http 請求。只不過在后續的數據任務處理中會有差別。（當然，在端側，為了統計頁面的停留時長，頁面 pv 的發送時機也會有些變化，不過這些也不需要前端開發者去感知。）

現在我們可以梳理一下 SDK 在用戶訪問頁面的過程中都做了什么事：

?引導成交（數據任務）

借助 SPM 體系和 SDK 方案，我們現在有了用戶的訪問路徑。我們的最終目標是知道每個頁面究竟創造了多少下單。

用戶瀏覽產生頁面交互數據，用戶下單產生訂單數據。我們需要把用戶的瀏覽行為和下單結果關聯起來。

這更多是一個數據任務。

在計算引導成交時，會涉及到兩個概念：

1. 引導

在目標頁的來源頁和來源頁的來源頁里找到了當前頁的 spm，就認為是當前頁的引導數據。

根據路徑不同：

• 從當前頁直接到目標頁，叫做直接引導。
• 從當前頁，通過中間頁到達目標頁，叫做非直接引導。（前面記錄的來源頁的來源頁，就在這里派上了用場）
• 直接引導和非直接引導加在一起，叫做全引導。

根據目標頁類型的不同

• 引導到商品詳情頁，叫做引導寶貝。
• 引導到店鋪相關頁，叫做引導進店。
• 商品詳情頁也是店鋪的相關頁，因此引導進店包含了引導寶貝。

其指標關系如下：

從上圖我們可以直觀地發現：全引導進店的口徑是最大的，直接引導寶貝的口徑是最小的。

2. 成交

成交的口徑就比較簡單了。用戶對該商品有購買記錄，就認為用戶這天有成交。

3. 引導成交

引導成交的紙面意義是：用戶通過我們的頁面被引導到目標頁，并在目標頁完成了下單。我們才將這個用戶及其成交情況計作當前頁的成果。

但是從上面提到的統計口徑來看，成交和引導其實是兩個相對獨立的事件。

• 當天有成交就視為用戶成交
• 當天有引導就視為用戶引導。
• 既有成交又有引導就視為用戶引導成交

根據引導類型的不同，又能夠進一步拆分為直接引導寶貝成交，直接引導店鋪成交……相應的，也有同樣的數據關系：

看數

集團除了提供一套上報 SDK，還建設了一個看數平臺，將上述提及的所有數據需求匯總在平臺上。

我們所有需要的東西就是一個頁面 spm，在平臺上檢索：

然后你就會得到想要的一切。

頁面流量

頁面引導轉化

頁面來源去向

區塊分析（包含區塊曝光和引導成交）

黃金令箭

FBI 報表

當然，也可以從數據底表里寫 sql ，借助 FBI 平臺構建可視化效果更好的報表。

結語

盡管數據之路并非總是一帆風順，諸如數據準確性、技術實現挑戰等問題依舊存在，但正因如此，不斷探索與優化數據應用的方法顯得尤為重要。作為前端開發者，掌握這些知識與技能，意味著能在激烈的市場競爭中，為產品與團隊帶來更堅實的數據支撐，推動業務持續增長。

總之，當前端談數據時，我們實際上在談論如何更好地理解用戶、優化體驗、驅動決策與創造價值。在這個數據驅動的時代，每一位前端同學都是數據海洋中的領航員，用代碼編織數據的網，捕捉商業成功的浪花。

作者:子蟲

來源-微信公眾號:大淘寶技術

出處:https://mp.weixin.qq.com/s/fN0XiCvcLqAEXcHwxo1D0w