彈跳追蹤會讓你的點擊繞經追蹤者自家網域，藉此植入第一方識別碼，完全繞過封鎖第三方 Cookie 的防護機制。
主流瀏覽器正逐步淘汰第三方 Cookie，許多隱私建議仍把這件事當成跨站追蹤終結的訊號。事實並非如此。彈跳追蹤（bounce tracking）——又稱重新導向追蹤——打從一開始就不依賴第三方 Cookie。它會讓你的點擊先經過追蹤者自己擁有的網域，短短一瞬間就足以讓該網域讀寫自己的第一方儲存空間，接著才把你送往原本要去的地方。整個過程中沒有設下任何第三方 Cookie，所以封鎖第三方 Cookie 對它完全無效。
重點整理
- 彈跳追蹤會在點擊前往目的地之前，悄悄把它重新導向到追蹤者自己的網域，讓追蹤者短暫變成第一方，得以利用自己的儲存空間植入或讀取識別碼。
- 連結裝飾（link decoration）讓識別碼跟著這一跳一起走：點擊 ID 或類似參數會被附加到網址上，讓追蹤者即使沒有 Cookie，也能把這次造訪拼接回某個使用者檔案。
- 它在設計上就能繞過第三方 Cookie 封鎖——彈跳期間，識別碼存放在追蹤者自家網域的第一方儲存空間裡，而這正是第三方限制規則管不到的類別。
- 瀏覽器對付它的方式是從結構面下手，而不只是封鎖 Cookie：Chrome 的 Privacy Sandbox 提供 Bounce Tracking Mitigations（彈跳追蹤緩解措施），會清除那些只曾以彈跳中介身分出現過的網域的狀態；Safari 的 Intelligent Tracking Prevention（智慧型追蹤防護，ITP）從一開始的設計，鎖定的就正是這一整類重新導向濫用手法。
- 它自成一個獨立的追蹤家族，有別於瀏覽器指紋辨識（無狀態的裝置訊號）、基於快取的超級 Cookie（藏在 HTTP 快取裡的狀態），以及指紋衍生式持久 ID——下方會逐一比較彼此的差異。
彈跳追蹤到底是什麼
想像一個普通的連結：你點下去，瀏覽器就直接前往目的地。彈跳追蹤則插入了一個看不見的額外停靠站。連結並不是直接指向目的地——而是先指向追蹤者的網域，該網域再立刻發出自己的重新導向把你送往下一站。這段繞路可以有幾種形式：
- 伺服端重新導向：追蹤者的伺服器回傳一個指向真正目的地的 HTTP 30x 回應。
- 用戶端重新導向：頁面先短暫載入在追蹤者的網域上，接著由 JavaScript（或 meta-refresh）在片刻後把你送往下一站。
不論是哪一種，在那短短一瞬間，你的瀏覽器其實真的就位於追蹤者的網域上——不是嵌在 iframe 裡，也不是載入第三方指令碼，而是貨真價實地導航到了那裡。這個差異正是整件事的關鍵：只要你人在追蹤者自己的網域上，它所儲存的任何東西，從瀏覽器的角度看都是第一方儲存空間，就跟你自己在網址列輸入那個網域造訪一樣。
連結裝飾：識別碼如何撐過這一跳
光靠重新導向並不能識別你——追蹤者還需要知道是哪一次點擊剛好落到了它的網域上，尤其是第一次見到你的時候（那時它還沒儲存任何東西）。這正是**連結裝飾（link decoration）**派上用場的地方：把識別碼直接以查詢參數的形式附加到網址上，例如在一個原本平凡無奇的連結後面加上 ?click_id=a1b2c3d4。
這種模式在聯盟行銷與廣告歸因中隨處可見：一組「點擊 ID」需要從廣告曝光一路撐到購買頁面，有時還得穿越好幾個中介網域。彈跳追蹤借用了完全相同的機制，只是用途不同：裝飾過的網址讓追蹤者的網域能直接從這次導航本身讀出識別碼，把它寫進該網域自己的第一方儲存空間，再把你交接出去。下一次你再彈跳經過同一個追蹤者時，它就讀回自己儲存的資料，把兩次造訪重新連結起來——整個過程完全不需要跟目的地網站交換任何 Cookie。
為什麼這能繞過第三方 Cookie 封鎖
第三方 Cookie 限制的運作方式，是在你身處別人網頁上時，拒絕讓網址列以外的網域設定或讀取 Cookie——典型案例就是嵌在出版商網頁裡的廣告指令碼，試圖為自己的網域設定 Cookie。彈跳追蹤從來不會把瀏覽器置於這種情境。彈跳期間，追蹤者的網域短暫地就是你網址列上的那個網域。它在那裡設定的儲存資料，不折不扣就是第一方儲存空間，而任何第三方 Cookie 規則，本來就從未打算限制一個網域在你真正導航到它時，如何處理自己的第一方儲存空間。
這也是為什麼解方不能只是「把 Cookie 封鎖範圍再擴大一點」——整套機制本來就繞開了 Cookie 封鎖賴以建立的第三方／第一方界線。要擋下它，就必須辨識出一種模式：某個網域永遠只以短暫彈跳的姿態出現，從來不是你真正停留的目的地。
瀏覽器對彈跳追蹤的防禦
由於彈跳追蹤利用的是導航本身，而不是某個特定的儲存 API，防禦手段必須長期觀察瀏覽行為，而不是單純封鎖某一次呼叫。
Chrome 的 Privacy Sandbox Bounce Tracking Mitigations（彈跳追蹤緩解措施）的做法，是追蹤使用者曾被重新導向經過、卻從未與之互動或停留太久的網域，再定期清除該網域的儲存空間與 Cookie。一個永遠只是短暫中介、從不是目的地的網域，會被區別對待，跟你真正造訪的網站不同——這正是區分彈跳追蹤中介與你刻意導航前往的一般網站的關鍵模式。
Safari 的 Intelligent Tracking Prevention（智慧型追蹤防護，ITP）採取了相關但更早的做法。正如 WebKit 自己在 Intelligent Tracking Prevention 2.0 這篇文章所描述的，ITP 從一開始的設計目標，就是要推斷跨站導航式追蹤，而不只是嵌入式的第三方請求——這正是彈跳追蹤所仰賴的重新導向加裝飾模式，ITP 透過對具有類似追蹤行為的網域分類並限制其儲存空間來因應，而不只是過濾第三方 Cookie 標頭。
Firefox 的 Enhanced Tracking Protection（強化追蹤保護）則透過自家的追蹤分類清單與儲存空間分割，追求相同的目標：無論互動是透過嵌入還是重新導向發生，都限制被歸類為追蹤者的網域能持續保存哪些內容。
這些做法的開發者，沒有一個把它們描述成已經完成、一勞永逸的解方——參見 MDN 對第三方 Cookie 的概覽，了解底層隱私模型如何隨著瀏覽器一個接一個補上漏洞而持續演進。與其說彈跳追蹤緩解措施是已經解決的問題，不如說它是一場針對移動目標、持續進行中的主動防禦。
彈跳追蹤與其他追蹤家族有何不同
BrowserInsight 涵蓋了好幾種截然不同的跨工作階段追蹤機制，值得先弄清楚你眼前看到的究竟是哪一種：
| 機制 | 持續存在的是什麼 | 狀態存放在哪裡 |
|---|---|---|
| 彈跳／重新導向追蹤 | 裝飾在網址上的識別碼 | 彈跳網域自己的第一方儲存空間 |
| 瀏覽器指紋辨識 | 完全沒有任何東西被儲存 | 每次造訪都根據裝置／算繪訊號重新運算 |
| 持久訪客 ID | 一個指紋衍生出的數值 | 從穩定的硬體／瀏覽器訊號重新運算，或在多個儲存空間之間復生 |
| 基於快取的超級 Cookie | 藏在快取回應中的識別碼 | 瀏覽器的 HTTP 快取 |
指紋辨識與指紋衍生式持久 ID，完全不需要任何儲存或導航手法——同一組 Canvas 雜湊值或 WebGL 算繪器字串每次都會出現，純粹是因為它是即時從你的裝置讀取出來的，這正是為什麼清除資料、開啟隱私模式或使用 VPN 都碰不到它。彈跳追蹤則是完全相反類型的技術：它整個核心都是儲存與導航機制，利用的是第一方／第三方的界線，而不是裝置特徵。網站也可能透過另一套獨立的儲存配額手法，判定你當下正處於隱私視窗——參見網站如何偵測無痕與隱私瀏覽模式，那是另一套不相關的機制。搞清楚某個追蹤說法屬於哪個家族很重要，因為能擋下其中一種的防禦手段（封鎖第三方 Cookie、隨機化指紋）通常對其他家族完全無效。
看看你自己的瀏覽器暴露了什麼
彈跳追蹤在網址列上是看不見的——重新導向鏈發生得太快，根本來不及注意，而它所仰賴的大部分機制，也不是單次頁面載入就能直接檢查出來的。你可以檢查的，是網站可能拿來與它搭配使用的更廣泛訊號面：BrowserInsight 的指紋檢測會顯示你的瀏覽器目前暴露出的儲存空間、Canvas 及其他用戶端訊號，整個過程完全在用戶端執行，不會傳送到任何地方進行分析。
常見問題
封鎖第三方 Cookie 能阻止彈跳追蹤嗎？
不能。彈跳追蹤的運作方式，是讓追蹤者的網域在重新導向期間短暫變成第一方，所以打從一開始就不會觸發第三方 Cookie 規則。要擋下它，瀏覽器必須辨識重新導向這個模式本身，而這正是 Chrome 的 Bounce Tracking Mitigations 與 Safari 的 ITP 這類緩解措施所設計要做到的事。
彈跳追蹤跟聯盟連結或短網址一樣嗎？
兩者的機制有重疊之處——都用到重新導向，通常也都有裝飾過的網址——但意圖不同。短網址或明確揭露的聯盟重新導向，存在的目的就是把你導向某處，重新導向本身是使用者看得見的重點。彈跳追蹤則是刻意運用完全相同的技術模式，專門在使用者根本沒注意到發生過的重新導向期間，植入一個第一方識別碼。
清除 Cookie 能阻止彈跳追蹤嗎？
只有部分效果，而且只撐到下一次彈跳為止。清除 Cookie 會抹掉追蹤者網域當下已經儲存的東西，但下次你點擊經過同一個網域的裝飾連結時，它大可在彈跳期間直接寫入一組全新的識別碼。真正針對這個模式的緩解措施，做法是辨識並定期清除那些只曾以彈跳中介身分出現的網域——而不是仰賴你自己動手清除資料。
彈跳追蹤到了 2026 年還有效嗎？
它的有效性正在縮小，但還沒有消失。瀏覽器層級的緩解措施，越來越能偵測並清除那些表現得像純粹彈跳中介的網域的儲存空間，但這些防禦在不同瀏覽器與設定之間的推行進度仍不平均，而底層的重新導向加裝飾機制也並未消失——這是一場正在進行中的軍備競賽，形式上跟無痕偵測的貓捉老鼠模式頗為類似。
總結
彈跳追蹤提醒我們：第三方 Cookie 的終結，並不等於跨站追蹤的終結——它終結的只是其中一種機制。透過在重新導向期間讓追蹤者的網域短暫變成第一方，再靠連結裝飾把識別碼一併帶走，它繞開了第三方 Cookie 封鎖原本要強制執行的那條界線。瀏覽器的應對方式，是改為觀察導航模式而不只是過濾 Cookie 標頭，但就跟本站介紹的每一項技術一樣，誠實的結論是：沒有任何單一解方——不論是清除 Cookie、封鎖第三方儲存空間，還是任何一項瀏覽器緩解措施——能一次補上所有的漏洞。
推薦閱讀：
