GA4 沒壞，GTM 也正常觸發，廣告轉換追蹤甚至比上週更完整。
直到行銷人員開啟偵錯畫面，發現某個結帳事件的頁面網址竟然長這樣：
工程說：「那是為了讓客服查單方便。」
行銷：「所以網址也可能被分析工具一起收走？」
網站沒有遭到入侵，會員資訊卻可能因為大家各自做了方便工作的設定，出現在不該出現的資料流裡。
資訊外傳不一定從駭客開始。有時候資料傳出去的路，是公司自己接出來的。
Google Analytics 對個資傳送有明確限制
Google Analytics 官方說明要求避免將可以識別個人的資訊（PII，Personally Identifiable Information）送進 GA；舉例包含電子郵件、個人行動電話號碼、身分證號碼等。官方也提醒，頁面網址、頁面標題、站內搜尋詞、事件自訂維度以及 UTM 參數，都可能意外帶入個資。Google Analytics：避免傳送 PII。
所以真正的問題不是「我們有沒有裝 GA4」，而是：我們實際送出了什麼資料？
五條容易漏掉的資料出口
| 資料出口 | 常見錯誤 | 應優先檢查 |
|---|---|---|
| 網頁 URL 與 query string | 成功頁網址包含 email=...、phone=...、完整會員編號 | GA4 page_location、歷史追蹤與伺服器存取日誌 |
| GTM dataLayer（資料層） | 前端為方便追蹤，把完整會員資料物件推到 dataLayer | 所有觸發器與變數實際送到哪些標籤 |
| CRM 與試算表匯出 | 行銷同仁將客戶清單傳給外包商、共用雲端連結無期限 | 權限、下載分享歷史、外部收件人 |
| 客服與自動化串接 | 客服對話、訂單備註包含不必要的敏感欄位 | API 欄位對照、可存取人員、保存期間 |
| 外部行銷工具 | 使用者分群、雜湊資料、跨平台同步目的不明確 | 資料類型、處理目的、契約和可退出機制 |
這些是可能的風險情境，不是宣稱所有品牌或工具都會預設犯同樣的錯。每一項都必須以站上實際追蹤流量、設定與資料紀錄核實。
圖解：追蹤正常不代表個資沒有進入不適當的目的地
去識別化實務查核拆解（以典型年營收破億之品牌電商結帳與追蹤鏈路為例）
在實際協助年營收破億的電商品牌進行資料流與追蹤參數查核時，我們常在結帳與行銷串接鏈路上攔截到以下三個具體的技術破口：
- 結帳完成頁 URL 參數外洩明碼個資： 訂單完成跳轉至結帳感謝頁（
/checkout/thank-you）時，URL query string 夾帶了?order_id=2026102401&phone=0912345678&[email protected]。透過 Chrome DevTools Network 檢視發往 Google Analytics 的g/collect封包時，發現dl（Document Location）參數完整收錄該包含電話與 Email 的網址；同時，頁面載入的所有第三方廣告腳本在發送請求時，HTTP Referer 亦將明碼個資直接外洩給外部網域。 - 前端 GTM dataLayer 明碼全域暴露： 前端於交易完成時呼叫
window.dataLayer.push({ event: 'purchase', ecommerce: { ... }, customer: { name: '林小明', phone: '0912345678', address: '台北市信義區忠孝東路...' } })。這些敏感個資未經 SHA-256 雜湊即直接推入全域物件，被頁面上共用的第三方廣告 Pixel（包含 Meta Pixel、LINE Tag 等）無差別讀取並打包回傳。 - 後端批次匯出與 Webhook 缺乏權限收斂： 為配合外部 EDM 廠商、簡訊商與第三方物流發貨，系統後端每日排程自動匯出包含完整顧客姓名、地址、身分證字號與消費紀錄的 CSV 清冊，或透過 Webhook 全量推播。然而這些串接缺乏「欄位最小化」設計，且外部廠商使用的 API Token 長期未設定存取範圍限制（Scope）與定期輪替機制。
改善這類破口不能只靠在 GA4 後台將欄位隱藏，而必須從前端追蹤與後端資料管線徹底收斂：結帳感謝頁改以無意義的隨機 Token 或 Session 驗證，不在網址傳遞個資；前端 dataLayer 嚴格過濾個資欄位；後端匯出與 Webhook 則落實欄位最小化與 Token 權限隔離。
不會寫程式，行銷主管怎麼查？
不用先成為工程師。你只需要能指出每個工具的用途、資料來源及負責人：
- 列工具： 91APP／SHOPLINE 等購物車、GA4、GTM、廣告像素、CRM、電子報、物流、客服、LINE 與自動化服務。
- 列資料： 姓名、信箱、電話、訂單、消費金額、會員識別碼、行為事件、客服紀錄等。
- 列路徑： 資料由何處產生，傳到哪裡，誰能查看、下載、刪除。
- 核對目的： 必須清楚分辨履行交易、客服、統計、行銷利用及其他目的，不能一張「同意分析」概括所有行為。
- 要求測試： 請技術窗口在測試環境用虛構測試帳號實際檢查網路請求、GTM Preview（預覽）、GA4 DebugView（偵錯檢視）等相關資訊；不要在錄影或截圖中暴露真實顧客資料。
- 留下紀錄： 截圖、檢查日期、問題、修正負責人、複驗結果與仍待判定項目。
台灣個資法要看的，不只資料有沒有送進 GA4
台灣《個資法》第 8 條、第 9 條涉及告知義務，第 19 條涉及非公務機關蒐集處理個資的法定事由，第 20 條涉及利用範圍與行銷拒絕等事項。即使某個追蹤設定沒有違反 GA4 平台政策，也不代表已自然滿足所有台灣法令或契約要求；反過來，GA4 平台政策違規，也不能不查事實就自動推定涉及特定法條的違法。《個人資料保護法》。
使用第三方行銷供應商還可能涉及委外資料處理。依實際契約關係，有必要另看 施行細則第 8 條的委外監督，把資料流、委託範圍和監督紀錄接起來。
行銷／工程對帳表（建議格式）
| 欄位 | 範例（虛構） |
|---|---|
| 系統與事件 | 網站完成購買事件 |
| 負責窗口 | 行銷 A + 工程 B |
| 原始資料 | 訂單金額、幣別、隨機交易識別碼 |
| 傳輸去向 | GA4 分析屬性 |
| 不可包含 | 姓名、email、電話等可直接識別資訊 |
| 已確認 | 測試事件沒有包含直接識別個資 |
| 待確認 | 其他自訂標籤是否把會員屬性同步出去 |
| 複驗 | 下次 GTM 發布前重新核對 |
這張表不能用「有制度」代替真實流量測試。 有些資料是否屬於可識別個資，仍要依使用情境及實際可識別性判斷；不要只憑欄位名稱推定絕對安全。
三個常見誤解
「我把 email 做雜湊，就一定不算個資？」 不一定。雜湊資訊是否仍可連結到個人、能否被他方比對，需依資料與實際識別風險判斷；也應遵守接收平台政策及相關法規。
「GTM 是 Google 的工具，所有標籤就都合規？」 GTM 是管理與觸發標籤的工具，實際送出哪些資料，仍取決於容器設定、標籤及網站程式。
「我們有寫隱私權政策，就不用檢查實際傳輸？」 不對。公告內容與實際執行應一致，還要核對必要的合法依據、資料接收者與保護措施。
如果你是企業內部行銷或法遵窗口，先把資料流畫出來，再與資訊團隊確認缺口。企業若需要更完整的品牌端權限、委外與證據查核，可以了解 個資健診服務內容；服務範圍不等於代替資安滲透測試或特定法律意見。
資料來源：Google Analytics 避免傳送 PII、Google Analytics 資料使用政策、台灣個資法、施行細則。
同主題延伸閱讀：個資法第 8 條怎麼告知？電商蒐集會員資料的六項要求與查核表、個資法第 20 條怎麼判斷？目的外利用、行銷拒絕與電商案例。