一個網站在背景發出的第三方請求，中位數是桌機版 83 個，這是 HTTP Archive《Web Almanac》整理全網數據後給出的答案，而且這還只是全網所有網站的中位數；流量前 1,000 大的網站，這個數字直接衝到 129 個。
多數人討論「該不該裝追蹤碼」時，通常是拿著單一平台在問：要不要裝 GA4、要不要裝 Meta Pixel、要不要裝某個平台給的一小段程式碼。但真正決定網站快不快、資料準不準、同意機制顧不顧得到的，從來不是「裝了幾種平台」，而是瀏覽器裡同時在跑的第三方程式碼加起來有幾支。每多一支，都在跟頁面的主執行緒、跟資料的可信度、跟同意管理的維護量搶資源。
這篇要拆的問題不是「追蹤碼該不該裝」（它幾乎一定要裝），而是「裝到第幾支之後，成本已經蓋過拿到的資料價值」。
多數網站的瀏覽器早已同時載入多支第三方程式
多支第三方程式同時掛在同一個網站上，不是流量大站才有的現象，而是全網的常態。HTTP Archive《Web Almanac》2025 年版的〈Third Parties〉章節整理了全網頁面的第三方請求數，結果是九成以上的網頁至少載入一個第三方資源；就算把全網所有網站一起算，第三方請求數的中位數也達到桌機版 83 個、行動版 79 個。流量前 1,000 大的網站更重，中位數直接衝到桌機版 129 個、行動版 106 個。而且這個數字還在逐年往上疊，跟 2024 年版相比，前 1,000 大網站的第三方請求數，2025 年桌機與行動版各再增加 15 個。
「不重複網域數」跟「請求數」是兩件事。即使不重複的第三方網域數量在下降，請求數還是在漲，代表個別廠商在同一頁面發出的請求變多了。對照 2024 年版數據，那一年前 1,000 大網站的第三方數量中位數是 66，前一百萬名網站的中位數是 27，92% 的頁面至少有一個第三方；廣告、分析與同意管理這三類，合計就占了全網第三方將近三分之一。
更容易被忽略的一點是串連。一支第三方程式，往往會自己再拉進另一支。Web Almanac 量出的第三方引入鏈中位深度是 3 層，意思是多數第三方會再帶入至少一個其他第三方，最深的一條引入鏈紀錄達到 2,285 層。這代表網站經營者自己數的「裝了幾支追蹤碼」，跟瀏覽器實際載入的支數，常常對不上。前十大第三方網域幾乎被 Google 系服務包辦，包括 fonts.googleapis.com、googletagmanager.com、google-analytics.com、accounts.google.com、adservice.google.com；Meta 的 facebook.com 是前十名裡唯一非 Google 的網域，出現在 21% 的頁面上，排名第 7。裝一支標籤管理容器，底下可能已經串出好幾支使用者從沒意識到的程式。
追蹤碼的取捨標準是資料有沒有人真的在用
前面這串數字容易讓人得出一個簡單的結論：追蹤碼越少越好。但這篇要談的立場更精確一點，追蹤碼該不該裝，判準從來不是「這個平台有沒有出追蹤碼」，也不是「裝了會不會比較保險」，而是這筆資料裝起來之後，真的有人會定期打開、拿去做決策嗎。
這個判準乍聽理所當然，實務上卻常常被反過來用。不少網站的追蹤碼清單，是好幾年累積下來的結果，這個平台流行的時候裝一支，那個代理商建議的時候再裝一支，卻很少有人回頭盤點這些資料現在還有沒有被打開。幾種常見情境都屬於這一類：GA4 裡建了好幾條轉換路徑報表，卻從沒被拿來檢討過廣告預算該往哪個渠道挪；Meta Pixel 裝在網站上好幾個月，這段期間卻從沒在 Meta 廣告後台投過任何一檔廣告；Hotjar 或類似工具的錄影功能開著，滾動熱點圖也累積了一整季，卻沒有人真的坐下來回放過一支影片。這些追蹤碼技術上都在正常運作、忠實蒐集資料，唯一的問題是沒有人在用它產出的東西。
跟「這個月還在拿來調整出價、還在拿來檢討轉換路徑」的追蹤碼相比，這些裝了但沒人用的追蹤碼，價值完全不是同一個等級，卻常常被用同一套「多裝一支比較安全」的心態一起留著。而它們留在網站上不是沒有代價的，這代價分成三塊：拖慢頁面反應的效能成本、讓資料兜不攏的治理成本，以及讓同意管理多一層負擔的維運成本。
多支追蹤碼一起跑，主執行緒忙不過來
多支追蹤碼一起跑，最先被犧牲的往往是效能。追蹤碼多半是透過瀏覽器的 JavaScript 引擎執行的，而瀏覽器處理使用者互動的地方，按一下按鈕、點一個連結、切換一個分頁，是同一條主執行緒（main thread）。如果這條主執行緒正忙著跑追蹤碼的程式碼，使用者的點擊就得排隊等，這段等待的時間，正好就是 Google 衡量網頁反應快不快的指標 INP（Interaction to Next Paint，互動至下一次繪製時間）所要量測的東西。
INP 量測的是使用者互動（點擊、輕觸、按鍵）到畫面下一次視覺更新之間的間隔，2024 年 3 月 12 日起正式取代 FID（First Input Delay），成為 Core Web Vitals 三項核心指標之一。這個替換不只是名稱換了。FID 只看第一次互動反應快不快，一個網站可能第一下點擊很快、後面每一下都卡，卻仍然拿到不錯的 FID 分數；INP 把整個瀏覽過程裡的每一次互動都納入計算，卡頓藏不住。在瀏覽器主執行緒上執行的程式碼，不分自家程式或第三方程式，都可能延遲這個反應，差別只在於第三方程式的延遲會疊加。一支追蹤碼佔用主執行緒幾毫秒或許感覺不出來，好幾支同時跑，時間會一路累加成使用者真的感覺得到的卡頓。
INP 不是唯一被拖累的指標。國際網頁效能監測平台 DebugBear 在分析第三方程式碼影響時指出，第三方會拖累全部三項 Core Web Vitals：LCP（最大內容繪製）常見的情境是第三方請求跟首屏內容搶頻寬，或首屏內容本身就是由第三方程式插入、載入慢了整個頁面的視覺完成時間也跟著晚；CLS（累積版面配置偏移）最常見的情境是廣告版位這類第三方內容延遲插入，把下方已經渲染好的內容硬生生往下推，造成使用者正要點擊時版面跳動。Lighthouse（PageSpeed Insights 背後的引擎）內建專門的稽核項目，會直接回報第三方程式碼佔用主執行緒多少毫秒，效能成本因此不是抽象的說法，而是打開任何一次 PageSpeed 檢測就能看到的具體數字。
追蹤碼一多，付出這些代價的不是網站經營者自己，是每一個正在瀏覽網頁的使用者，而 Google 又剛好把這種體驗量化進了搜尋相關的訊號裡。
重複安裝追蹤碼造成的數字落差
追蹤碼裝得零散、沒有人定期盤點，代價不只出在效能，也會出在資料治理面。最常見的後果不是完全沒資料，而是資料兜不攏，甚至互相打架。
最典型的兩種情況，第一種是重複安裝：同一種追蹤碼被不同人在不同時間點各裝了一份，可能是原本的人裝了一次、後來接手的人不知道已經裝過又裝一次，也可能是舊版網站遷移時新舊程式碼一起保留下來，結果是同一個轉換事件被觸發兩次、三次，轉換數字看起來比實際發生的還多，等於被自己的重複標籤灌水。第二種是殭屍標籤：舊代理商或舊工具留下的追蹤碼，專案結束了、合作關係也結束了，程式碼卻還留在網站上，繼續悄悄把使用者資料送出去，沒有人記得它的存在，也沒有人知道該不該關掉它。
這兩種情況的共通點，是資料失真會朝兩個相反的方向發生：漏掉的方向，該觸發的轉換事件沒觸發，會讓某個渠道的成效被低估；灌水的方向，同一事件被重複觸發，會讓成效看起來比實際更好。兩個方向都會誤導媒體採購與預算分配的判斷，而且誤導的方式不一樣，漏掉會讓一個明明有效的渠道被錯誤砍預算，灌水則會讓一個效果普通的渠道拿到不該有的預算。標籤治理稽核商 ObservePoint 的共同創辦人 Robert Seolas 曾提到，他們在 2012 年協助的 250 個網站，一開始平均有超過 20% 的頁面缺少追蹤碼，經過幾輪稽核與修正後，資料遺失才降到幾乎為 0%。
追蹤碼一多，最傷的地方就在這裡，出錯的不是有沒有資料，是資料可不可信，而後者對要拿數據做預算決策的人衝擊更大，因為壞掉的資料看起來跟正常的資料一模一樣，不會自己舉手說自己壞了。這也是為什麼標籤治理已經被視為跟隱私合規相關的營運流程之一，而不只是工程師手上一件排錯的雜事。
每多裝一支追蹤碼，同意管理就多一層維運負擔
效能與資料治理之外，還有一塊常被忽略的成本，是隱私與同意機制的維運。追蹤碼不是裝上去就結束，每一支會讀寫 cookie 或蒐集使用者行為的第三方，理論上都要接進網站的同意管理流程，也就是使用者在同意橫幅上按下同意或拒絕之後，這支追蹤碼該不該繼續執行、該不該把資料送出去。這件事不會因為裝了追蹤碼就自動具備，得另外串接。
追蹤碼的種類越雜、來源越多，要盤點這支屬不屬於需要同意才能執行的清單就越長，漏掉的機率也越高。以 Google 自己的產品線為例，Google 提供 Consent Mode（同意模式）這套機制，讓網站把同意橫幅蒐集到的使用者同意選擇，回報給 Google 旗下的分析與廣告產品，動態調整這些標籤讀寫 cookie 的行為；Google 的測量產品也會讓訪客的同意狀態在瀏覽不同頁面時被保留下來。連 Google 自己的產品線都要求接上同意訊號，這反映出裝了追蹤碼跟處理好它的同意狀態，是兩件分開、但都要做的事。
而且這個負擔並不是平均分攤在所有種類的追蹤碼上，是集中在特定兩類。Web Almanac 2025 年版在分析全網的同意訊號時發現，TCF（IAB 透明度與同意框架）是全網最主要的同意標準，在排名較後的一般網站上採用率達 36%（全網平均 18%）；USP（對應 CCPA 的同意框架）次之，各排名層級採用率約 9% 到 17%。接收最多同意訊號的第三方網域，以廣告科技類（廣告交易平台、需求方平台、廣告伺服器）為主，分析類第三方則多半採用另一套 GPP 框架。換句話說，追蹤碼一多，同意管理的維護量也跟著多，而且多出來的這部分，集中在廣告與分析這兩類最常見的追蹤碼類型上，剛好也是網站最容易一裝再裝、卻最少回頭盤點的那兩類。
同時投放多個廣告平台通常省不了各自像素
前面三個理由都成立，不代表追蹤碼越少越好是一句無條件對的話。最常見、也最站得住腳的例外，是一個網站同時在多個廣告平台上投放付費廣告，例如同時在 Google 與 Meta 上都有預算，或再加上其他社群、內容平台。
各家廣告平台的出價演算法與受眾模型，都是靠自己平台蒐集到的轉換資料在訓練、優化，這件事平台之間不會互通。Google 的出價模型看不到 Meta Pixel 蒐集到的轉換資料，反過來也一樣。這代表只留一支追蹤碼、其他平台的像素乾脆不裝，不是把成本降下來，而是讓其他平台的廣告直接失去優化依據，出價演算法等於在盲飛，投的預算反而更容易浪費在不精準的受眾上。
這種情況跟前面講的裝了但沒人用的追蹤碼，是完全不同性質的問題。判準仍然是同一個，資料有沒有被用在決策，只是這裡的決策是廣告出價優化，不是報表檢討。只要這個平台的廣告確實還在投放，這支追蹤碼就在持續被使用，追蹤碼數量跟著正在使用的廣告通路數增加，是合理的必要成本；等哪一天某個平台的廣告預算收掉了，對應的追蹤碼才該跟著一起下架，而不是預先假設越少越好就先關掉還在用的那一支。
網站改版前的短期質化研究算是合理例外
第二個成立的反方情境，是為了一次明確目的、短期安裝的質化分析工具，最常見的是螢幕錄影與熱點圖類型的工具，例如網站改版前想知道使用者在舊版介面卡在哪一步、或是 A/B 測試期間想看使用者實際怎麼操作兩個版本。
這類工具即使會增加當下的追蹤碼數量與效能負擔，只要符合三個條件就符合前面資料有沒有人真的在用這個判準：有明確的起訖時間、真的有人會定期回放這些錄影或熱點圖去做分析、專案結束後會把它移除。跟前面談的殭屍標籤最大的差別，正好就在這三個條件：殭屍標籤是裝了忘記拆，沒有終點、也沒有人在看；短期質化分析工具是用完就會拆，有明確的起點與終點，而且過程中真的被拿來做決策依據。
這一節跟前面追蹤碼的取捨標準是資料有沒有人真的在用那節，本質上是同一個判準給出的兩種答案。多數裝了沒人用的追蹤碼，判準給出的答案是不該裝；同時投放多個廣告平台的像素，以及短期質化分析工具，判準給出的答案剛好是該裝。反方成立的兩種情境，走的仍然是同一套邏輯，不是另立一套標準。
平台一多，瀏覽器端的程式不必跟著等比增加
即使前面兩節的反方情境都成立，確實需要同時對接多個廣告與分析平台，要接的平台數跟瀏覽器裡要跑的程式數，其實是兩件可以拆開處理的事，不是綁死在一起、非等比增加不可。
做法是把個別廠商各自的追蹤碼，統一收進單一的標籤管理容器，例如 Google Tag Manager，不用每接一個新平台，就在網站原始碼裡再手動貼一段程式碼；更進一步的做法，是把標籤執行搬到網站自己控制的伺服器端，也就是伺服器端代管（server-side tagging）。這套做法把測量標籤從瀏覽器移到伺服器端處理。由網站自己控制的伺服器統一接收事件，再轉發給該送的各個平台，取代由瀏覽器直接對每個廠商各自發送請求的傳統做法。因為執行標籤的工作移到了伺服器上，客戶端（也就是使用者的瀏覽器）需要執行的程式碼因此變少，同時訪客資料在由網站自己管理的伺服器端環境中被收集與分配，也比放在瀏覽器端更有掌控與保護。
這樣一來，網站仍然可以把同一筆事件資料轉發給 GA4、Google Ads、Meta 等多個目的地，對接的平台數不用少一個，但使用者瀏覽器裡實際要下載、解析、執行的程式碼量卻能跟著減少。這篇要收回來的立場很簡單，追蹤碼裝幾支才夠，答案不是一個固定數字，而是先把兩個問題分開問：要接哪些平台，跟瀏覽器要多跑幾支程式。這兩件事多數時候不必然要畫等號。前者的答案，看的是有多少筆資料真的被用在決策上；後者的答案，靠標籤管理與架構上的收斂，就能跟前者脫鉤。
回到最開頭的問題，網站該裝幾支追蹤碼，答案不會是某個固定數字，也不會是「越少越好」這種口號。真正該做的動作，是把手上現有的追蹤碼清單攤開來，一支一支問這筆資料上一次被打開、被拿去做決策，是什麼時候。答得出來、而且答案是上個月的，留著；答不出來、或答案是不記得了的，那就是該關掉的那一支。追蹤碼的多寡從來不是重點，有沒有人在看它產出的東西才是。