GTM 的「代碼類型」是什麼?為什麼不能只看成一段追蹤碼
這裡的 GTM 指 Google Tag Manager(GTM),也就是 Google 代碼管理工具;不討論 Go-To-Market strategy、GTM Stores 或其他品牌名稱。GTM 代碼類型指的是在容器裡選擇哪一種代碼範本或自訂方式,用來把特定事件、轉換或第三方追蹤資料送到對應平台。
很多人第一次接觸 GTM,會把它想成「把一段追蹤碼貼到網站」。這個想法只對了一半。GTM 真正的價值,在於把「要送什麼資料」、「什麼時候送」、「送哪些值」分開管理。我的判斷是,只要這三件事沒分清楚,後面做 GA4 事件、Google Ads 轉換或 Meta Pixel,都很容易變成有裝代碼但資料不能用。
| 組成 | 負責的事情 | 例子 |
|---|---|---|
| 代碼 | 決定要把資料送到哪個平台,以及用哪種格式送出 | GA4 事件代碼、Google Ads 轉換追蹤、Meta Pixel、自訂 HTML |
| 觸發條件 | 決定代碼在什麼情況下執行 | 所有頁面、表單送出、按鈕點擊、購買完成頁 |
| 變數 | 決定代碼執行時要帶入哪些值 | 頁面 URL、按鈕文字、訂單金額、商品 ID、會員狀態 |
代碼、觸發條件、變數的關係
以「點擊 LINE 諮詢按鈕」來看,代碼可能是 GA4 事件代碼,也可能是 LINE Tag 或 Meta Pixel。觸發條件是使用者點了特定 LINE 按鈕。變數則可能包含按鈕文字、所在頁面、服務類型或來源活動。
如果只設定代碼,沒有正確的觸發條件,事件可能在每個頁面都送出。如果觸發條件對了,但變數沒整理好,報表裡只會看到一堆難以判讀的事件。這也是為什麼 GTM 代碼類型不能單獨看,它必須和觸發條件、變數一起設計。
GTM 代碼類型和網站原始碼的差別
網站原始碼通常由工程師維護,GTM 則讓行銷、分析與技術窗口在同一個容器裡管理追蹤代碼。多數 GA4 事件、廣告轉換、再行銷與第三方像素,都可以透過 GTM 集中部署。
但 GTM 不能取代所有網站程式碼。像訂單金額、商品明細、會員等級、表單類型這類商業資料,如果網站本身沒有把資料準備好,GTM 很難憑空取得。需要精準事件追蹤時,通常仍要工程端配合 dataLayer。
GTM 內建支援哪些常見代碼類型?
GTM 內建常見代碼類型以 Google 生態為主,包含 Google Tag、GA4 事件、Google Ads 轉換追蹤、Google Ads 再行銷、Conversion Linker 與 Floodlight;第三方工具則多半要靠自訂 HTML、社群平台整合或自訂範本處理。
| 代碼類型 | 主要用途 | 適合情境 | 注意事項 |
|---|---|---|---|
| Google Tag / GA4 事件代碼 | 送出 GA4 頁面瀏覽、事件與參數 | 追蹤瀏覽、點擊、表單、下載、互動與轉換事件 | 事件名稱與參數要有命名規則,避免報表混亂 |
| Google Ads 轉換追蹤 | 回傳廣告轉換 | 詢價、註冊、購買、預約、表單送出 | 需確認 conversion ID、conversion label 與觸發條件 |
| Google Ads 再行銷 | 建立廣告受眾 | 瀏覽過特定頁面、加入購物車、看過方案頁的使用者 | 需搭配隱私同意與廣告用途揭露 |
| Conversion Linker | 協助保存廣告點擊資訊 | 使用 Google Ads 轉換追蹤或 Floodlight 時 | 通常應在所有頁面觸發,並與轉換追蹤一起驗收 |
| Floodlight | 企業級廣告活動與轉換追蹤 | 使用 Campaign Manager 360 或大型廣告投放架構 | 設定通常牽涉媒體代理商與廣告技術窗口 |
官方的 Google Tag Manager 說明中心 會持續更新產品介面與支援項目,實作前仍應以容器內可選的最新範本為準。
Google Tag / GA4 事件代碼
Google Tag 與 GA4 事件代碼是做網站分析時最常用的 GTM 代碼。Google Tag 負責建立 Google 量測基礎,GA4 事件代碼則負責把使用者行為送到 GA4,例如點擊、搜尋、表單送出、影片互動、加入購物車或完成購買。
如果需求是 GA4 事件追蹤,優先使用 GA4 相關代碼,而不是先貼一段自訂 HTML。站內可搭配 GA4 安裝設定、GA4 事件追蹤 與 GA4 轉換設定 這類內容一起規劃。
Google Ads 轉換追蹤代碼
Google Ads 轉換追蹤代碼用來告訴 Google Ads:某次廣告點擊後,使用者完成了表單、購買、註冊、來電或其他重要行為。它適合追蹤廣告成效,不等同於 GA4 的一般事件分析。
常見錯誤是把 GA4 事件和 Google Ads 轉換追蹤混成同一件事。GA4 偏向分析使用者行為,Google Ads 轉換追蹤偏向廣告歸因與投放最佳化。兩者可以互相支援,但代碼類型、驗收工具與資料用途不同。
Google Ads 再行銷代碼
Google Ads 再行銷代碼用來建立受眾,例如瀏覽過產品頁、到過結帳頁但沒有購買、看過服務方案頁的使用者。它的目的不是記錄一次轉換,而是讓廣告平台知道哪些使用者符合再行銷條件。
2026 年做再行銷代碼時,不能只問「有沒有觸發」,還要問「是否符合隱私同意」。廣告相關代碼通常會受 ad_storage、ad_user_data、ad_personalization 這類同意狀態影響,這部分可延伸檢查 GA4 隱私設定。
Conversion Linker
Conversion Linker 用來協助保存廣告點擊 ID,讓後續轉換能更穩定地和廣告點擊歸因。只要網站有使用 Google Ads 轉換追蹤或 Floodlight,通常都應檢查是否需要 Conversion Linker。
實務上我會把 Conversion Linker 視為 Google 廣告追蹤的基礎配套,而不是可有可無的小工具。少了它,轉換代碼可能仍會觸發,但歸因品質可能受影響。
Floodlight 代碼
Floodlight 代碼主要用在 Campaign Manager 360 等企業級廣告追蹤架構,常見於大型品牌、跨媒體投放或代理商管理的廣告帳戶。它可以追蹤活動、轉換與受眾,但設定邏輯通常比一般 Google Ads 轉換追蹤更複雜。
若網站只是一般中小型投放,通常先處理 GA4、Google Ads 轉換與 Conversion Linker 就夠。Floodlight 應在廣告帳戶、媒體代理商與資料驗收流程明確時再導入。
第三方追蹤工具在 GTM 裡通常用哪種代碼類型?
Meta Pixel、LINE Tag、TikTok Pixel、Hotjar、Clarity、客服外掛與 CRM 追蹤,多數會透過自訂 HTML、社群平台整合或自訂範本放進 GTM;選擇時要同時檢查重複觸發、載入速度、隱私同意與事件命名。
| 第三方工具 | 常見部署方式 | 適合用途 | 主要風險 |
|---|---|---|---|
| Meta Pixel / Facebook Pixel | 自訂 HTML、平台整合、社群像素範本 | 廣告轉換、再行銷、事件受眾 | 重複觸發、事件名稱不一致、同意狀態未控管 |
| LINE Tag | 自訂 HTML 或平台提供的追蹤碼 | LINE 廣告轉換、加入好友、諮詢按鈕、表單送出 | 多頁觸發錯誤、活動代碼混用、歸因驗收不足 |
| Hotjar / Clarity | 自訂 HTML 或官方安裝片段 | 熱圖、錄影、行為分析 | 載入速度、隱私揭露、敏感欄位遮蔽 |
| 客服外掛 / CRM 追蹤 | 自訂 HTML、Webhook 事件、表單事件整合 | 客服啟動、名單來源、表單提交 | 與網站既有程式衝突、表單送出判斷不準 |
Meta Pixel / Facebook Pixel
Meta Pixel 常用於 Facebook 與 Instagram 廣告的轉換追蹤、再行銷與事件最佳化。透過 GTM 安裝時,多數情況會使用自訂 HTML 或既有社群像素範本,依序設定 PageView、Lead、Purchase、AddToCart 等事件。
Meta Pixel 最怕重複觸發。若網站原本已透過外掛或網站後台安裝 Pixel,又在 GTM 再裝一次,同一個轉換可能被送出兩次。上線前一定要確認事件管理工具中的事件數量、來源與參數。
LINE Tag 與台灣常見廣告追蹤碼
台灣網站常見的情境包含 LINE 諮詢、加入好友、表單送出、預約完成與購物車事件。LINE Tag 可以透過 GTM 管理,但要先釐清每個事件代表什麼商業行為,不能把所有 LINE 按鈕都當成同一個轉換。
我的判斷是,台灣站做 LINE 追蹤時,最需要管理的是「事件定義」而不是「代碼貼上」。例如 LINE 諮詢按鈕點擊可以是微轉換,表單送出才是主要轉換,兩者應分開命名與驗收。
Hotjar、Clarity、客服外掛與行為分析工具
Hotjar、Microsoft Clarity、客服外掛與行為分析工具常用自訂 HTML 放入 GTM。它們通常在所有頁面或特定頁面觸發,用來觀察使用者互動、熱圖、錄影或客服啟動。
這類工具不只要看能不能安裝,還要看是否拖慢頁面、是否收集到不該收集的欄位、是否需要在隱私權政策中揭露。尤其是表單、會員中心、結帳頁,應先確認遮蔽與同意設定。
自訂 HTML、自訂圖片與自訂範本各適合什麼情況?
自訂 HTML 適合需要執行 JavaScript 的第三方追蹤碼,自訂圖片適合簡單像素請求,自訂範本適合團隊重複使用與風險控管;內建範本能處理時應優先使用內建範本。
| 自訂類型 | 用途 | 什麼時候用 | 注意事項 |
|---|---|---|---|
| 自訂 HTML | 執行第三方 script、像素或特殊追蹤邏輯 | 沒有內建範本,且工具提供 JavaScript 安裝碼 | 需控管權限、效能、安全與重複觸發 |
| 自訂圖片 | 送出一個不需要 JavaScript 的 pixel request | 只需呼叫追蹤網址,不需要讀取頁面互動 | 能傳的資料有限,複雜事件不適合 |
| 自訂範本 | 把常用代碼做成可重複使用的受控元件 | 團隊常重複部署同一類追蹤,且需要權限限制 | 需有人維護範本、測試欄位與權限設定 |
Google Developers 對 GTM 自訂範本 的說明指出,自訂範本使用權限導向與 sandboxed JavaScript,目的就是降低直接貼自訂 HTML 的風險。
自訂 HTML:彈性最高,但風險也最高
自訂 HTML 可以貼入第三方 script、像素追蹤、特殊事件邏輯或外部工具要求的安裝碼。它的彈性最高,因為可以執行 JavaScript,也因此風險最高。
使用自訂 HTML 前,至少要確認四件事:代碼來源可信、觸發頁面合理、不會重複送出事件、不會阻塞關鍵頁面載入。若是結帳頁、會員頁或表單頁,更要確認是否碰到個人資料與隱私同意。
自訂圖片:適合簡單像素請求
自訂圖片適合只需要送出一個追蹤請求的情境,例如某些廣告平台提供的 image pixel。它不需要執行 JavaScript,結構比較單純。
限制也很明顯。自訂圖片不適合複雜互動、動態參數很多、需要讀取頁面狀態或執行回呼的場景。若要送出訂單明細、商品陣列或會員狀態,通常要改用 GA4 事件、平台指定代碼或搭配 dataLayer。
自訂範本:適合團隊重複使用與風險控管
自訂範本適合把重複使用的追蹤邏輯變成固定欄位,讓使用者填入 ID、事件名稱或參數,而不是每次都貼一段未審核的 script。這對多人協作的行銷與技術團隊特別有價值。
我的判斷是,只要同一類第三方代碼會在多個網站、多個活動或多個國家版本反覆使用,就應考慮自訂範本。它前期比自訂 HTML 麻煩,但長期較容易控管權限、欄位與版本。
dataLayer 和 GTM 代碼類型有什麼關係?
dataLayer 不是 GTM 代碼類型,而是把事件資料傳給 GTM 的資料層;當 GA4、廣告轉換或電商事件需要訂單金額、商品 ID、會員狀態等資訊時,通常要靠 dataLayer 提供資料。
只靠 GTM 的點擊偵測,可以處理簡單互動,例如點了哪個按鈕、在哪個頁面送出表單。但對電商與會員網站來說,真正重要的資料常不在畫面文字裡,而是在網站系統後端。
什麼情況只靠 GTM 點擊偵測不夠?
如果事件只需要知道「使用者點了 LINE 諮詢按鈕」,GTM 點擊觸發通常夠用。但如果事件要知道表單類型、客戶身份、服務方案、商品 ID、訂單金額或優惠券,單靠點擊偵測通常不夠。
例如「加入購物車」不只是一個按鈕點擊。分析端通常想知道加入的是哪個商品、價格多少、數量多少、幣別是什麼。若沒有 dataLayer,GA4 事件可能只能收到 add_to_cart,卻不知道是哪個商品進了購物車。
電商事件通常需要哪些 dataLayer 資料?
電商事件常見 dataLayer 資料包含 item_id、item_name、value、currency、transaction_id、items、quantity、coupon 等。完成購買時,transaction_id 特別重要,因為它可以協助檢查重複交易與訂單對帳。
做 GA4 電商追蹤 時,GTM 代碼類型只是一半,dataLayer 規格才是另一半。若資料層設計不穩,後面的 GA4 報表、Google Ads 轉換價值與再行銷受眾都會受到影響。
不同代碼類型應該怎麼選?一張決策表
選擇 GTM 代碼類型時,先看追蹤目標:GA4 分析用 GA4 事件,Google Ads 成效用轉換追蹤與 Conversion Linker,第三方像素多用自訂 HTML 或範本,複雜商業資料則需要 dataLayer。
| 追蹤需求 | 建議代碼類型 | 需要搭配 | 判斷重點 |
|---|---|---|---|
| 頁面瀏覽與一般互動分析 | Google Tag / GA4 事件代碼 | GA4 事件命名、事件參數 | 是否能在 GA4 報表中清楚解讀 |
| 表單送出、註冊、購買等廣告轉換 | Google Ads 轉換追蹤 | Conversion Linker、轉換 ID 與 label | 是否對應正確廣告帳戶與轉換動作 |
| 再行銷受眾 | Google Ads 再行銷、Meta Pixel、LINE Tag | Consent Mode、受眾規則 | 是否符合隱私同意與受眾用途 |
| 第三方行為分析或客服工具 | 自訂 HTML 或自訂範本 | 觸發頁面、載入順序、隱私揭露 | 是否影響速度或收集敏感資訊 |
| 電商訂單、商品、會員事件 | GA4 事件代碼搭配 dataLayer | dataLayer 變數、事件參數、交易 ID | 網站是否已提供完整事件資料 |
| 簡單 pixel request | 自訂圖片 | 追蹤網址、必要參數 | 是否真的不需要 JavaScript |
如果是 GA4 事件追蹤
GA4 事件追蹤優先使用 Google Tag 與 GA4 事件相關代碼。事件名稱應先規劃,不要每次有人提出需求就臨時命名,否則同一個表單送出可能出現 form_submit、lead、contact_send 等多種名稱。
事件參數也要控制。常見參數包含 button_text、form_name、page_location、content_type、value、currency。可參考站內 GA4 事件追蹤 的命名邏輯,避免 GA4 裡出現看得懂但不能比較的資料。
如果是廣告轉換或再行銷
廣告轉換要依平台選代碼。Google Ads 用 Google Ads 轉換追蹤,Meta 用 Meta Pixel,LINE 廣告用 LINE Tag,其他平台則依官方提供的像素、script 或範本處理。
再行銷代碼要特別確認同意狀態。使用者沒有同意廣告用途時,不應無條件觸發所有廣告與再行銷代碼。Consent Mode 不只是技術設定,也會影響資料收集與平台建模方式。
如果要傳送訂單或會員資料
訂單、會員與商品資料通常需要 dataLayer。GTM 可以讀取 dataLayer 變數,再由 GA4 事件、Google Ads 轉換或第三方像素送出,但前提是網站已經在正確時機把資料推到 dataLayer。
例如完成購買事件至少應檢查訂單編號、金額、幣別與商品資料。若 transaction_id 缺漏,後續驗收重複訂單會很痛苦。若 value 錯誤,廣告投放可能拿到錯誤的轉換價值。
如果是一次性第三方工具安裝
一次性第三方工具常用自訂 HTML,但不能只把官方安裝碼貼進去就發布。要先確認它要放在所有頁面還是特定頁面、是否需要早於其他代碼觸發、是否會載入外部 script,以及是否有隱私揭露需求。
若工具只是短期測試,建議在 GTM 版本名稱與備註寫清楚用途、開始日期與負責人。這樣之後要清理容器時,不會留下沒人敢刪的舊追蹤碼。
使用 GTM 代碼類型時的驗收與風險控管
GTM 代碼發布前要用 Preview mode、Tag Assistant、GA4 DebugView、廣告平台事件工具與 Consent Mode 檢查;發布後還要看實際報表、重複事件、權限與版本回復。
| 階段 | 檢查項目 | 工具 | 通過標準 |
|---|---|---|---|
| 發布前 | 代碼是否在正確頁面與行為觸發 | Preview mode、Tag Assistant | 該觸發時觸發,不該觸發時不觸發 |
| 發布前 | 事件名稱與參數是否正確 | GA4 DebugView、即時報表 | 事件與參數能在 GA4 看到並能解讀 |
| 發布後 | 廣告平台是否收到事件 | Google Ads、Meta、LINE 等事件管理工具 | 平台顯示有效事件,且沒有明顯重複 |
| 治理 | 同意狀態、權限與版本 | Consent Overview、版本管理、使用者權限 | 代碼有負責人、可回復、同意設定清楚 |
Google 官方對 Tag Manager Consent Mode 支援 的說明提到,GTM 可透過 Consent Initialization、代碼同意設定與 Consent Overview 管理代碼如何回應同意狀態。
發布前:用 Preview 和 Tag Assistant 檢查觸發
發布前先開 GTM Preview mode,實際走一次使用者流程,例如瀏覽頁面、點擊 LINE 諮詢、送出表單、加入購物車或完成購買。每一步都要看哪些代碼觸發、哪些代碼沒有觸發。
Tag Assistant 可協助檢查 Google 相關代碼是否載入與觸發。重點不是看到綠色狀態就結束,而是要對照需求:這個頁面該不該觸發?這個事件該不該帶參數?同一個動作是否送出兩次?
發布後:用 GA4 DebugView 與廣告平台事件管理工具驗證
GA4 事件上線後,可用 GA4 DebugView 或即時報表確認事件進站情況。若是廣告轉換,還要進 Google Ads、Meta 或 LINE 的事件管理工具確認平台端是否收到事件。
發布後的驗收不應只看一次。部分平台事件會有處理時間,廣告轉換也可能因同意狀態、瀏覽器限制或歸因條件而有落差。實務上至少要同時看觸發紀錄、平台事件狀態與隔天報表趨勢。
隱私同意:廣告與分析代碼不應無條件全部觸發
Consent Mode 會影響 Google Analytics、Google Ads、Floodlight,以及部分會讀寫 cookie 或做廣告用途的第三方代碼。常見同意類型包含 analytics_storage、ad_storage、ad_user_data、ad_personalization。
若網站有隱私同意橫幅,GTM 代碼應配合同意狀態,而不是一進站就全部觸發。這對再行銷、廣告轉換、使用者資料傳送尤其重要。站內 GA4 隱私設定 可作為延伸檢查方向。
權限與版本:誰能發布、誰能回復
GTM 容器應限制發布權限。行銷同仁可以建立草稿,技術或資料負責人負責審核與發布,會比所有人都能直接上線穩定很多。
每次發布都要寫清楚版本名稱與變更內容,例如「新增 LINE 諮詢事件」、「修正 GA4 purchase value」、「移除舊 Hotjar 代碼」。我的判斷是,GTM 版本紀錄寫得越清楚,出問題時越快回復,也越能避免容器變成追蹤碼垃圾場。
本文不處理的 GTM 問題
這一頁只處理 Google Tag Manager 支援哪些代碼類型,以及各自適合怎麼使用;Go-To-Market、完整安裝教學、GA4 報表操作、CRM 策略與平台後台逐步設定都不在這個範圍。
- 不討論 Go-To-Market strategy、HR 術語、CRM 策略或 GTM Stores 等縮寫歧義。
- 不展開完整 GTM 帳戶建立、容器安裝或網站後台操作流程。
- 不把 GA4 報表教學放進主軸,只處理 GA4 與 GTM 代碼類型的關係。
- 不把 Shopify、SHOPLINE、WordPress 寫成平台安裝教學,只回答代碼類型判斷。
- 不建議未經同意就觸發所有廣告、分析與第三方追蹤代碼。
收斂成選擇原則會更實用:Google 生態先看內建範本,第三方工具再看自訂 HTML 或範本,複雜事件先確認 dataLayer,任何代碼發布前都要完成驗收。
GTM 是 Google Tag Manager 還是 Go-To-Market?
在網站追蹤與 SEO 分析情境中,GTM 通常指 Google Tag Manager,也就是 Google 代碼管理工具。Go-To-Market 也會縮寫成 GTM,但那是市場進入策略,和網站追蹤代碼類型不是同一個主題。
GTM 支援哪些代碼類型?
GTM 常見代碼類型包含 Google Tag、GA4 事件代碼、Google Ads 轉換追蹤、Google Ads 再行銷、Conversion Linker、Floodlight、自訂 HTML、自訂圖片與自訂範本。第三方工具如 Meta Pixel、LINE Tag、Hotjar、Clarity 則常透過自訂 HTML、平台範本或整合方式部署。
GTM 的代碼和 GA4 的事件有什麼差別?
GTM 的代碼是部署與觸發機制,GA4 的事件是送到 GA4 的資料內容。GTM 負責在正確時間執行 GA4 事件代碼,GA4 則接收事件名稱與參數,讓你在報表中分析使用者行為。
GA4 事件追蹤應該用哪一種 GTM 代碼?
GA4 事件追蹤應優先使用 Google Tag 與 GA4 事件相關代碼。若事件包含訂單、商品或會員資料,通常還要搭配 dataLayer 與 GTM 變數,把正確參數送進 GA4。
Google Ads 轉換追蹤和再行銷代碼可以都放在 GTM 嗎?
可以。Google Ads 轉換追蹤與再行銷代碼都能透過 GTM 管理。轉換追蹤用來回傳表單、購買、註冊等成效事件,再行銷代碼用來建立受眾。若使用 Google Ads 轉換追蹤,也應檢查 Conversion Linker 與同意狀態設定。
Meta Pixel 或 LINE Tag 可以用 GTM 安裝嗎?
可以。Meta Pixel 與 LINE Tag 常透過 GTM 的自訂 HTML、社群像素範本或平台整合方式安裝。設定時要特別檢查是否重複觸發、事件名稱是否一致、轉換事件是否對應正確頁面或按鈕,以及是否符合隱私同意。
什麼情況需要用 GTM 自訂 HTML?
當內建範本無法處理,且第三方工具提供的是 JavaScript 安裝碼時,通常會使用自訂 HTML。常見例子包含部分廣告像素、行為分析工具、客服外掛與特殊事件追蹤。使用前要確認代碼來源、觸發頁面、載入影響與安全風險。
自訂 HTML 會不會影響網站速度或安全?
有可能。自訂 HTML 可以載入外部 script,也可能執行會影響頁面的 JavaScript。若代碼來源不明、載入過重、在所有頁面無差別觸發,可能影響速度、安全與資料品質。較成熟的團隊會限制發布權限,並把重複使用的代碼改成自訂範本。
dataLayer 是 GTM 的代碼類型嗎?
dataLayer 不是 GTM 代碼類型。它是網站提供給 GTM 的資料層,用來傳送事件名稱、商品資料、訂單金額、會員狀態等資訊。GTM 可以讀取 dataLayer,再用 GA4 事件、廣告轉換或第三方代碼把資料送出去。
GTM 代碼發布前要怎麼確認有沒有正常觸發?
發布前應使用 GTM Preview mode 和 Tag Assistant 檢查觸發條件,再用 GA4 DebugView 或廣告平台事件工具確認事件是否送達。驗收時要看三件事:該觸發時有沒有觸發、不該觸發時有沒有誤觸發、事件參數是否正確。
Consent Mode 會影響哪些 GTM 代碼?
Consent Mode 會影響 Google Analytics、Google Ads、Floodlight,以及其他會讀寫 cookie 或涉及廣告、分析用途的代碼。常見同意類型包含 analytics_storage、ad_storage、ad_user_data、ad_personalization。廣告與分析代碼不應在未確認同意狀態時無條件全部觸發。
Shopify、SHOPLINE、WordPress 都能安裝 GTM 嗎?
多數 Shopify、SHOPLINE、WordPress 網站都可以安裝 GTM,但實際方式取決於方案權限、佈景主題、外掛與網站後台設定。平台安裝只是第一步,後續仍要依需求選擇 GA4 事件、Google Ads 轉換、第三方像素、自訂 HTML 或 dataLayer。
以官方文件、實際設定與量測結果整理 SEO 數據、網站追蹤與分析方法,並標示資料來源與判讀限制。