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

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 的資料集屬於哪一個商家資產管理組合、建立之後能不能轉給另一個組合，以及委託代理商時資料集該建在誰的組合裡，見 追蹤資產的歸屬。

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 跟著換的處理，見 追蹤資產的歸屬。

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

頁面打開時不載入任何 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 再點開那一筆。

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

頁面打開時不載入 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 面板。

概念位置

第一方 cookie 是追蹤碼在第三方 cookie 被瀏覽器限制之後保存識別碼的位置。第三方 cookie 由 vendor 的網域直接讀寫，第一方 cookie 寫在網站網域上，瀏覽器送往 vendor 網域的請求不會在 Cookie 標頭裡帶上網站網域的 cookie，所以追蹤碼在瀏覽器裡讀出它的值，放進事件請求的參數送出：在預設設定下（使用者沒有透過同意機制拒絕、追蹤碼的第一方 cookie 設定沒有關掉），Meta Pixel 的每一筆事件都帶 fbp 參數，值就是 _fbp 的內容；GA4 的 collect 請求帶 cid，與 _ga 值以點分隔的最後兩段數字相同。網站自己沒有呼叫的自動事件也帶著這些參數送出。

cookie 期限的設定者與瀏覽器上限

cookie 的到期時間由寫入它的 script 設定，再受瀏覽器的規則截斷。Chrome 從 104 版起把任何 cookie 的到期時間上限訂為 400 天，要求更久的 cookie 會被改成 400 天。Safari 的 Intelligent Tracking Prevention（ITP）對追蹤碼常用的寫法另有三條限制，依 WebKit 的追蹤防護說明頁：由 JavaScript 寫入的 cookie 與其他 script 寫得到的儲存資料（例如 localStorage），在使用者 7 天沒有與這個網站互動之後刪除（WebKit 先前的說明以使用 Safari 的天數計，現行說明頁沒有寫單位），重新起算的條件是互動、不是單純的造訪；ITP 偵測到網址帶著點擊 ID 這類參數（link decoration）時，落地頁上由 JavaScript 寫入的 cookie 期限上限是 24 小時（WebKit 先前的說明寫明的條件是：把使用者導過來的網域被分類為追蹤者，而且網址帶查詢字串或片段）；回應來自偽裝成第一方、實際指向第三方的伺服器（CNAME 或第三方 IP 偽裝）時，那個 HTTP 回應寫入的 cookie 期限上限是 7 天。所以同一個追蹤碼在不同瀏覽器上的 cookie 壽命不同：GA4 代碼替 _ga 與 _ga_<評估 ID> 設的預設期限是兩年，在 Chromium 上實測看到的 400 天是瀏覽器的上限，不是 GA4 的設定；從 Meta 廣告帶著 fbclid 點進來的那一次，_fbc 與 _fbp 正好在落地頁上由 JavaScript 寫入，在 Safari 上可能只留一天。

可觀察訊號與例子

在開發者工具的 Application 面板（Chrome）或儲存空間面板（Firefox）查看網站網域底下的 cookie，看名稱、網域、到期時間與 HttpOnly 欄位；由 JavaScript 寫入的 cookie 不能設 HttpOnly，所以頁面上任何 script 都讀得到它。一次在 Chromium 上的實測裡，_fbp 與 _fbc 的到期時間是寫入起算 90 天，_ga 與 _ga_<評估 ID> 是 400 天，四個都不是 HttpOnly、SameSite 都是 Lax；_fbc 只有網址帶了廣告的點擊 ID（fbclid）時才寫入。各 cookie 的值怎麼對應到事件參數，以 用 Playwright 擷取追蹤碼請求 的結果檔為準。

判讀方式

一個 cookie 受哪些限制，取決於兩個屬性：它寫在哪個網域，以及它由 JavaScript 寫入還是由伺服器回應的 Set-Cookie 標頭寫入。寫入方式可以在 Network 面板分辨：某個回應的 Set-Cookie 標頭帶著這個名稱，就是伺服器寫的；所有回應都沒有、而它在 script 執行之後出現，就是 JavaScript 寫的。網域決定瀏覽器的第三方 cookie 封鎖管不管得到它，封鎖第三方 cookie 不影響第一方 cookie；寫入方式（連同回應來自誰的伺服器）決定 ITP 的哪一條限制管得到它，JavaScript 寫入的第一方 cookie 仍然受 ITP 限制，所以同一個人隔一週以上沒有互動、或從廣告點進來隔天才回來時，可能被追蹤碼當成另一個瀏覽器。用 Network 面板分辨寫入方式時，要用無痕視窗或先清掉這個網站的 cookie、在載入頁面之前就打開面板，否則前一次造訪留下的 cookie 會被誤判成 JavaScript 寫的。在歐盟 ePrivacy 指令下（第 5(3) 條，本站的解讀見配額、濫用防護、隱私與遷移訊號的〈隱私與 PII 邊界〉），判斷是否要取得使用者同意時，看的是「在使用者的裝置上儲存或讀取資訊」這個動作，第一方或第三方都在範圍內；把識別碼寫成第一方 cookie 改變的是瀏覽器的限制，改變不了這條同意的要求。

完整章節

追蹤碼寫下哪些 cookie、值怎麼對應到事件參數 → 用 Playwright 擷取追蹤碼請求。_fbp、_fbc 在伺服器端事件裡的用途與 ITP 造成的損失 → Meta Pixel 與 Conversions API。cookie 期限在儲存限制裡的位置 → GDPR 最小化原則的工程落地。

篇目

擷取紀錄在第一次擷取完成之前維持 draft: true；2026-10-23 GTM 與 Meta Pixel 各完成一次擷取之後發布。

篇目的收錄條件

收進來的 vendor 要有一段自架方案沒有的機制可以寫：廣告平台的資料消費者是投放演算法、tag manager 把部署權交給行銷人員，這些在模組一到八的自架脈絡裡沒有對應物。只是功能清單不同的 vendor（另一家 error tracking）先在模組六的對照文補一列，累積到有獨立機制可講再開篇。

實測方式的決策紀錄

本站已經有一套自製的流量 beacon（layouts/partials/custom_body.html，說明在 Automation 模組二：流量 beacon 實作），設計上刻意不送完整 User-Agent、識別碼是隨機值、有 opt-out。全站加上第三方追蹤碼會推翻這組設計：讀者的瀏覽紀錄送到 Meta 與 Google、頁面多出 _fbp、_ga 這類 cookie、每一頁多載入第三方 script，歐盟讀者的部分還需要同意聲明。所以不全站嵌入，採用兩種實測方式並行（2026-10-22 決定）：

• 獨立實測頁：實作是 layouts/shortcodes/vendor-lab.html。頁面預設不注入任何第三方 script，讀者按下載入按鈕才注入；ID 由讀者填寫，預設值取 hugo.toml 的 [params.vendorLab]。tests/vendor-lab.spec.ts 把 vendor 網域攔下來回 stub，守住「按下之前零請求」與 ID 格式檢查。
• 本機 Playwright 擷取：scripts/vendor-capture/capture.mjs 操作實測頁並把請求、cookie、資料層寫成 JSON（scripts/vendor-capture/results/），每份結果帶擷取時間、瀏覽器版本、vendor script 的回應標頭與本體雜湊，因為 vendor 改版之後結果就不再適用。Meta Pixel 在無頭瀏覽器裡不送事件，擷取 Meta 要加 --headed（2026-10-23 實測）；腳本不改寫 User-Agent。
• 文章不寫測試 ID、實測頁不設預設值（2026-10-23 決定）：Pixel ID、容器 ID 與評估 ID 本來就寫在網頁原始碼裡，公開它們不會讓別人登入帳號；風險在反方向，任何人都能拿 ID 往帳號送事件，而 Meta 的資料集不能刪除，被灌入假事件之後只能另建一個。這組測試帳號只放實測資產、沒有投放廣告，被灌入假事件的影響只在測試報表上，所以接受這個風險：擷取結果的 JSON 保留原始 ID（repo 是公開的，ID 因此查得到），供日後比對。文章正文不寫實際值，理由是讀者照抄別人的 ID 去測試，事件會送進別人的帳號、也學不到用自己的 ID；文章只描述 ID 的格式與查詢位置。hugo.toml 的 [params.vendorLab] 維持空白，讀者在實測頁填自己的 ID。
• 測試帳號：Meta 商家資產管理組合「Tarragon Tech Notes」裡的資料集、GTM 帳戶 vendor-lab-test、GA4 帳戶 vendor-lab-test，都只放實測資產。建立時的檢查與預設值記在 用 Playwright 擷取追蹤碼請求 的〈擷取用的測試帳號〉一節，為什麼另開擁有者記在 追蹤資產的歸屬 的〈本站實測資產的擁有者〉一節。

Conversions API 這類伺服器端路徑在本站有一個限制：本站的接收端是 Apps Script，而 Apps Script 的 doPost 讀不到請求的 HTTP header（拿不到 IP 與 User-Agent），Meta 對網站事件要求的 client_user_agent 只能由前端放進 payload，這又回到送完整 User-Agent 的隱私取捨上，所以伺服器端目前只寫機制、不做實測。

Backlog

概念位置

無頭模式改變的是瀏覽器自己對外暴露的特徵，追蹤碼在訪客的瀏覽器裡、收資料的伺服器在 vendor 那一端，都可能依這些特徵決定事件送不送出、收不收下。最直接的特徵是 User-Agent（瀏覽器在每個請求裡附上的身分字串）：一次以 Playwright 預設無頭模式啟動 Chromium 的實測裡，User-Agent 帶 HeadlessChrome 字樣，有視窗模式下是一般的 Chrome。被程式驅動則另有自己的特徵，navigator.webdriver 在 Playwright、Puppeteer、Selenium 驅動的瀏覽器裡是 true，有沒有視窗都一樣。所以「擋無頭瀏覽器」與「擋自動化」是兩條不同的規則：比對 HeadlessChrome 字樣的規則換成有視窗模式就不命中，比對 navigator.webdriver 的規則兩種模式都命中。被攔下的事件裡也包括網站沒有呼叫的自動事件，它們走的是同一條送出路徑。

可觀察訊號與例子

本站用 Playwright 寫的擷取腳本（用 Playwright 擷取追蹤碼請求）在實測頁上載入本站測試用的一個 Meta Pixel。fbevents.js 載入後會向 Meta 取得這個 Pixel 的設定檔，設定檔指定要載入的模組（plugin）裡有一個 botblocking，它拿 navigator.userAgent 比對一份含 HeadlessChrome/ 的機器人規則清單。無頭模式下 fbevents.js 照樣載入、_fbp 照樣寫入，而 PageView、ViewContent、Purchase 一筆都沒有送出；腳本改用有視窗模式之後，三筆事件都送出了。這個模組只攔事件請求，script 的載入與第一方 cookie 的寫入不受影響，頁面上的狀態訊息在兩種模式下也相同，從頁面上看不出事件沒送。GA4 的 collect 請求在無頭模式下照樣送出並收到回應；GA4 在接收端預設排除已知機器人流量，依據是 Google 的研究與 IAB（Interactive Advertising Bureau，網路廣告業的產業組織）的機器人清單，被排除了多少不會顯示，所以從擷取結果判斷不出無頭模式的事件是否進了報表。

判讀方式

兩次擷取用同一個 Pixel、在相近的時間、做相同的操作、只切換有沒有視窗時，兩種模式的結果差異量的是追蹤碼對無頭特徵的反應：有視窗模式下送得出、無頭模式下送不出的事件，是被比對 User-Agent 這類無頭特徵的規則攔下的。兩次之間隔得久，Pixel 的設定檔可能已經改版，差異就不能只歸給無頭模式。有視窗模式的 Playwright 仍然是被程式驅動的瀏覽器（navigator.webdriver 為真），所以它的結果不等於真人訪客的結果；追蹤碼改成依 navigator.webdriver 判斷時，有視窗模式也會被攔。比對自建統計與商業追蹤碼的訪問數時，差額裡可能有一部分是無頭瀏覽器的訪問：自建統計的接收端收下並標成機器流量，Meta Pixel 在瀏覽器裡就丟掉。反過來，GA4 的代碼在無頭模式下照常送出事件，所以拿正式網站的評估 ID 或 Pixel ID 跑自動化測試，事件會送進正式的資源，進不進報表由 Google 的已知機器人排除判定，而排除了多少看不到；擷取與測試用測試專用的帳戶與 ID，做法見用 Playwright 擷取追蹤碼請求的〈擷取用的測試帳號〉。

完整章節

無頭與有視窗兩種模式下 Meta Pixel 實際送出的請求、botblocking 的機制與擷取紀錄要記下的模式 → 用 Playwright 擷取追蹤碼請求。自建統計怎麼用 User-Agent、navigator.webdriver 等訊號標記機器流量 → 辨識自動化流量。GA4 預設的已知機器人排除與主機名稱篩選器 → Client-side SDK 認證的根本限制。

概念位置

自動事件收集決定的是「事件從哪裡來」，位置在事件產生的那一端，比管線上的取樣與遮蔽都早：事件的欄位由 vendor 的規則決定，網站要等它送出之後才看得到內容。它與本站自建 SDK 的自動攔截機制（auto-intercept）同樣不需要開發者為每個事件寫程式，分辨兩者的依據是送出規則由誰持有：自動攔截的規則寫在網站自己的 SDK 程式碼裡，自動事件收集的規則由 vendor 決定，網站的原始碼裡看不到。名稱各家不同：Meta 把這類事件叫自動事件（automatic events），GA4 叫自動收集的事件（automatically collected events），本站把兩者統稱為自動事件。兩家的範圍與開關也不同。

Meta Pixel 的自動事件由 Pixel 的設定檔指定的模組產生：fbevents.js 載入後會向 Meta 取得這個 Pixel 的設定檔，設定檔決定要載入哪些模組（plugin，見 Meta Pixel 與 Conversions API 的〈Meta Pixel 在瀏覽器裡做的事〉）。實測時每按一次頁面上的按鈕，fbevents.js 都在網站呼叫的事件之外多送一筆 SubscribedButtonClick，內容包含按鈕文字（cd[buttonText]）、按鈕的 DOM 特徵與頁面特徵；設定檔來自 Meta 的伺服器，所以送出哪些自動事件由 Meta 那一端的設定決定，網站的原始碼裡看不到。要關掉 Pixel 依按鈕點擊與頁面中繼資料自動送出的事件，Meta 的開發者文件給的做法是在 Pixel 基本碼裡、fbq('init', …) 之前加一行 fbq('set', 'autoConfig', false, '<Pixel ID>')，<Pixel ID> 換成自己的 Pixel ID。

GA4 的自動收集事件分成只要裝了 Google 代碼就會送的基本事件，例如 first_visit、session_start、user_engagement，以及由加強型評估（enhanced measurement）控制的事件。加強型評估是網頁資料串流（GA4 資源裡代表一個網站資料來源的設定單位）上的一組開關，涵蓋捲動、外連點擊、站內搜尋、影片互動、檔案下載與表單互動，其中檔案下載會帶連結文字（link_text）、表單送出會帶送出按鈕的文字。page_view 也列在加強型評估底下，而它是其中唯一關不掉的一項。這組開關在 GA4 管理介面的資料串流設定裡，需要編輯者以上的權限。

可觀察訊號與例子

自動事件在請求裡的樣子與網站自己呼叫的事件相同，差別只在網站的程式碼裡找不到對應的呼叫。Meta 的事件請求送到 www.facebook.com/tr/，事件名稱在 ev 參數；GA4 的事件請求送到 Google Analytics 網域下的 g/collect（在開發者工具的 Network 面板以 collect 篩選），事件名稱在 en 參數。一次 Meta Pixel 的實測裡，網站呼叫了 ViewContent 與 Purchase 各一次，擷取結果裡多出兩筆 SubscribedButtonClick，各自緊跟在一次按鈕點擊之後。

判讀方式

網站原始碼只列得出手動埋點的那一部分，網站實際送出的資料要從送出的請求裡數；按鈕文字、連結文字這類欄位也在送出範圍內，按鈕或連結上顯示了使用者的個人資料時，那段文字會一起送到 vendor。兩種埋點方式的取捨方向相反：手動埋點會漏掉沒有寫追蹤程式的互動，換到的是送出的欄位全部由開發者決定；自動收集不需要逐一標記，而涵蓋哪些互動、送出哪些欄位由 vendor 的規則決定、會隨 vendor 改版變動。vendor 改版不會通知網站，所以送出資料的盤點要定期重做；Meta Pixel 的 fbevents.js 版本可以在頁面的開發者工具 Console 輸入 fbq.version 讀出，但自動事件由每個 Pixel 的設定檔決定，設定檔或事件管理工具裡的設定改了，fbq.version 不會變，所以版本相同不代表送出的內容沒變，盤點仍要看實際送出的請求。

完整章節

Meta Pixel 自動加送的事件與它的欄位 → 用 Playwright 擷取追蹤碼請求的〈各次擷取的結果〉。以 data-track 屬性手動埋點的感測器設計，與它和自動收集的對照 → 前端感測器設計。設定檔指定的模組怎麼在網站沒呼叫時自己送事件 → Meta Pixel 與 Conversions API 的〈Meta Pixel 在瀏覽器裡做的事〉；同一類模組依 User-Agent 攔下事件的機制 → 用 Playwright 擷取追蹤碼請求的〈擷取方式〉。