廣告平台轉換追蹤的資料消費者

Meta Pixel 送出的事件，主要的消費者是 Meta 的廣告投放系統：投放演算法依轉換事件學習該把廣告給誰看，廣告後台依它計算每一檔廣告帶來幾筆轉換。這一點讓它跟 Mixpanel / Amplitude 這類行為分析工具分開——行為分析的消費者是自己的產品團隊，事件怎麼命名、帶什麼屬性由自己決定；廣告平台的事件要讓平台的演算法讀得懂，所以命名照平台的規定。

Meta 定義了一組標準事件（standard events）：PageView、ViewContent、AddToCart、InitiateCheckout、Purchase、Lead、CompleteRegistration 等。廣告活動的最佳化目標綁在這些事件名稱上，例如以「購買」為目標的廣告活動讀的是 Purchase；Purchase 另外要帶 value 與 currency，平台才算得出廣告投資報酬。自己的事件命名（事件命名規範 的 namespace.action）因此需要一層對映：checkout.complete 送到自己的 collector，同一筆在送往 Meta 時改名成 Purchase。對映表寫在一個地方、由工程維護，比散在各個埋點呼叫裡改名好查。

廣告平台各自用自己看得到的事件做歸因，同一筆訂單可能同時被 Meta 與 Google Ads 算成自己帶來的轉換，兩個後台的轉換數加總會大於實際訂單數。跨渠道的歸因模型見 Attribution。

Meta Pixel 在瀏覽器裡做的事

Pixel 的基本碼從 connect.facebook.net 載入 fbevents.js，再用 fbq() 這個全域函式初始化並送事件。fbevents.js 載入後會再向 Meta 取得這個 Pixel 的設定檔，設定檔載入的模組（plugin，fbevents.js 依 Pixel 設定檔載入的程式片段）會在網站沒有呼叫 fbq() 的情況下自己送事件，例如依按鈕點擊送出的 SubscribedButtonClick，內容包含按鈕文字；實測見 用 Playwright 擷取追蹤碼請求 的 Meta Pixel 有視窗那一次。

1<script>
2  // Meta 提供的載入片段（略）：定義 fbq 並從 connect.facebook.net 載入 fbevents.js
3  fbq('init', 'PIXEL_ID');   // PIXEL_ID 換成 Events Manager 裡那個 Pixel 的 ID
4  fbq('track', 'PageView');  // 每一頁載入時送一次
5</script>

fbq('init', ...) 的第二個引數是 Pixel ID，每個 Pixel 在 Meta Events Manager 裡有自己的一串數字，一個網站可以初始化多個 Pixel。PIXEL_ID 在這裡是佔位值，要換成自己 Events Manager 裡顯示的那一串。

送轉換事件時，fbq('track', ...) 依序接事件名稱、事件參數、以及選填的第四個引數：

1// 第二個引數是標準事件名稱，第三個是事件參數，第四個帶這一筆事件的唯一 ID
2fbq('track', 'Purchase',
3  { value: 1280, currency: 'TWD' },
4  { eventID: 'order-20261022-0042' });

value 與 currency 是這一筆購買的金額與幣別，從訂單資料取值。eventID 是這一筆事件的識別碼，只送 Pixel 的時候可以省略；同一筆事件還要從伺服器再送一次時就必須帶，原因在〈兩路並送時的去重規則〉一節。

Pixel 也在網站自己的網域上寫 cookie：_fbp 記錄這個瀏覽器的識別碼；使用者從廣告點進來時，落地網址會帶 fbclid 參數，Pixel 把它存成 _fbc。這兩個 cookie 是第一方 cookie（寫在網站自己的網域上），之後伺服器端送事件時會用到它們的值。

瀏覽器端事件的損失路徑

Pixel 的事件從讀者的瀏覽器發出，所以它會在讀者端被擋下，而網站這一端收不到任何錯誤：

• 廣告攔截器擋下 script 本身：攔截清單收錄 connect.facebook.net 這類已知追蹤網域，fbevents.js 載不進來，fbq() 之後的所有事件都不會送出。
• 瀏覽器的追蹤防護縮短 cookie 壽命：Safari 的 Intelligent Tracking Prevention（ITP）會限制由 JavaScript 寫入的第一方 cookie 的有效期，_fbp 因此比預期更早消失：一般情形是使用者 7 天沒有互動之後刪除；從 Meta 廣告帶著 fbclid 進站那一次在落地頁寫下的 cookie，上限只有 24 小時，所以同一個人點了廣告、過了一天以上才回來購買時，就可能被當成另一個瀏覽器（期限規則見 First-party Cookie（第一方 cookie））；部分瀏覽器與 App 內開啟的連結也會移除網址裡的 fbclid。
• 同意聲明還沒取得：在要求事先同意的法域（例如 GDPR 下的歐盟讀者），網站在使用者同意之前不能載入 Pixel，這段期間的事件依規定就不送。
• 自動化與機器人流量過濾：實測的這個 Pixel，設定檔裡的模組依 User-Agent 判斷機器人流量（模組由 Meta 依各 Pixel 的設定檔下發），無頭瀏覽器（User-Agent 帶 HeadlessChrome）送出的事件在瀏覽器裡就被攔下。fbevents.js 照常載入、cookie 照常寫入，網站這一端看不出事件沒送；用自動化工具驗證追蹤設定時會撞上這一條，實測見 用 Playwright 擷取追蹤碼請求 的無頭模式那一次。
• 跳頁中斷：購買按鈕按下後立刻導向感謝頁，送事件的請求可能還沒送完頁面就被卸載。這是所有前端事件追蹤共通的狀況，機制與 sendBeacon 的解法見 JS/TS 平台適配。

每個網站被擋下的比例取決於讀者組成（裝攔截器的比例、iOS 的比例、歐盟流量的比例），網路上流傳的百分比是別人網站的數字。量自己網站的方式是對帳：同一段期間內，訂單資料庫裡的訂單數與 Events Manager 收到的 Purchase 數相比，差距就是這個網站的瀏覽器端損失。

Conversions API：從伺服器送同一批事件

Conversions API 讓網站的伺服器直接把事件 POST 到 Meta 的 Graph API（/<PIXEL_ID>/events），請求不經過讀者的瀏覽器，所以廣告攔截器與 cookie 期限都影響不到它。代價是伺服器要自己準備瀏覽器原本會自動附上的資訊：

 1{
 2  "data": [{
 3    "event_name": "Purchase",
 4    "event_time": 1792656000,
 5    "event_id": "order-20261022-0042",
 6    "action_source": "website",
 7    "event_source_url": "https://shop.example.com/checkout/thanks",
 8    "user_data": {
 9      "client_user_agent": "<下單時瀏覽器的 User-Agent>",
10      "client_ip_address": "<下單時的來源 IP>",
11      "fbp": "<讀自 _fbp cookie>",
12      "fbc": "<讀自 _fbc cookie>",
13      "em": ["<正規化後的 email 的 SHA-256>"]
14    },
15    "custom_data": { "value": 1280, "currency": "TWD" }
16  }]
17}

欄位的來源與限制：

• event_name、event_id、custom_data 與 Pixel 那一筆相同，名稱的對映方式見〈廣告平台轉換追蹤的資料消費者〉一節。
• event_time 是事件發生的 Unix 時間（秒）。Meta 接受的範圍是送出當下往前七天內；一批資料裡只要有一筆超過七天，整個請求會被拒絕、一筆都不處理，所以用排程補送積壓的事件時要先過濾掉過期的那些。
• action_source 標明事件發生在哪裡，網站事件填 website。Meta 對網站事件另外要求 event_source_url（事件發生的頁面網址，網域要與 Meta 後台驗證過的網域一致）與 client_user_agent。
• user_data 是 Meta 用來把這筆事件對回某個 Meta 使用者的資料。fbp、fbc 從請求帶上來的 cookie 讀，client_ip_address 與 client_user_agent 從下單那一次請求的 header 讀，這四個欄位原樣送出；email、電話這類個人資料要先依 Meta 規定的方式正規化（去空白、轉小寫等），再做 SHA-256 雜湊才送。給的欄位越多，Events Manager 顯示的事件比對品質（Event Match Quality）越高。

請求要帶 Meta 發給這個 Pixel 的 access token，這個 token 只能放在伺服器上：放進前端程式碼等於公開，任何人都能用它往這個 Pixel 灌假事件。前端程式碼裡的存取憑證會被提取的機制見 Client-side SDK 認證的根本限制。user_data 裡雜湊過的 email 仍然是可以對回個人的資料，送出前的同意與用途說明照 GDPR 最小化原則的工程落地 的原則處理。

兩路並送時的去重規則

Meta 建議 Pixel 與 Conversions API 並用：Pixel 送得到的時候帶著完整的瀏覽器資訊，送不到的那些由伺服器補上。兩條路徑都送成功的事件會被 Meta 收到兩次，所以 Meta 用兩個欄位判斷是不是同一筆：Pixel 的 eventID 與伺服器的 event_id 相同、且兩邊的事件名稱相同。依 Meta 文件，去重只在同一個 event_id 第一次送達後的 48 小時內生效；兩筆幾乎同時抵達時 Meta 保留瀏覽器那一筆；48 小時內沒有收到瀏覽器那一筆時，伺服器那一筆照常計入。

這條規則決定了 event_id 要在哪裡產生：在事件的源頭產生一次，再同時交給前端與後端。訂單編號符合這個條件，前後端都拿得到同一個值：感謝頁從訂單資料讀出編號放進 fbq 的第四個引數，伺服器在建立訂單時用同一個編號送 Conversions API。兩邊各自產生一個隨機 UUID 是常見的錯法，兩個值永遠對不上，每一筆轉換都會被算兩次，廣告後台的轉換數膨脹而沒有任何錯誤訊息。

Meta 另有一種用 event_name 加 fbp 或 external_id 比對的去重方式，文件註明它通常只在瀏覽器那一筆先到、伺服器那一筆後到的順序下有效，所以只當作 event_id 的備援。

去重的道理與自架 collector 處理 SDK 重送是同一件事：重送的事件要靠一個在源頭就決定的 ID 才認得出來，見 端到端資料完整性。

用 Test Events 驗證送出的事件

Events Manager 在每個 Pixel 底下有 Test Events 頁面，它即時列出這個 Pixel 收到的事件、來源是瀏覽器還是伺服器、以及去重的結果。兩條路徑的驗證方式不同：

• 瀏覽器端：在 Test Events 頁面輸入網站網址開啟，或在瀏覽器裝 Meta Pixel Helper 擴充功能，操作一次購買流程，確認 Purchase 出現且帶著 value、currency 與 eventID。
• 伺服器端：Test Events 頁面會給一組測試代碼，伺服器送 Conversions API 時在請求裡加上 test_event_code 欄位，那批事件就會出現在測試視窗裡。正式上線前要把這個欄位拿掉；帶測試代碼的事件會不會計入正式報表，以 Events Manager 當下的說明為準。

驗證去重時兩條路徑一起跑：同一筆測試訂單在 Test Events 裡應該看到瀏覽器與伺服器各一筆，並標示其中一筆被去重。只看到一筆時，先確認另一條路徑確實沒送，還是 event_id 對不上而被當成兩筆不同的事件。

和自架事件追蹤並存的資料流

接了 Pixel 與 Conversions API 之後，同一個業務事件（一筆購買）會往三個地方送：自己的 collector、Meta 的瀏覽器端、Meta 的伺服器端。業務事件的定義只寫一次，送往各家時各自做名稱與欄位的對映，比在各個埋點位置分別呼叫三家的 API 好維護，改一個欄位不必找遍三種呼叫。這個分流結構與它的保留期、PII 取捨，在 監控資料的雙重用途 有完整的推導。

本篇描述的瀏覽器端行為可以在 Meta Pixel 實測頁 按按鈕觸發、對照它實際送出的請求與 cookie。追蹤碼要由誰、用什麼流程放上網站，是另一層的決定。行銷團隊常用 tag manager 自行加 Pixel，那條路徑的約定與治理見 Google Tag Manager。Pixel 的資料集屬於哪一個商家資產管理組合、建立之後能不能轉給另一個組合，以及委託代理商時資料集該建在誰的組合裡，見 追蹤資產的歸屬。

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

頁面打開時不載入任何 Meta 的 script。按下「載入 Meta Pixel 並送 PageView」之後，面板才把 fbevents.js 從 connect.facebook.net 注入頁面，並用填在欄位裡的 Pixel ID 初始化；在那之前這一頁沒有任何送往 Meta 的請求，請求清單可以直接驗證這一點。注入的 script 在重新整理或離開這一頁時就消失，而 Pixel 寫下的 cookie 會留在這個網域上，直到按「清除這一頁的追蹤 cookie」或瀏覽器自己刪除。

Pixel ID 欄位填的是 Meta Events Manager 裡某個 Pixel 的 ID。欄位預設空白，填自己的測試 Pixel ID：在事件管理工具的資料集頁面讀得到，商家設定頁網址裡的 selected_asset_id 是另一個編號，填錯時頁面不會報錯（見 用 Playwright 擷取追蹤碼請求 的指令一節）。用自己的 Pixel 實測時，事件會出現在那個 Pixel 的 Test Events 頁面，可以對照 Meta 那一端實際收到了什麼。

對照面板讀出各個呼叫的效果

面板分成三塊。「操作紀錄」列出按鈕實際執行的 fbq() 呼叫；「這一頁送出的跨網域請求」來自瀏覽器的 Resource Timing 紀錄，列出這一頁向其他網域發出的每一個請求與它的查詢參數；「追蹤 cookie」列出這個網域上以 _fbp、_fbc 等前綴開頭的 cookie（這些是寫在網站網域上的第一方 cookie）。操作紀錄、請求與 cookie 並排讀，就能把一個呼叫對到它造成的網路請求與狀態變化。

• 載入 Pixel 之後：請求清單出現 fbevents.js 與 signals/config/<Pixel ID>（這個 Pixel 的設定檔）兩個 script 請求，cookie 清單在幾秒內出現 _fbp。PageView 等事件請求不會出現在這個清單裡：fbevents.js 以隱藏的表單把事件以 POST 提交到一個 iframe，這類提交不進這一頁的 Resource Timing。要看事件請求，打開瀏覽器開發者工具的 Network 面板，篩選 facebook.com/tr；表單 body 裡的 ev 是事件名稱，其餘參數的名稱與意義由 Meta 決定、會隨版本調整，實測的參數對應見 用 Playwright 擷取追蹤碼請求 的各次結果。
• 送 Purchase：操作紀錄裡的 eventID 是這次按鈕產生的值，在 Network 面板那一筆 /tr/ 請求的表單 body 裡是 eid 參數，這就是 Conversions API 去重時要對上的那一個。value 與 currency 在同一筆的 cd[value] 與 cd[currency]。同一時間還會多一筆自動事件 SubscribedButtonClick，那是 Pixel 依按鈕點擊自動送出的事件，內容包含按鈕文字。
• 帶 fbclid 參數重新開啟這一頁：按鈕把一個測試用的 fbclid 加進網址再重新載入。重新載入後再按一次「載入 Meta Pixel」，cookie 清單會多出 _fbc，值裡包含剛才的 fbclid。這是讀者從廣告點進網站時 Pixel 保存點擊來源的方式。
• 載入失敗：狀態列顯示「載入失敗」時，代表 fbevents.js 的請求被擋下，常見來源是廣告攔截器、瀏覽器的追蹤防護或公司網路的政策。這時按其他按鈕，fbq() 只會把呼叫排進佇列，請求清單裡不會出現任何送往 Meta 的請求。這正是瀏覽器端事件損失的樣子：網站這一端沒有任何錯誤訊息。

請求清單在頁面打開時就可能已經有幾筆紀錄，那些是本站每一頁都會載入的第三方資源（例如從 cdn.jsdelivr.net 載入的 Mermaid）與本站的流量 beacon（送往 script.google.com），與 Meta 無關。本站的 beacon 怎麼設計見 Automation 模組二：流量 beacon 實作，拿來和 Pixel 的請求並排看，是自製追蹤與第三方追蹤碼在送出內容上的對照。

Resource Timing 只記錄網址、看不到 POST 請求的 body，而 Pixel 以表單提交到 iframe 的事件連網址都不會出現在這裡。要看完整的請求內容，打開瀏覽器開發者工具的 Network 面板，篩選 facebook 再點開那一筆。

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

擷取腳本不直接把服務商的 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 兩節。