GTM 承擔的責任：追蹤碼的部署

GTM 是一個在頁面上執行的追蹤碼載入器，分析資料由它載入的各家代碼收集：網站放一段容器片段（container snippet），頁面載入時從 googletagmanager.com 下載這個容器目前發布的設定，再依設定決定在什麼時機載入哪些追蹤碼。設定由三種元件組成：

• 代碼（tag）：要執行的追蹤碼，例如 GA4 的設定、Meta Pixel、一段自訂的 JavaScript。
• 觸發條件（trigger）：代碼在什麼時候執行，例如每一頁載入時、某個按鈕被點擊時、資料層 出現某個事件時。
• 變數（variable）：代碼執行時要讀的值，例如目前頁面的網址、資料層 裡的訂單金額。

GTM 存在的理由是部署權的轉移。沒有 GTM 時，行銷要加一個廣告平台的像素，得請前端改程式、走一次發版；有了 GTM，行銷在後台加代碼、按發布，網站程式不用動。這個轉移同時是 GTM 所有成本的來源：GTM 容器裡的代碼從此也在網站上執行，而它們不經過工程團隊的程式碼審查與版本控制。

資料層：頁面與容器之間的事件約定

GTM 讀取網站狀態有兩種方式：從頁面的 DOM 抓（某個 CSS class 的按鈕被點擊、某個元素的文字），或讀網站主動推進來的資料。網站主動推送資料的載體是資料層（資料層）——頁面上的一個全域陣列 window.dataLayer，網站在事件發生時往裡面推一個物件：

1// 訂單建立成功之後由前端程式推入；event 是 GTM 觸發條件比對的事件名稱
2window.dataLayer = window.dataLayer || [];
3window.dataLayer.push({
4  event: 'purchase',
5  order_id: 'order-20261022-0042',  // 送往各家時當去重 ID 用
6  value: 1280,
7  currency: 'TWD'
8});

event 這個鍵的值會被 GTM 的自訂事件觸發條件（Custom Event trigger）比對，名稱對上的代碼就執行，沒有任何觸發條件對上的事件只留在陣列裡、不產生請求（擷取紀錄見 用 Playwright 擷取追蹤碼請求 的 GTM 那一則）；其餘的鍵可以在 GTM 裡建成 資料層 變數，讓代碼讀取。purchase、order_id 這些名稱由網站自己決定，GTM 不規定，所以它們要被當成一份 schema 管理：誰新增了哪個事件、欄位的型別與意義、改名時哪些代碼會受影響。事件命名規範 與 Schema 版本演進策略 的做法同樣適用在這份約定上。

兩種讀法的差別在前端改版的時候浮現。靠 DOM 抓的觸發條件綁在 CSS selector 上，前端重構把按鈕的 class 改名，觸發條件就不再命中，GTM 不報錯、事件安靜地消失，通常要等行銷發現報表的數字掉下來才會有人查。資料層 的推送寫在前端程式裡，改版時跟著程式碼一起被審查，所以分工會落成：前端工程負責在對的時機推對的事件，行銷負責把事件接到哪幾家代碼。

order_id 在這裡同時服務 Meta Pixel 與 Conversions API 的去重：GTM 裡的 Meta Pixel 代碼把它填進 eventID，伺服器端用同一個值送 Conversions API。

預覽模式與版本發布的驗證

GTM 的變更要先驗證再發布，驗證工具是預覽模式（Preview，在 Tag Assistant 裡開啟）。開啟後，這個瀏覽器載入網站時會用工作區裡還沒發布的設定，並在旁邊列出這次瀏覽依序發生的 資料層 事件；點選任一個事件，可以看到那個時間點哪些代碼執行了、哪些沒執行，以及每個變數當時的值。預覽模式靠 cookie 運作，只影響開啟它的那個瀏覽器，其他讀者看到的仍是已發布的版本。

驗證一個購買事件時，操作一次測試購買，在預覽模式裡確認 purchase 事件出現、該執行的代碼都在「已觸發」那一欄、資料層 變數讀到的金額與訂單相符。代碼送出的內容再到各家自己的驗證工具確認（GA4 的 DebugView、Meta 的 Test Events），因為預覽模式只看得到代碼有沒有執行，看不到對方的後台有沒有收到。

GTM 有自己的版本紀錄：每次發布產生一個版本，可以比對兩個版本的差異、退回前一版。這份紀錄在 GTM 的後台裡，不在網站的 git 裡，所以網站程式的變更與追蹤設定的變更分住兩處。出事時要對時間軸的人得兩邊都查：某天轉換數掉了，可能是前端那天發版改了 資料層，也可能是有人那天在 GTM 發布了一個新版本。

自訂 HTML 代碼的安全與效能成本

GTM 的代碼類型裡有一種自訂 HTML（Custom HTML），內容是任意的 HTML 與 JavaScript，發布後會在每一個符合觸發條件的頁面上執行。這代表 GTM 容器的發布權限等同於在網站上執行任意程式碼的權限：一個帳號被盜、或一段從廣告商複製來的程式碼帶有錯誤或惡意行為，影響的是所有讀者，而這段程式碼從來沒有進過程式碼審查。治理上要控制的因此是權限：誰能發布（GTM 把編輯與發布分成不同的權限等級）、發布前誰審過、自訂 HTML 的內容有沒有人讀過。

網站有設內容安全政策（Content Security Policy，CSP）時，GTM 要求的放行範圍也是這個成本的一部分：容器本身要放行 googletagmanager.com，自訂 HTML 注入的 inline script 要靠 nonce 或放寬 script-src 才能執行，每多接一家代碼還要再放行那一家的網域。放寬 CSP 讓 GTM 正常運作，同時也放寬了它原本要擋的那一類注入。

效能面的成本來自每一個代碼都是一段第三方 script。GTM 讓加代碼變得很便宜，所以容器裡的代碼數量只增不減，停用的廣告活動留下的像素很少有人回頭刪。定期盤點的做法是在預覽模式裡走一次主要頁面，列出實際執行的代碼與它們載入的網域，對照目前還在使用的服務。

伺服器端代碼管理改變的資料路徑

網頁容器的每個代碼都從讀者的瀏覽器直接送資料給各家 vendor。伺服器端代碼管理在中間多放一個伺服器容器（server container），通常架在網站自己的子網域上：瀏覽器只把事件送到這個子網域一次，伺服器容器再轉送給 GA4、Meta Conversions API 等目的地。

這條路徑帶來三個變化。事件送往網站自己的網域，避開以已知追蹤網域為對象的攔截清單；資料送出去之前會先經過自己控制的伺服器，可以在那裡拿掉不該送給第三方的欄位（作法同 SDK redaction helper 在 SDK 送出前做的遮蔽）；cookie 由自己的伺服器以 HTTP header 寫入，比 JavaScript 寫入的 cookie 受瀏覽器追蹤防護的限制少；這一項有前提：伺服器所在的子網域，它的 CNAME 或 IP 位址與網站主站不同、而指向第三方時（例如子網域以 CNAME 指到雲端服務的網域，而主站不在那裡），Safari 會把它寫的 cookie 期限壓到 7 天；與主站解析到同一個 CNAME 或 IP 範圍時不受這條限制（規則見 First-party Cookie（第一方 cookie））。代價是那台伺服器要自己跑：GTM 的伺服器容器部署在 Cloud Run 或自己的主機上，流量、費用與可用性都回到自架 collector 要面對的那些事，見 Ingestion Scaling。

伺服器容器的預覽模式驗證的是另一段：它列出伺服器收到的請求、解析出的事件資料，以及轉送給各家的請求。網頁容器的預覽模式確認瀏覽器有送，伺服器容器的預覽模式確認轉送的內容對，兩段要分別驗。

容器載入、資料層事件與代碼送出的請求，可以在 Google Tag Manager 實測頁 填入測試容器的 ID 實際觸發一次。容器屬於哪一個帳戶、帳戶與容器的權限分級，以及把容器移到另一個帳戶時要匯出匯入、網站上的容器 ID 跟著換的處理，見 追蹤資產的歸屬。

這一頁載入什麼、什麼時候載入

頁面打開時不載入 GTM。按下「載入 GTM 容器」之後，面板才先往 window.dataLayer 推一筆 gtm.js 事件，再從 googletagmanager.com 注入填在欄位裡的那個容器；在那之前這一頁沒有任何送往 Google 的請求。注入的容器在重新整理或離開這一頁時消失，容器裡的代碼寫下的 cookie 會留在這個網域上，直到按「清除這一頁的追蹤 cookie」。

容器 ID 欄位填的是 GTM 後台裡某個容器的 ID（GTM- 開頭）；欄位預設空白，填自己的測試容器 ID。容器裡有哪些代碼、它們在什麼觸發條件下執行，由那個容器目前發布的版本決定，所以同一個按鈕在不同容器上會送出完全不同的請求。用自己的測試容器實測時，在 GTM 後台開啟預覽模式再回到這一頁，就能在 Tag Assistant 裡看到每一筆資料層事件觸發了哪些代碼。

（尚未建立）

對照面板讀出容器的行為

面板分成四塊：「操作紀錄」列出按鈕實際執行的 dataLayer.push()；「這一頁送出的跨網域請求」列出這一頁向其他網域發出的每一個請求；「追蹤 cookie」列出 _ga、_gcl 等前綴開頭的第一方 cookie；「window.dataLayer 目前的內容」是資料層這個陣列的完整內容。

• 載入容器之後：資料層除了按鈕推的 gtm.js，還會多出容器自己推入的事件（頁面的 DOM 就緒、視窗載入完成這類），它們是 GTM 內建觸發條件比對的對象。請求清單先出現 gtm.js，再出現容器裡各個代碼載入的 script 與送出的請求——容器設了 GA4 就會看到送往 Google Analytics 的請求，設了 Meta Pixel 就會看到 fbevents.js。
• 往資料層推 purchase 事件：資料層多一筆帶 order_id、value、currency 的物件。容器裡有以 purchase 為名的自訂事件觸發條件時，以它為觸發條件的代碼會在這時執行並送出請求；沒有的話這一筆只會留在陣列裡，請求清單不會變。資料層是約定、容器決定要不要讀它，從這裡可以直接看到兩者的分工。
• 推了事件而容器沒有對應觸發條件時網路請求的實際樣子，擷取紀錄見 用 Playwright 擷取追蹤碼請求 的 GTM 那一則。
• 沒有載入容器就推事件：先按「往資料層推 purchase 事件」再載入容器，容器載入後會從陣列開頭依序處理已經在裡面的事件，所以先推的那一筆仍然觸發得到代碼。網站在容器載入完成之前就推事件，靠的是這個行為。
• 載入失敗：狀態列顯示「載入失敗」時，代表 gtm.js 的請求被擋下（廣告攔截器、瀏覽器追蹤防護或網路政策），容器裡的每一個代碼都不會執行。

請求清單在頁面打開時就可能已經有幾筆紀錄，那些是本站每一頁都會載入的第三方資源（例如從 cdn.jsdelivr.net 載入的 Mermaid）與本站的流量 beacon（送往 script.google.com），與 GTM 無關。Resource Timing 只記錄網址、看不到 POST 請求的 body，要看完整內容改用瀏覽器開發者工具的 Network 面板。

擷取方式：讓瀏覽器自動化操作實測頁

擷取腳本不直接把服務商的 script 載入一個空白頁，而是開啟實測頁、照讀者的操作順序按按鈕。這樣擷取到的是和讀者在實測頁上觸發的同一組 JavaScript 呼叫：同樣的 fbq() 呼叫、同樣的資料層（dataLayer，頁面上供 GTM 讀取事件的全域陣列 window.dataLayer，定義見 Google Tag Manager 的資料層一節）內容，結果可以拿來對照實測頁的面板（實測頁上列出操作紀錄、跨網域請求與追蹤 cookie 的區塊）。

擷取腳本在 Meta Pixel 實測頁上依序做的動作是：載入 Pixel 並送 PageView、送 ViewContent、送帶 eventID 的 Purchase，再把 fbclid 參數加進網址重新開啟頁面並再載入一次 Pixel，觀察 _fbc cookie 的產生。在 GTM 實測頁上是載入容器、按實測頁的「往資料層推 purchase 事件」按鈕。每個動作之後等三秒，讓 script 送完請求、寫完 cookie。

實測頁的面板用瀏覽器的 Resource Timing 列出跨網域請求，Playwright 則直接監看瀏覽器送出的每一個請求，所以擷取結果多了面板拿不到的資訊：POST 請求的 body、回應的狀態碼與標頭、帶 HttpOnly 旗標而 document.cookie 讀不到的 cookie，以及面板根本列不出來的請求。Meta Pixel 的事件請求就是最後一種：fbevents.js 以隱藏的表單把事件提交到一個 iframe，這類提交不進父頁面的 Resource Timing，所以實測頁面板上只看得到 fbevents.js 與它的設定檔，看不到任何一筆事件；在 Playwright 的紀錄與瀏覽器開發者工具的 Network 面板裡看得到。

擷取腳本預設以無頭模式（headless）啟動 Chromium，這時瀏覽器的 User-Agent 帶 HeadlessChrome 字樣。實測時 Meta Pixel 在無頭模式下照樣載入、照樣寫 cookie，事件請求卻一筆都不送出，原因在 Pixel 的設定檔（signals/config/<Pixel ID>）載入的 botblocking 模組（plugin，fbevents.js 依 Pixel 設定檔載入的程式片段）：依擷取當時那一版設定檔的原始碼，這個模組拿 navigator.userAgent 比對一份機器人規則清單，清單裡有 HeadlessChrome/，比對成功時由這個模組在事件送出之前把它攔下（模組程式碼裡對應的訊息字串是 [Meta pixel] Bot traffic detected and blocked）。fbevents.js 本體也偵測 HeadlessChrome，但只把結果寫進事件請求的 o 參數。

兩組對照支持這個歸因，都沒有存成結果檔。作者在 Playwright 的瀏覽器設定裡只把 User-Agent 換成一般 Chrome 的字串、其餘照舊以無頭模式執行，事件就送出了，這證明結果取決於 User-Agent，但 fbevents.js 本體同樣讀 User-Agent，單靠這一組分不出攔截的是模組還是本體。另一組來自一次填錯 Pixel ID 的擷取：同樣是無頭模式，不存在的 ID 拿到的設定檔裡沒有 botblocking（只有幾個不分 ID 的通用模組，該 ID 專屬的那一段是空的），向 www.facebook.com/tr/ 的事件請求卻照樣送出（那次是 GET，o 參數含 IS_HEADLESS），所以本體偵測到無頭模式之後並沒有攔截，攔截來自設定檔載入的模組。那份結果檔因為 ID 填錯而刪除了。GTM 容器裡的 GA4 代碼在無頭模式下照常送出事件請求。依 User-Agent 辨識自動化流量是通用的做法，本站自己的流量統計怎麼分辨機器流量見 辨識自動化流量。

所以擷取 Meta Pixel 要加 --headed，讓 Playwright 開一個有視窗的瀏覽器操作實測頁。擷取腳本不改寫 User-Agent，有視窗的瀏覽器仍然是自動化控制的瀏覽器，Meta 之後若加入其他偵測條件，同一個指令的結果可能改變，這也是每份結果要記下擷取模式的理由。

擷取結果檔（JSON）的欄位

擷取腳本每次執行寫出一份 JSON，檔名是服務商名稱加上 UTC 擷取時間（例如 meta-pixel-20261022T1726Z.json），放在 scripts/vendor-capture/results/。欄位分成三組：

• 重現條件：capturedAt（UTC）與 capturedAtTaipei、browser（Chromium 版本）、userAgent、headless（這次是否以無頭模式執行）、labUrl、使用的 Pixel 或容器 ID。headless 欄位從 2026-10-23 01:26 那一次擷取起才有，01:23 與 00:45 兩份結果沒有這個欄位，看 userAgent 有沒有 HeadlessChrome。結果和這些條件綁在一起才有意義，換一個瀏覽器版本或服務商改版之後，同一個動作可能送出不同的參數。
• script 的版本線索：requests 裡 fbevents.js、gtm.js 那幾筆的 body 欄位（script 本體的位元組數與 SHA-256）與回應標頭，以及 vendorRuntime.fbqVersion（頁面上 fbq.version 的值）。實測兩家的回應都不帶 last-modified 與 etag，所以讀結果的人判斷 script 有沒有改版，以本體雜湊為主。fbq.version 在網站安裝的 Pixel 基本碼（base code）裡先被設成 2.0，fbevents.js 載入後覆寫成實際版本。gtm.js 的內容由容器設定與 Google 提供的 GTM 執行時程式碼（runtime）一起產生，雜湊變了之後要再到 GTM 後台的版本紀錄查容器那段期間有沒有發布，才分得出是哪一邊改的。
• 觀察對象：steps（每個動作之後實測頁狀態訊息列的文字）、requests（每一筆跨網域請求的方法、網址、查詢參數、POST body、狀態碼）、cookies（追蹤 cookie 的名稱、值、網域、到期時間與旗標）、vendorRuntime.dataLayer（GTM 實測時資料層的完整內容）。

判讀 requests 時，status 是主要訊號。瀏覽器收到回應之後才被中止的請求，Playwright 會觸發失敗事件，擷取腳本在失敗事件裡也讀取已收到的回應，所以結果檔同時記下 status 與 failure，這時以 status 為準：請求送達了。本篇的擷取裡只有 GA4 的 g/collect 出現這個組合，00:45 那一則記錄了它與作者用 Chrome DevTools Protocol 做的對照。status 為 null 而帶 failure 的，是沒有收到回應的請求。

擷取用的測試帳號

擷取用的 Pixel 與 GTM 容器都是測試專用的資產，各自放在只放實測資產的擁有者底下：Meta 另開一個商家資產管理組合，GTM 與 GA4 各另開一個帳戶。這樣安排的理由見 追蹤資產的歸屬。建立時三家的檢查與預設值會影響擷取結果，記在這裡：

• Meta 對組合名稱有檢查：vendor-lab-test 與 Tarragon 兩個名稱都被退回，錯誤訊息是組合名稱必須如實反映商家，Tarragon Tech Notes 通過。Meta 的說明頁只寫組合名稱要和商家對外使用的名稱一致、不能有特殊字元，沒有列出退件的判斷條件；錯誤訊息附的連結是粉絲專頁的命名守則，其中一條是名稱不能只由一個統稱用詞組成（守則舉的例子是「披薩」），Tarragon 是香草的英文名稱，與這一條相符。GTM 與 GA4 這次以 vendor-lab-test 當帳戶名稱，都直接建立成功。
• Meta 的建立流程詢問要不要把既有的粉絲專頁加入新組合，預設不勾選。Meta 資料集不需要粉絲專頁，這次略過。
• Meta 資料集的建立表單有一個預設勾選的選項，表單上的說明是勾選之後，組合裡現有與日後新建的每一個資料集都會連結到 Meta 的 Conversions API（轉換 API），搭配 Pixel 把網站事件也送到 Meta 的伺服器端。這個選項由 Meta 那一端代為處理伺服器端的傳送，與 Meta Pixel 與 Conversions API 描述的、由網站自己的伺服器呼叫 Conversions API 是不同的設置方式。擷取要觀察的是瀏覽器端送出的內容，這次取消勾選，所以測試 Pixel 沒有伺服器端的事件來源。
• GA4 建立帳戶時，四個資料共用選項有三個預設勾選（「根據輸入內容和業務洞察資料建立模型」「技術支援」「依據您業務性質提供的建議」），這次全部取消；GTM 帳戶的匿名資料共用選項預設不勾選。

Pixel ID 在事件管理工具（Events Manager）的資料集頁面讀，商家設定頁網址裡的 selected_asset_id 是設定頁內部的資產編號，與 Pixel ID 不同；GTM 容器 ID（GTM- 開頭）顯示在 GTM 後台工作區頁面的上方。

執行擷取的指令

指令都在 repo 的根目錄執行。第一次執行前，先裝好 Node.js，安裝 repo 的相依套件（@playwright/test 與 http-server）與 Playwright 用的 Chromium：

1# 取得擷取腳本與實測頁的原始碼
2git clone https://github.com/tarrragon/blog.git && cd blog
3
4# 安裝相依套件與 Playwright 的 Chromium；沒有裝 Chromium 時，第一次執行會出現 Executable doesn't exist
5npm ci
6npx playwright install chromium

擷取指令本身：

 1# 擷取 Meta Pixel：--id 填測試用 Pixel 的 ID，--headed 讓事件請求送得出去
 2node scripts/vendor-capture/capture.mjs --vendor meta-pixel --id <Pixel ID> --headed
 3
 4# 擷取 GTM：--id 填測試用容器的 ID（GTM- 開頭）
 5node scripts/vendor-capture/capture.mjs --vendor gtm --id <GTM-容器ID>
 6
 7# 改測本機建置的網站：先建置網站並啟動靜態伺服器，再把 --url 指到本機的實測頁
 8make site
 9mkdir -p .test-www && ln -sfn ../public .test-www/blog
10npx http-server .test-www -p 4173 -s &
11node scripts/vendor-capture/capture.mjs --vendor meta-pixel --id <Pixel ID> --headed \
12  --url http://localhost:4173/blog/devops/monitoring/vendors/meta-pixel-lab/
13node scripts/vendor-capture/capture.mjs --vendor gtm --id <GTM-容器ID> \
14  --url http://localhost:4173/blog/devops/monitoring/vendors/google-tag-manager-lab/

擷取腳本依 --vendor（meta-pixel 或 gtm）決定開哪一個實測頁、照哪一組動作操作。--id 是要填進實測頁欄位的 ID，用測試專用的 Pixel 與容器，擷取送出的事件才不會混進正式的廣告報表；兩個 ID 去哪裡讀，見〈擷取用的測試帳號〉一節的最後一段。省略 --url 時，擷取腳本開正式站的實測頁；加 --out <目錄> 時，擷取腳本把結果檔寫到那個目錄；--headed 不帶值，加上它就以有視窗的瀏覽器執行，執行期間螢幕上會開一個 Chromium 視窗、跑完自動關閉。本篇的擷取都在有桌面的 macOS 上執行，沒有顯示器的環境（例如沒有桌面的 Linux 伺服器）開不了有視窗的瀏覽器，本篇沒有驗證那種環境的做法。

擷取腳本啟動的 Chromium 由 @playwright/test 的版本決定；沒有跑過 npx playwright install chromium、或 Playwright 升級之後，執行時會出現 Executable doesn't exist at … 這個錯誤。這時重跑安裝指令，或用環境變數 PW_CHROMIUM_PATH 指定本機已有的 Chromium 執行檔，例如 PW_CHROMIUM_PATH=<Chromium 執行檔路徑> node scripts/vendor-capture/capture.mjs …。

改測本機那幾行指令裡，make site 用 Hugo 把網站建置到 public/，接著用 npx pagefind 產生站內搜尋的索引（這一步要連網下載 pagefind）；建置前要先裝好 Hugo，並以 git submodule update --init --recursive 拉下網站的佈景主題。本站的網址前綴是 /blog/，所以把 public/ 以符號連結掛在 .test-www/blog 底下，再用 http-server 從 .test-www 提供檔案，網址才會和正式站的路徑結構一致。4173 是 http-server 監聽的連接埠，與 --url 裡的埠號要一致，換成其他未被占用的埠號時兩處一起改；網站的網址前綴不是 /blog/ 時，.test-www 底下的資料夾名稱與 --url 的路徑一起改。-s 讓 http-server 不輸出每一筆存取紀錄，結尾的 & 讓它在背景執行，擷取完用 kill %1 停掉它。

Pixel ID 填錯時沒有任何錯誤訊息：Meta 的伺服器對不存在的 ID 也回應 signals/config/<ID> 的請求（狀態碼 200），設定檔裡仍有幾個不分 ID 的通用模組，而該 ID 專屬的那一段只有 /* empty plugin */，fbevents.js 照樣送出事件。確認 ID 的方法是看 signals/config 回來的設定檔裡有沒有以這個 ID 開頭的 config.set("<Pixel ID>", …) 設定（存在的 Pixel 有好幾行，不存在的一行都沒有），或直接在事件管理工具的資料集頁面讀 ID。

執行環境（跑擷取腳本的那台機器）要能連到 connect.facebook.net、www.facebook.com、www.googletagmanager.com 與各家 script 用到的網域。連不到的時候擷取腳本照樣跑完並寫出結果檔，steps 會顯示 script 載入失敗，requests 裡向那些網域的請求帶 failure 欄位；這時結果檔反映的是網路環境，不是服務商 script 的行為。

各次擷取的結果

這一節收錄服務商的 script 實際載入、請求有回應的擷取，依時間由新到舊排列，每一則寫明擷取時間、瀏覽器版本、script 的版本線索，以及和實測頁、Meta Pixel 與 Conversions API、Google Tag Manager 兩篇機制文對照之後的觀察。網路被擋下的擷取不收，理由在〈執行擷取的指令〉一節的最後一段。

2026-10-23 01:26（台北）：Meta Pixel，有視窗的瀏覽器

擷取時間是 UTC 2026-10-22 17:26:10，瀏覽器是 Playwright 提供的 Chromium 148.0.7778.96，在 macOS 上以 --headed 執行，User-Agent 不帶 HeadlessChrome；實測頁開在本機建置的網站。Pixel 是〈擷取用的測試帳號〉一節建立的測試 Meta 資料集。結果檔是 scripts/vendor-capture/results/meta-pixel-20261022T1726Z.json。

版本線索：fbevents.js 本體 435,058 位元組，SHA-256 開頭是 6f3aa7a0d8d9；fbq.version 是 2.9.427，signals/config 請求的查詢參數同樣帶 v=2.9.427、r=stable。這個 Pixel 的設定檔裡出現 26 個模組名稱，與本篇觀察相關的是 cookie（寫 _fbp 與 _fbc）、inferredevents（自動事件）與 botblocking（機器人流量）；不存在的 ID 拿到的設定檔裡沒有 botblocking，也沒有任何 config.set("<ID>", …) 設定。

事件請求的形式。 每一筆事件都是向 www.facebook.com/tr/ 送出的 POST，參數放在表單 body 裡，rqm=formPOST。fbevents.js 建立一個隱藏的表單，把它提交到一個 iframe，所以 Playwright 把這些請求記成 document 類型（resourceType），實測頁面板也因此列不出它們。ev 是事件名稱；fbevents.js 把 fbq('track', …) 的第三個引數（事件參數物件）轉成 cd[...] 參數，例如 ViewContent 的 cd[content_name]、Purchase 的 cd[value] 與 cd[currency]，第四個引數帶的 eventID 轉成 eid。網站同時從瀏覽器與伺服器送同一筆事件時，Meta 用 eid 把兩邊去重，機制見 Meta Pixel 與 Conversions API 的去重一節；這次的測試 Pixel 沒有伺服器端的事件來源，eid 只出現在瀏覽器端這一路。

Pixel 自動加送的事件。 Pixel 載入之後，每按一次實測頁的按鈕，fbevents.js 都在實測頁呼叫的事件之外多送一筆 SubscribedButtonClick，依兩筆請求的 ts 參數，相差不到 10 毫秒。這筆事件由 fbevents.js 讀取被點的按鈕之後自動產生，內容是按鈕文字（cd[buttonText] 是「送 ViewContent」）、按鈕的 DOM 特徵（cd[buttonFeatures]）與頁面特徵（cd[pageFeatures]）。網站開發者沒有為按鈕寫任何追蹤程式，按鈕文字就由 fbevents.js 送到了 Meta；盤點一個網站送出哪些資料時，要把 Pixel 自動加送的事件算進去。載入 Pixel 的那一下按鈕沒有對應的 SubscribedButtonClick，那時 fbevents.js 還沒載入。

cookie 與參數的對應。 _fbp 的值是 fb.0. 接毫秒時間戳與一串隨機數，每一筆事件的 fbp 參數都帶著這個值。帶 fbclid 重新開啟頁面之後多了 _fbc，值是 fb.0. 接毫秒時間戳與 fbclid 的原值，那一次的 PageView 同時帶 fbp 與 fbc 兩個參數，另外還有一個 fbcs 參數，原始碼裡它與 fbc 寫在同一組點擊 ID 的處理裡，本篇沒有進一步確認它記錄的內容。兩個 cookie 都由 fbevents.js 以 JavaScript 寫入（httpOnly 為 false）、SameSite=Lax，到期時間是擷取時間起算 90 天。

o 參數。 這一次的每一筆事件都帶 o=4126。fbevents.js 原始碼裡把 o 定義成一組旗標的位元和，4126 拆開是 FIRST_PARTY_COOKIES、AUTO_CONFIG、CONFIG_LOADING、SUPPORTS_DEFINE_PROPERTY 與 SUPPORTS_SEND_BEACON。原始碼裡另有一個 IS_HEADLESS 旗標，在無頭模式下加進 o；01:23 那次無頭擷取沒有送出任何事件，所以沒有 o 值可以對照。另一個參數 coo 在原始碼裡記錄的是免程式碼事件設定（codeless）是否被關閉，不是 cookie 的設定。

2026-10-23 01:23（台北）：Meta Pixel，無頭模式

擷取時間是 UTC 2026-10-22 17:23:23，瀏覽器是 Chromium 148.0.7778.96 的無頭模式；Pixel、實測頁與操作順序與 01:26 那次以 --headed 執行的擷取相同，差別只在沒有加 --headed。結果檔是 scripts/vendor-capture/results/meta-pixel-20261022T1723Z.json。

版本線索：fbevents.js 本體的位元組數與 SHA-256、fbq.version 都與 01:26 那一次相同，兩次擷取用的是同一版 script，差別只來自擷取模式。

fbevents.js 與 signals/config 都載入成功，_fbp 與 _fbc 照樣寫入，向 www.facebook.com/tr/ 的事件請求一筆都沒有：PageView、ViewContent、Purchase 都沒有送出。差別來自無頭模式的 User-Agent 帶 HeadlessChrome，攔下事件的是 Pixel 設定檔載入的 botblocking 模組，機制見〈擷取方式〉一節。實測頁狀態訊息列顯示「fbevents.js 已載入」，從頁面上看不出事件沒送。Meta Pixel 與 Conversions API 列的瀏覽器端損失路徑裡，script 被廣告攔截器擋下時網站還有機會察覺載入失敗；這一次是 script 載入成功、cookie 也寫了，事件在送出之前被設定檔載入的模組攔下。

2026-10-23 00:45（台北）：GTM 容器只帶一個 GA4 代碼

擷取時間是 UTC 2026-10-22 16:45:30，瀏覽器是 Playwright 提供的 Chromium 148.0.7778.96 的無頭模式（collect 請求的 uaa=arm、uab=64 顯示是 macOS arm64），實測頁開在本機建置的網站（http://localhost:4173/blog/monitoring/vendors/google-tag-manager-lab/）。GTM 容器是〈擷取用的測試帳號〉一節建立的測試容器，發布的版本裡只有一個 Google Analytics 代碼（tag），觸發條件（trigger）是 Initialization - All Pages，沒有任何以 purchase 為名的自訂事件觸發條件。代碼與觸發條件的定義見 Google Tag Manager 講 GTM 責任的那一節。結果檔是 scripts/vendor-capture/results/gtm-20261022T1645Z.json。

版本線索：gtm.js 的回應本體 546,027 位元組，SHA-256 開頭是 b970456b1ca6；回應標頭只有 content-type、date 與 cache-control: private, max-age=900。

載入容器之後送出的請求。 瀏覽器先向 www.googletagmanager.com 取得 gtm.js?id=<容器 ID>（200），約 0.1 秒後由容器裡的 GA4 代碼向 www.google-analytics.com/g/collect 送出一筆 POST（204）。這一筆 collect 請求的事件資料全部放在網址的查詢參數裡，POST body 是空的：tid 是評估 ID（Measurement ID），en=page_view 是事件名稱，dl 與 dt 是頁面網址與標題。dl 記錄的網址沒有連接埠號，實測頁實際開在 4173 埠，所以在本機用不同埠號測試時，GA4 報表上的頁面網址看不出是哪一個埠號的伺服器送來的。

GA4 代碼寫下的 cookie。 一筆 page_view 之後，實測頁所在的網域（這次是 localhost）多出兩個 cookie。_ga 的值是 GA1.1. 接兩段數字，這兩段數字與 collect 請求的 cid 參數相同，GA4 用它辨識同一個瀏覽器。另一個 cookie 的名稱是 _ga_ 接上評估 ID 去掉 G- 的部分，值記錄這個瀏覽器在這個 GA4 資源（property）下的工作階段，s 之後的時間戳與 collect 請求的 sid 參數相同。兩個 cookie 都由 GA4 代碼以 JavaScript 寫入（httpOnly 為 false）、SameSite=Lax，到期時間是擷取時間起算 400 天（這是 Chrome 對 cookie 到期時間的上限，GA4 代碼自己設的預設是兩年，見 First-party Cookie（第一方 cookie））。

往資料層推 purchase 事件之後。 window.dataLayer 依序是實測頁推的 gtm.js、容器自己推的 gtm.dom 與 gtm.load，以及實測頁的「往資料層推 purchase 事件」按鈕推的 purchase（帶 order_id、value、currency）。推入 purchase 之後沒有新的請求，成因是這個容器裡沒有以名稱為 purchase 的自訂事件觸發條件啟動的 GA4 事件代碼，那一筆只留在陣列裡。Google Tag Manager 的資料層一節描述的分工，在網路請求上就是這個樣子：網站推什麼事件由前端決定，事件是否變成送往某一家的請求由容器的設定決定。

Playwright 對 collect 請求的記錄。 Playwright 把 g/collect 那一筆記成 requestfailed（net::ERR_ABORTED）。作者在這次擷取之後另外用 Chrome DevTools Protocol 的網路事件對照同一個操作，瀏覽器在中止之前已收到 204，事件有送達；那次對照沒有存成結果檔。結果檔因此同時帶 status: 204 與 failure，判讀以 status 為準，見〈擷取結果檔（JSON）的欄位〉。請求清單裡另有一筆 cdn.jsdelivr.net 的 Mermaid script，那是本站每一頁都會載入的資源，與 GTM 無關。

網站程式碼引用的 ID 與它所屬的擁有者

三家的追蹤碼放進網站時，程式碼裡都寫著一個 ID，而這個 ID 指向一個由某一層擁有者持有的資產：

• Meta：網站程式碼裡寫的是 Pixel ID（一串數字）。Pixel 收到的事件在 Meta 那一端整理成一個資料集（dataset），本文稱它為 Meta 資料集，事件管理工具（Events Manager）的資料集頁面顯示的 ID 就是網站要填的 Pixel ID。Meta 資料集的擁有者是商家資產管理組合（business portfolio，舊名 Business Manager，下文簡稱組合）；廣告帳號與粉絲專頁也是組合底下的資產。Facebook 的個人帳號不擁有組合底下的資產，它是組合裡的一位成員，透過組合取得權限。另一條路徑是還沒有建組合、直接在某個人的廣告帳號底下建立 Pixel，這時 Pixel 跟著那個廣告帳號，而那個廣告帳號由建立它的人以自己的 Facebook 帳號管理。
• GTM：網站程式碼裡寫的是 GTM- 開頭的容器 ID。GTM 容器（container）是存放代碼（tag）、觸發條件（trigger）與變數的設定單位，網站上的一段片段載入它；容器屬於一個 GTM 帳戶（account），一個帳戶底下可以有多個容器。Google 的說明寫一家公司通常只需要一個帳戶。
• GA4：直接安裝 GA4 時，網站程式碼裡寫的是 G- 開頭的評估 ID（Measurement ID）。評估 ID 屬於網站資料串流（data stream），資料串流屬於一個 GA4 資源（property，一個網站或 App 的報表與設定單位），資源屬於一個 GA4 帳戶。Google 對帳戶的定義是「一個法律實體擁有其資料的一組資源」。

判斷一個資產的歸屬時要確認兩件事：它屬於哪一層的擁有者，以及它能不能換到另一個擁有者底下。資產換得了擁有者時，網站程式碼不必動；換不了時，要讓新擁有者持有它就只能建一個新資產，網站上的 ID 跟著改，舊資產累積的資料留在原擁有者那裡。三家的資產各屬於哪一種，在〈追蹤資產換擁有者的條件〉一節逐家說明。

Meta 的服務條款規定每個人只建立一個自己的個人帳號，所以「另開一個個人帳號給公司用」這條路在 Meta 不成立。組合是公司資產與員工個人帳號之間的分隔：資產屬於組合，個人帳號只是進出組合的身分。

Meta、GTM 與 GA4 的權限分級

三家都把權限分成兩層：管理擁有者本身（組合或帳戶）的權限，與操作底下個別資產的權限。

Meta 的組合分成完整存取權限（full access，舊名完整控制權）與部分存取權限（partial access）。部分存取權限再分成基本（Basic，舊名員工）與應用程式和整合（Apps and integrations，舊名開發人員）；財務相關的權限是另外加上的附加權限。持有完整存取權限的成員也可以給其他人 3 到 75 天的暫時存取權限，暫時存取只有基本權限、到期自動失效，適合只需要短期協助的外部人員。持有完整存取權限的成員可以新增與移除成員、變更組合的設定，Meta 建議至少兩位成員擁有完整存取權限。成員對個別資產（某個 Meta 資料集、某個廣告帳號）的權限另外指派。

GTM 在帳戶層有管理員（Admin）與使用者（User）兩種角色，在容器層有五級權限：無權限、讀取（Read）、編輯（Edit）、核准（Approve）、發布（Publish）。持有編輯權限的成員可以修改容器裡的代碼、觸發條件與變數，但不能建立版本也不能發布；持有核准權限的成員另外可以建立版本與工作區（workspace，容器尚未發布的草稿），但不能發布。Google Tag Manager 的自訂 HTML 一節說明過發布權限等同於在網站上執行任意程式碼的權限，容器層的分級讓這個權限可以只交給少數人。GTM 沒有「擁有者」這個角色，帳戶只有管理員，後台不允許把所有管理員移除；Google 建議至少有兩位管理員。

GA4 的角色是管理員（Administrator）、編輯者（Editor）、行銷人員（Marketer）、分析師（Analyst）、檢視者（Viewer），可以指派在帳戶層或資源層。分析師在檢視者的權限之上，可以把自己建立的探索分析分享給資源的其他成員；行銷人員在分析師的權限之上，可以建立與編輯目標對象、事件與關鍵事件（key events），並修改歸因模式的設定；資源層的完整設定權由編輯者持有。另外有兩項可以加在角色上的資料限制：不含成本指標（No Cost Metrics）與不含營收指標（No Revenue Metrics），各自讓成員看不到那一類指標，用在外部人員只該看流量與成效、不該看到營收或廣告花費的情況。GA4 的使用者管理說明頁沒有提到權限到期的設定，和 Meta 的暫時存取權限不同：只需要短期看報表的外部人員，要由管理員在期限到時自己移除。

追蹤資產換擁有者的條件：Meta 資料集、GTM 容器與 GA4 資源

Meta 資料集不能轉移，也不能刪除。 Meta 的說明頁在建立資料集的步驟之前寫明這一點，替代做法是把資料集分享給合作夥伴（partner，另一個組合，例如代理商的組合）或加入成員。分享只能由擁有資產的組合發起，取得分享的合作夥伴即使有完整權限，也不能再分享給第三方。同樣固定的還有廣告帳號：在某個組合裡建立的廣告帳號永久屬於那個組合，不能刪除也不能轉出；不屬於任何組合的廣告帳號可以被認領進一個組合，而廣告帳號屬於別人時，要由那個擁有者批准認領的要求。粉絲專頁可以換組合，流程是原擁有者先把它從自己的組合移除，另一個組合再加入它。

所以 Pixel 建在某個組合底下之後，要讓另一方使用它只有兩條路：原組合把 Meta 資料集分享給對方，資料集仍屬於原組合；或對方在自己的組合另建一個資料集、把網站上的 Pixel ID 換掉，代價是原資料集累積的事件資料留在原組合裡。

GTM 容器沒有官方的搬移功能。 Google 的說明頁沒有寫容器能不能從一個帳戶移到另一個帳戶，有文件記載的路徑是把容器匯出成 JSON 檔，再匯入到另一個帳戶的容器裡（匯入時可選擇覆寫或合併）。匯入的目標是另一個容器，它有自己的容器 ID，所以走這條路之後網站上的容器片段要換成新的 ID。不換 ID 的做法是不搬容器、換人移交：在原帳戶加入新擁有者的管理員，再移除原本的管理員。先加後移的順序是因為後台不允許把所有管理員移除，反過來做時移除最後一位會失敗。這是由權限設計推出的做法，前提是整個帳戶裡只有要移交的容器。

GA4 資源可以搬到另一個帳戶。 執行搬移的人要在來源帳戶與目的帳戶都同時有管理員與編輯者兩個角色。Google Marketing Platform 機構（organization）是位在帳戶之上、由公司建立用來集中管理 Google 行銷產品的單位，搬移受它限制：兩個帳戶分屬不同機構時不能搬；只有目的帳戶屬於機構時，由目的帳戶所屬機構的管理員把來源帳戶連結進同一個機構。說明頁沒有列出兩個帳戶都不屬於任何機構時的限制。搬移時報表資料是移過去而不是複製一份，資料串流與它的設定、資源設定、與其他產品的連結都一起移動，所以網站上的評估 ID 不必改；搬移之前的變更記錄留在來源帳戶。連結本身跟著資源移動；被連結的 Google Ads 帳戶與 BigQuery 專案的歸屬，不在本篇範圍。不能搬的情形包括資源連結了 Google Ad Manager、還有未抽樣報表（GA4 360 付費版才有的報表）正在處理、目的帳戶的資源數已達上限（預設 50 個），以及 GA4 360 資源的機構連結還沒有驗證。

三家可以換擁有者的單位不同：Meta 資料集與組合內建立的廣告帳號不能換，GTM 容器只能複製設定、不能保留 ID，GA4 資源能整個搬。三家共通的是最高的那一層（組合、帳戶）可以換人移交：把新擁有者的人加成完整存取權限或管理員，再移除原本的人，底下的資產與 ID 全部不動。換人移交是由三家的權限設計推出的做法，說明頁沒有寫成移交流程。它的前提是那一層裡只放著要移交的資產，而且三件事要先處理：Meta 組合裡由別的組合以合作夥伴身分分享進來的資產，換人之後會連同存取一起交出去；廣告帳號綁的付款方式仍是原擁有者的，換人不會改掉它；GA4 與 GTM 帳戶若連結在原擁有者的 Google Marketing Platform 機構底下，換人不會讓帳戶離開那個機構（機構管理員之後還保有哪些權限，本篇沒有查證）。

追蹤資產的歸屬安排：公司自營與委託代理商

Meta 資料集不能轉、GTM 容器不能保留 ID、GA4 資源跨機構不能搬，這三項限制推出一個安排原則：追蹤資產建在公司自己的組合與帳戶底下，代理商以合作夥伴或成員的身分取得權限。 反過來由代理商在自己的組合或帳戶裡建立 Pixel、容器與資源再給公司用，日常運作沒有差別，差別出現在合作結束的時候：Meta 資料集留在代理商的組合裡，公司要嘛繼續靠代理商分享才看得到，要嘛另建一個並改網站上的 Pixel ID；GTM 容器要匯出匯入並換 ID；GA4 資源要搬到公司的帳戶，而兩邊分屬不同機構時搬不了。GTM 的說明頁直接寫了這個建議：帳戶要由組織內部的人管理，不要交給外部代理商。

各家對應的做法，以及這樣分的理由：

• Meta：公司建立自己的組合，Meta 資料集與廣告帳號建在組合底下，再以合作夥伴的方式分享給代理商的組合。代理商自己的員工由代理商在它的組合裡增減，公司不必追蹤代理商的人事異動；合作結束時，公司撤銷對代理商組合的分享，就一次收回所有代理商員工的存取。
• GTM：帳戶由公司建立，公司的管理員把代理商的人員加成帳戶的使用者，再給容器層的權限。發布權限等同在網站上執行任意程式碼，所以權限給到哪一級取決於公司是否在發布前審查代理商的變更：有人審查時，公司把容器層權限給到核准（Approve）這一級，發布由公司的人做；不審查而把發布權限交給代理商時，代理商發布的自訂 HTML 會直接在每一位讀者的瀏覽器上執行，出事的後果由公司承擔。
• GA4：帳戶與資源由公司建立，公司的管理員把代理商的人員加在資源層，角色依代理商要做的事、給到剛好夠用的那一級（最小權限）：看報表與做分析給分析師角色，需要調整目標對象、關鍵事件與歸因設定給行銷人員角色，需要改資源的其他設定才給編輯者角色；代理商不該看到營收或廣告花費時，再加上對應的資料限制。GA4 的說明頁沒有針對代理商的建議，這一條是由角色設計推出的安排。

擁有最高管理權的成員（Meta 的完整存取權限、GTM 與 GA4 的管理員）至少兩位，而且至少一位是公司裡長期在職的人。 Meta 與 GTM 的說明頁都建議至少兩位，GTM 還禁止移除所有管理員；GA4 的說明頁沒有這項建議，而它的帳戶同樣只能由管理員增減成員。只有一位時的失效不會立刻出現：組合由一個人就建得起來，建立的人自動取得完整存取權限；其他成員各自握有廣告帳號與資料集的權限，已經指派給其他成員的投放與報表權限不需要完整存取權限，所以唯一的管理員離職或帳號遺失之後，日常的投放與看報表照常運作（由權限設計推出），要等到需要加入新代理商或移除離職者的那一天，才發現沒有人做得到。另一種情形來得比較快：那一位的個人檔案被 Meta 限制刊登廣告時，Meta 的說明寫明，只連結他一個人的廣告帳號也可能一起被停用。

唯一的管理員已經不在、才發現沒有人管理得了之後，三家能不能救回各不相同。

Meta 有一條申訴路徑（管理員爭議），說明頁列出的適用情形有：持有完整存取權限的是沒有所有權的前員工或承包商；公司換了擁有者而失去組合的存取權；組合裡沒有任何人持有完整存取權限；持有完整存取權限的人已過世（附死亡證明）；有法院命令證明申請人是組合所屬公司的合法擁有者。申請時要附上申請人的身分證明、證明擁有這家公司的文件與簽名的聲明書，並且要登入與這個組合有關聯的 Facebook 個人檔案，從 Meta 的商家支援中心送出；核准之後申請人取得完整存取權限，原有成員不會被移出組合。前承包商握著組合不交還，是說明頁明列的情形；唯一一位管理員自己的 Facebook 帳號遺失則不在清單裡，而且那時公司手上可能已經沒有任何與組合有關聯的個人檔案可以登入送件，所以要先走 Facebook 個人帳號的復原，帳號找不回來時，這條申訴路徑很可能走不通（依送件條件推出，本站沒有實際送件驗證）。

GA4 的復原方式是在帳戶裡每一個送資料的網站上放一個寫有驗證資訊的 analytics.txt 檔（放在根網域或送資料的子網域，不能上傳檔案時改在頁面加 meta tag），證明網站屬於自己，帳戶連結了 Google Ads 或 AdSense 時也要證明那些帳戶屬於自己，再填 Google 的聯絡表單。

GTM 的情形寫在同一份 GA4 復原說明頁裡：GTM 目前沒有復原途徑，失去所有管理員的 GTM 帳戶救不回來，只能另建容器、換掉網站上的容器 ID。事先多設一位管理員，省下的就是這些申訴與重建。

只有一個人的公司也適用同一個理由：第二位成員承擔的責任是在唯一的帳號遺失時，還有另一個身分能繼續管理，所以第二位不必是員工，可以是合夥人、家人或委託的會計事務所，給他完整存取權限或管理員。這個人同樣有權限移除原本的管理員，所以人選的條件是可以信任，而不只是方便聯絡。Meta 的條款不允許同一個人另開帳號充當第二位。找不到第二位時，風險集中在那唯一一個帳號上。Meta 的說明頁要求從與組合有關聯的個人檔案送出管理員爭議，那個帳號本身遺失時，這條申訴路徑可能走不通（依送件條件推出，本站沒有實際送件驗證），所以能做的是降低那個帳號遺失的機率、並保住它的復原途徑：替自己的 Facebook 與 Google 帳號開啟兩步驟驗證，把帳號綁定的復原電子郵件與手機號碼設成自己長期持有、不隨公司網域或門號變動的那一組。

帳號是被盜而不是遺失時，情形不同：盜用者以那個帳號的完整存取權限持有組合，網站上的 Pixel 仍把訪客的事件送進他控制的資料集，廣告帳號綁定的付款方式也還能被使用。這時有兩件事不必等帳號復原、也不需要那個帳號的權限，可以同時做：從網站拿掉那個 Pixel 的程式碼，切斷網站送進去的資料；向發卡機構停用廣告帳號綁的那張卡，擋住持續中的扣款（由權限設計推出）。之後走 Facebook 帳號的復原，帳號拿不回來時，在新的組合另建資料集，放回網站的是新的 Pixel ID。

成員的身分屬於個人，資產屬於擁有者。 三家的成員都是個人身分：Meta 是個人的 Facebook 帳號，GTM 與 GA4 是 Google 帳號。成員用的是公司 Google Workspace 的帳號時，公司在 Workspace 停權或刪除那個帳號，他就登不進 GTM 與 GA4（由帳號機制推出：GTM 與 GA4 以 Google 帳號登入）；用的是個人 Gmail 或個人 Facebook 帳號時，公司停用內部帳號碰不到它們，要到每一個組合與帳戶裡逐一移除；整份離職撤權清單見 職務交接與存取撤銷設計。資產建在公司的組合與帳戶底下時，員工離職只要由公司的管理員把他從成員中移除，公司就收回了他的權限，資產本身不受影響；資產建在員工自己的組合或帳戶底下時，那位員工就是擁有者，公司沒有可以移除他的權限。

資產與權限的移交方式：換代理商與事業轉手

移交的每一條路，除了看資產屬於哪一層，還要看兩件事：這一步要哪一方動手，以及那一方是否還聯絡得上、願意配合。下文的「對方」指公司以外要動手的那一方：換代理商時是舊代理商或廣告帳號的擁有者，事業轉手時是賣方；標「由權限設計推出」的做法，是本篇依三家的權限規則推導、Meta 與 Google 的說明頁沒有寫成流程的做法。認領廣告帳號要擁有者批准，分享舊的 Meta 資料集、匯出 GTM 容器、把帳戶連結進 Google Marketing Platform 機構都要對方的人操作，GA4 資源的搬移還要求執行的人在兩個帳戶都同時是管理員與編輯者。對方的狀態分成三種，出口各不相同。對方聯絡得上而且配合時，那段期間是處理這些事的窗口。對方失聯或拒絕配合、但手上沒有公司網站還在使用的資產權限時，剩下的只有不需要對方的路：另建資產、換掉網站上的 ID，以及 Meta 的管理員爭議與 GA4 的 analytics.txt 驗證這兩條由公司自己提出的復原途徑；管理員爭議要從與組合有關聯的個人檔案送件，公司的人從來不是那個組合的成員時這條路可能走不通，analytics.txt 要放在帳戶裡每一個送資料的網站上，所以資源放在代理商、帳戶裡還有其他客戶網站時，analytics.txt 這條路用不上（兩者皆依送件條件推出）。對方不只不配合、還握著資產的權限時（盜用帳號的人、與公司起爭議的代理商），對方能繼續收到網站送出的資料，透過 GTM 容器的發布權限還能在網站上執行程式碼，所以先切斷網站對那個資產的引用：拿掉頁面上屬於對方帳戶的 Pixel 與容器片段，再談移交或另建（由權限設計推出）。

換代理商時，資產若一開始就建在公司的組合與帳戶底下，要處理的只有權限：公司撤銷舊代理商的合作夥伴分享與成員身分，再把 Meta 資料集與廣告帳號以合作夥伴的方式分享給新代理商的組合，把 GTM 與 GA4 的成員權限給新代理商的人員。撤銷之前先列出舊代理商在公司資產上建立的整合（由權限設計推出）：GTM 容器裡指向代理商自己帳戶的代碼、GA4 連結的代理商 Google Ads 帳戶、Meta 上由代理商系統發出的 Conversions API 存取權杖。這些整合不會因為撤銷權限而消失：指向代理商帳戶的代碼與產品連結會繼續把資料送給代理商；依賴代理商發出的存取權杖的伺服器端事件，可能在撤銷後停止運作。

資產建在舊代理商的組合或帳戶底下時，網站上載入的 ID 是處理的起點。網站上可能同時留著舊代理商建立的 ID，以及更早之前的代理商或員工留下的 ID，而追蹤碼依 ID 送事件：留著的舊 Pixel ID 會讓事件繼續送進舊代理商的資料集，新的資料集也照常收事件，網站畫面與新報表都不會顯示異常；留著的舊 GTM 容器片段更嚴重，舊代理商仍持有那個容器的發布權限，等於仍能在公司網站上執行程式碼。所以要先查清每個網站實際載入的 Pixel ID、容器 ID 與評估 ID（查法見 用 Playwright 擷取追蹤碼請求，或在瀏覽器開發者工具的 Network 面板篩選 Meta 與 Google 的網域），再依各家處理：

• Meta：Meta 資料集無法轉給另一個組合，公司在自己的組合建新資料集、把網站上的 Pixel ID 換掉。查看舊資料的管道只能由擁有舊資料集的組合開放，合作結束後能不能開放只取決於舊代理商是否配合，所以要在換掉 Pixel ID 之前請舊代理商以合作夥伴的方式把舊資料集分享給公司。Pixel 建在舊代理商某一位人員自己的廣告帳號底下時，那個廣告帳號若不屬於任何組合，公司可以提出認領，由那位人員批准之後進入公司的組合；Meta 的說明頁沒有寫 Pixel 會不會隨廣告帳號一起進來，認領之後要在公司組合的資料集清單裡確認。那位人員不批准、舊代理商與那位人員都聯絡不上，或認領之後 Pixel 不在清單裡時，公司另建新資料集、換掉 Pixel ID，舊的歷史事件拿不回來。
• GTM：公司請舊代理商把容器匯出成 JSON 檔，由公司的人匯入公司帳戶裡的新容器，再換掉網站上的容器片段。舊代理商的帳戶專為這家公司建立、帳戶裡沒有其他客戶的容器時，也可以換人移交（由權限設計推出）：舊代理商把公司的人加成那個帳戶的管理員，再移除代理商的人，帳戶整個移交、容器 ID 不變。舊代理商的帳戶放著多個客戶的容器時，換人移交會把其他客戶的容器一起交出去，所以只有匯出匯入一途。舊代理商聯絡不上或不配合時，公司依網站上實際執行的追蹤碼（Network 面板裡看得到的 Pixel ID、評估 ID 與各家請求）在自己的帳戶建一個新容器，重新設定代碼，再換掉容器片段；舊容器的設定拿不回來。
• GA4：GA4 資源（property）的搬移受 Google Marketing Platform 機構（帳戶之上的管理單位）限制，說明頁寫明擋下的情形是兩個帳戶分屬不同機構，以及只有目的帳戶屬於機構而來源帳戶不屬於；執行的人在兩個帳戶都要同時是管理員與編輯者。依兩個帳戶目前與機構的關係：
  • 兩個帳戶屬於同一個機構：資源可以直接搬到公司的帳戶，評估 ID（Measurement ID）不變。
  • 只有公司的帳戶屬於機構：公司是目的帳戶，這正是說明頁擋下的狀態，所以要先由公司所屬機構的管理員把舊代理商的帳戶連結進公司的機構，兩個帳戶屬於同一個機構之後再搬；連結這一步要舊代理商配合。
  • 只有舊代理商的帳戶屬於機構：Google 的說明頁沒有寫這一種情形，本篇沒有驗證能不能直接搬。說明頁寫明可以搬的是兩個帳戶屬於同一個機構的情形，所以符合說明頁條件的做法是請舊代理商機構的管理員把公司的帳戶連結進同一個機構再搬，這要舊代理商配合（依說明頁的條件推出）。搬完之後公司的帳戶仍在舊代理商的機構底下，能不能移出、機構管理員還保有哪些權限，本篇沒有查證（見〈追蹤資產換擁有者的條件〉末段）。
  • 兩個帳戶分屬不同機構：Google 的說明頁寫明不能搬。
  • 兩個帳戶都不屬於任何機構：說明頁沒有寫是否能直接搬。符合說明頁條件的做法是公司建立機構、把兩個帳戶連結進同一個機構再搬；舊代理商的帳戶專為這家公司建立時，也可以把整個帳戶換人移交（由權限設計推出）。
  • 以上各種情形都搬不了，或需要配合的舊代理商聯絡不上、不配合時（任一成立）：公司另建資源、換掉網站上的評估 ID，歷史報表留在舊帳戶。

事業轉手時，買方要的是整套資產連同歷史資料。Meta、GTM 與 GA4 三家都能用換人的方式移交最上層的擁有者（Meta 的組合、GTM 帳戶、GA4 帳戶；由權限設計推出）：賣方把買方指定的人加成組合的完整存取權限，以及 GTM 帳戶與 GA4 帳戶的管理員，再移除賣方的人。在移除賣方的人之前，要先由買方確認自己登得進去、管理得了，因為移除之後賣方已經沒有權限補救；買方這時才發現自己管理不了的話，Meta 只剩管理員爭議、GA4 只剩 analytics.txt 驗證、GTM 沒有復原途徑。這條路徑底下的 Pixel ID、容器 ID、評估 ID 與歷史資料都不動，前提是三件事先處理好（理由見〈追蹤資產換擁有者的條件〉一節末段）：組合裡沒有別的組合分享進來的資產、廣告帳號的付款方式改成買方的、GA4 與 GTM 帳戶不在賣方的機構底下。

賣方的組合或帳戶裡如果還放著與這個事業無關的資產，整個組合或帳戶不能直接交出去。GA4 與 GTM 還有一條路：賣方先把無關的 GA4 資源搬到賣方另一個帳戶、把無關的 GTM 容器匯出匯入到賣方的新帳戶（那些無關容器原本所在的賣方網站要換成新容器 ID，買方的網站不受影響），帳戶裡只剩這個事業的資產之後再整個移交，買方手上的評估 ID 與容器 ID 都不動（由權限設計推出）。Meta 的組合做不到這一步，因為資料集與組合內建立的廣告帳號搬不出去，只能逐項處理；GA4 與 GTM 不走上面那條路時也一樣逐項處理：粉絲專頁移到買方的組合；Meta 資料集只能由賣方以合作夥伴的方式分享給買方，或由買方另建，組合內建立的廣告帳號也只能由賣方分享給買方或由買方另建；GA4 資源依換代理商那一段 GA4 條列的機構條件搬到買方的帳戶，買賣雙方分屬不同機構時搬不了，只能由買方另建；GTM 容器匯出匯入。

所以一個組合或帳戶只放一個事業的資產，轉手時才有整包移交這個選項。Google 說一家公司通常只需要一個 GTM 帳戶，本篇認為這適用於只經營一個事業的公司；同一家公司經營日後可能分拆出售的事業時，按事業各開一個組合與帳戶。

本站實測資產的擁有者

本站為 Meta Pixel 實測頁 與 Google Tag Manager 實測頁 建立的測試資產，套用的是同一個原則：一個擁有者只放一個用途的資產。Meta 另開一個組合、GTM 與 GA4 各另開一個帳戶，裡面只放實測用的 Meta 資料集、GTM 容器與 GA4 資源，不放進登入帳號原本就有的組合或帳戶；實測結束時，GTM 與 GA4 的帳戶可以整個刪除（刪除後分別有 30 天與 35 天可以從垃圾桶救回），Meta 資料集依規則刪不掉，會一直留在這個只放實測資產的組合裡，不會混進其他用途的組合。建立過程中三家各自的檢查與預設值（Meta 的組合名稱審查、資料集表單預設勾選的 Conversions API 選項、GA4 預設勾選的資料共用選項），以及這些資產上做的擷取，記錄在 用 Playwright 擷取追蹤碼請求 的測試帳號一節與各次結果。

延伸閱讀：資產建立之後的資料路徑與部署權限

這篇處理的是資產屬於誰；資產建立之後，事件怎麼從網站送進那個 Meta 資料集或 GA4 資源，由各家的機制文說明。Pixel 的瀏覽器端與伺服器端兩條路徑，以及兩條路徑送出同一個事件時靠 event_id 去重，見 Meta Pixel 與 Conversions API；代理商取得 GTM 容器的發布權限之後能在網站上做什麼、發布前怎麼驗證，見 Google Tag Manager 的預覽模式與自訂 HTML 兩節。