Pixel on Tarragonhttps://tarrragon.github.io/blog/tags/pixel/Recent content in Pixel on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Thu, 22 Oct 2026 00:00:00 +0800Vendor：各家追蹤碼的接入與驗證https://tarrragon.github.io/blog/devops/monitoring/vendors/Thu, 22 Oct 2026 00:00:00 +0800https://tarrragon.github.io/blog/devops/monitoring/vendors/<p>本資料夾的目的是實測各家追蹤系統的設計：每一家有一篇機制文，寫它在頁面或 App 裡做什麼、事件送到哪裡給誰用、資料在哪些環節會掉；有一頁實測頁，讓讀者在瀏覽器裡按按鈕觸發它、對照它實際送出的內容；Playwright 擷取紀錄把同樣的操作自動化並記下擷取時間，留給 vendor 改版之後比對。另有一篇跨三家的帳號治理文章，處理這些追蹤資產建在誰的帳號底下、權限怎麼分、委託代理商與轉手時怎麼移交。本站不是要用這些追蹤碼收集讀者資料，所以實測頁是獨立的頁面、只在讀者按下按鈕時載入。<a href="https://tarrragon.github.io/blog/devops/monitoring/06-commercial-comparison/" data-link-title="模組六：商業方案對照" data-link-desc="Sentry / Crashlytics / Datadog RUM / Mixpanel — 自架 vs 商業的功能和成本取捨">模組六：商業方案對照</a> 處理的是要不要買、什麼時候從自架換過去，跟本資料夾的分工是「選型」與「設計實測」，同一家 vendor 可以兩邊各有一篇。</p> <h2 id="篇目">篇目</h2> <table> <thead> <tr> <th>文章</th> <th>類型</th> <th>交付</th> </tr> </thead> <tbody> <tr> <td><a href="https://tarrragon.github.io/blog/devops/monitoring/vendors/meta-pixel-conversions-api/" data-link-title="Meta Pixel 與 Conversions API：廣告平台轉換追蹤的瀏覽器端與伺服器端" data-link-desc="Meta Pixel 在頁面上送出的標準事件與它的資料消費者、瀏覽器端事件被攔截的路徑、Conversions API 從伺服器補送同一批事件的必填欄位，以及兩路並送時以 event_id 去重與用 Test Events 驗證的方式">Meta Pixel 與 Conversions API</a></td> <td>機制文</td> <td>標準事件、被攔截的路徑、伺服器端補送、<code>event_id</code> 去重、Test Events</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/devops/monitoring/vendors/meta-pixel-lab/" data-link-title="Meta Pixel 實測頁：在瀏覽器裡觀察 fbq 呼叫、送出的請求與寫下的 cookie" data-link-desc="在這一頁按按鈕載入 Meta Pixel、送 PageView、ViewContent 與帶 eventID 的 Purchase，並用頁面上的面板對照每個呼叫送出的請求參數，以及 _fbp 與 fbclid 帶出的 _fbc cookie">Meta Pixel 實測頁</a></td> <td>實測頁</td> <td>按鈕觸發 PageView / ViewContent / Purchase、<code>_fbp</code> 與 <code>_fbc</code> 的產生、載入失敗態</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/devops/monitoring/vendors/google-tag-manager/" data-link-title="Google Tag Manager：追蹤碼的部署層、資料層約定與發布治理" data-link-desc="GTM 容器在頁面上承擔的部署責任、資料層作為前端與行銷之間的事件約定、預覽模式與版本發布的驗證方式、自訂 HTML 代碼帶來的安全與效能成本，以及伺服器端代碼管理改變的資料路徑">Google Tag Manager</a></td> <td>機制文</td> <td>資料層約定、預覽模式驗證、自訂 HTML 的治理、伺服器端代碼管理</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/devops/monitoring/vendors/google-tag-manager-lab/" data-link-title="Google Tag Manager 實測頁：在瀏覽器裡觀察容器載入、資料層事件與代碼送出的請求" data-link-desc="在這一頁按按鈕載入 GTM 容器、往資料層推 purchase 事件，並用頁面上的面板對照 window.dataLayer 的內容、容器載入的代碼與它們送出的請求">Google Tag Manager 實測頁</a></td> <td>實測頁</td> <td>容器載入、資料層內容、容器載入前推入的事件、代碼送出的請求</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/devops/monitoring/vendors/tracking-request-capture/" data-link-title="用 Playwright 擷取追蹤碼請求：擷取方式、記錄欄位與各次結果" data-link-desc="以 Playwright 操作 Meta Pixel 與 GTM 實測頁、記錄各家 script 實際送出的請求與 cookie 的方式，結果檔記錄的欄位與它們的用途，擷取用的測試帳號，以及每一次擷取觀察到的事件請求形式、cookie 與請求參數的對應、無頭瀏覽器下的差異與 script 自動送出的事件">用 Playwright 擷取追蹤碼請求</a></td> <td>擷取紀錄</td> <td>擷取方式、結果檔欄位、各次結果（標擷取時間與版本）</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/devops/monitoring/vendors/tracking-account-ownership/" data-link-title="追蹤資產的歸屬：Meta、GTM 與 GA4 的擁有層級、權限分級與移交方式" data-link-desc="Meta Pixel 的資料集、GTM 容器與 GA4 資源（property）各自屬於哪一層的擁有者，三家的權限怎麼分級，哪些資產能換到另一個擁有者底下，以及公司自營、委託代理商、換代理商與事業轉手時的歸屬安排">追蹤資產的歸屬</a></td> <td>帳號治理</td> <td>Meta 組合、GTM 帳戶與容器、GA4 帳戶與資源的擁有層級、權限分級、能否換擁有者、代理商與轉手時的歸屬</td> </tr> </tbody> </table> <p>擷取紀錄在第一次擷取完成之前維持 <code>draft: true</code>；2026-10-23 GTM 與 Meta Pixel 各完成一次擷取之後發布。</p> <h2 id="篇目的收錄條件">篇目的收錄條件</h2> <p>收進來的 vendor 要有一段自架方案沒有的機制可以寫：廣告平台的資料消費者是投放演算法、tag manager 把部署權交給行銷人員，這些在模組一到八的自架脈絡裡沒有對應物。只是功能清單不同的 vendor（另一家 error tracking）先在模組六的對照文補一列，累積到有獨立機制可講再開篇。</p> <h2 id="實測方式的決策紀錄">實測方式的決策紀錄</h2> <p>本站已經有一套自製的流量 beacon（<code>layouts/partials/custom_body.html</code>，說明在 <a href="https://tarrragon.github.io/blog/automation/02-analytics-beacon/" data-link-title="模組二：流量 beacon 實作" data-link-desc="把「頁面被看了就送一則事件、接收端寫進 Sheet」從零做到收到第一筆真實瀏覽紀錄時的完整實作">Automation 模組二：流量 beacon 實作</a>），設計上刻意不送完整 User-Agent、識別碼是隨機值、有 opt-out。全站加上第三方追蹤碼會推翻這組設計：讀者的瀏覽紀錄送到 Meta 與 Google、頁面多出 <code>_fbp</code>、<code>_ga</code> 這類 cookie、每一頁多載入第三方 script，歐盟讀者的部分還需要同意聲明。所以不全站嵌入，採用兩種實測方式並行（2026-10-22 決定）：</p> <ul> <li><strong>獨立實測頁</strong>：實作是 <code>layouts/shortcodes/vendor-lab.html</code>。頁面預設不注入任何第三方 script，讀者按下載入按鈕才注入；ID 由讀者填寫，預設值取 <code>hugo.toml</code> 的 <code>[params.vendorLab]</code>。<code>tests/vendor-lab.spec.ts</code> 把 vendor 網域攔下來回 stub，守住「按下之前零請求」與 ID 格式檢查。</li> <li><strong>本機 Playwright 擷取</strong>：<code>scripts/vendor-capture/capture.mjs</code> 操作實測頁並把請求、cookie、資料層寫成 JSON（<code>scripts/vendor-capture/results/</code>），每份結果帶擷取時間、瀏覽器版本、vendor script 的回應標頭與本體雜湊，因為 vendor 改版之後結果就不再適用。Meta Pixel 在無頭瀏覽器裡不送事件，擷取 Meta 要加 <code>--headed</code>（2026-10-23 實測）；腳本不改寫 User-Agent。</li> <li><strong>文章不寫測試 ID、實測頁不設預設值</strong>（2026-10-23 決定）：Pixel ID、容器 ID 與評估 ID 本來就寫在網頁原始碼裡，公開它們不會讓別人登入帳號；風險在反方向，任何人都能拿 ID 往帳號送事件，而 Meta 的資料集不能刪除，被灌入假事件之後只能另建一個。這組測試帳號只放實測資產、沒有投放廣告，被灌入假事件的影響只在測試報表上，所以接受這個風險：擷取結果的 JSON 保留原始 ID（repo 是公開的，ID 因此查得到），供日後比對。文章正文不寫實際值，理由是讀者照抄別人的 ID 去測試，事件會送進別人的帳號、也學不到用自己的 ID；文章只描述 ID 的格式與查詢位置。<code>hugo.toml</code> 的 <code>[params.vendorLab]</code> 維持空白，讀者在實測頁填自己的 ID。</li> <li><strong>測試帳號</strong>：Meta 商家資產管理組合「Tarragon Tech Notes」裡的資料集、GTM 帳戶 <code>vendor-lab-test</code>、GA4 帳戶 <code>vendor-lab-test</code>，都只放實測資產。建立時的檢查與預設值記在 <a href="https://tarrragon.github.io/blog/devops/monitoring/vendors/tracking-request-capture/" data-link-title="用 Playwright 擷取追蹤碼請求：擷取方式、記錄欄位與各次結果" data-link-desc="以 Playwright 操作 Meta Pixel 與 GTM 實測頁、記錄各家 script 實際送出的請求與 cookie 的方式，結果檔記錄的欄位與它們的用途，擷取用的測試帳號，以及每一次擷取觀察到的事件請求形式、cookie 與請求參數的對應、無頭瀏覽器下的差異與 script 自動送出的事件">用 Playwright 擷取追蹤碼請求</a> 的〈擷取用的測試帳號〉一節，為什麼另開擁有者記在 <a href="https://tarrragon.github.io/blog/devops/monitoring/vendors/tracking-account-ownership/" data-link-title="追蹤資產的歸屬：Meta、GTM 與 GA4 的擁有層級、權限分級與移交方式" data-link-desc="Meta Pixel 的資料集、GTM 容器與 GA4 資源（property）各自屬於哪一層的擁有者，三家的權限怎麼分級，哪些資產能換到另一個擁有者底下，以及公司自營、委託代理商、換代理商與事業轉手時的歸屬安排">追蹤資產的歸屬</a> 的〈本站實測資產的擁有者〉一節。</li> </ul> <p>Conversions API 這類伺服器端路徑在本站有一個限制：本站的接收端是 Apps Script，而 Apps Script 的 <code>doPost</code> 讀不到請求的 HTTP header（拿不到 IP 與 User-Agent），Meta 對網站事件要求的 <code>client_user_agent</code> 只能由前端放進 payload，這又回到送完整 User-Agent 的隱私取捨上，所以伺服器端目前只寫機制、不做實測。</p>本資料夾的目的是實測各家追蹤系統的設計：每一家有一篇機制文，寫它在頁面或 App 裡做什麼、事件送到哪裡給誰用、資料在哪些環節會掉；有一頁實測頁，讓讀者在瀏覽器裡按按鈕觸發它、對照它實際送出的內容；Playwright 擷取紀錄把同樣的操作自動化並記下擷取時間，留給 vendor 改版之後比對。另有一篇跨三家的帳號治理文章，處理這些追蹤資產建在誰的帳號底下、權限怎麼分、委託代理商與轉手時怎麼移交。本站不是要用這些追蹤碼收集讀者資料，所以實測頁是獨立的頁面、只在讀者按下按鈕時載入。模組六：商業方案對照 處理的是要不要買、什麼時候從自架換過去，跟本資料夾的分工是「選型」與「設計實測」，同一家 vendor 可以兩邊各有一篇。

篇目

文章 類型 交付
Meta Pixel 與 Conversions API 機制文 標準事件、被攔截的路徑、伺服器端補送、event_id 去重、Test Events
Meta Pixel 實測頁 實測頁 按鈕觸發 PageView / ViewContent / Purchase、_fbp 與 _fbc 的產生、載入失敗態
Google Tag Manager 機制文 資料層約定、預覽模式驗證、自訂 HTML 的治理、伺服器端代碼管理
Google Tag Manager 實測頁 實測頁 容器載入、資料層內容、容器載入前推入的事件、代碼送出的請求
用 Playwright 擷取追蹤碼請求 擷取紀錄 擷取方式、結果檔欄位、各次結果（標擷取時間與版本）
追蹤資產的歸屬 帳號治理 Meta 組合、GTM 帳戶與容器、GA4 帳戶與資源的擁有層級、權限分級、能否換擁有者、代理商與轉手時的歸屬

擷取紀錄在第一次擷取完成之前維持 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

項目 類型 前置條件 規模
GA4 網頁版的事件模型與 Measurement Protocol（機制文 + 實測頁） 主章 無 2
Mixpanel 的接入面（identify / alias、Ingestion API） 主章 無 1
實際送件驗證 Meta 管理員爭議對「唯一帳號已遺失」與「前承包商持有組合」兩種情形的處理結果；說明頁層級已查證（前承包商明列為可申請，唯一帳號遺失不在清單、送件要登入與組合有關聯的個人檔案），結果寫回追蹤資產的歸屬 案例 需有可申訴的實際組合 小
異源複核：另一個執行者（另一個工作階段或真人）用同一組 frame 獨立掃追蹤資產的歸屬與擷取紀錄，兩邊各自報數再並排 案例 有另一個執行者可用 小
查證三項本輪沒讀到原文的宣稱：Meta 合作夥伴存取裡「代理商提出要求、擁有者核准」那條路徑（team-access-management 已標未查證）；GA4 使用者群組的前提（同篇）；visitor-identity 寫 ITP 天數「曾經是三十天」（WebKit 文件裡 30 天屬於另一條規則，查證後修正） 跨模組 用瀏覽器讀 Meta 商家說明頁與 GA4 使用者管理頁 小
時效複核：三家帳號規則與 fbevents.js、gtm.js 會改版，半年後重讀追蹤資產的歸屬與擷取紀錄兩篇、三張追蹤碼知識卡（first-party-cookie、headless-browser、autocapture），用 rg "botblocking|_fbp|_ga\b|SubscribedButtonClick|管理員爭議|主機名稱篩選|ITP|autoConfig" content/ 找出其他引用處一併核對，並重跑一次擷取，比對雜湊與說明頁 案例 2027-04 之後 小
]]>