導入 GTM 工作流程

大家好，我是 applemint 的 Eric。今天將和大家分享「如何導入 GTM」。

GTM 最重要的工作，在於透過網頁介面，進行代碼管理，因此在 GTM 導入過程中，理解管理架構，比理解代碼本身還要重要，但也往往都是大多數的人很常忽略的一環。

為什麼要使用 GTM

先講結論，因為 GTM 簡單又方便。

GTM 的學習門檻極低，零工程背景的人都可以在 1.5 個小時內掌握 GTM 的運作方式，並具備安裝代碼的基本能力。除了預設的代碼範本已經包含了 Google 自家的行銷工具外，去年推出自訂代碼範本後，現在安裝 Facebook 代碼也能透過範本直接完成，可以說完全是透過使用者介面進行安裝代碼的過程。

GTM 如何方便？以大家最常使用的 Google Analytics 為例。從 2018 年開始，Google Analytics 逐步將通用 Google Analytics 代碼 (analytics.js) 轉換為 gtag.js 的全域網站代碼。這個轉換，對於使用 GTM 埋設 GA 的人來說，並不需要理會，因為 Google 會自己逐步完成這個轉換。

你也可以透過 GTM 驗證 Search Console 的網站持有權，而不需要設定網域名稱的位址紀錄。你可以透過 GTM 的介面，直接設定 Google Optimize，而不需要更改網站的原始碼。換句話說，你可以透過 GTM 整合 Google 自家的所有服務。

此外，GTM 提供了版本控制的功能，可以在代碼錯誤發生時，回到前一個版本，同時卻不會影響到整個網站的其他功能。

如何規劃導入 GTM

許多企業網站在建置初期，會直接將追蹤碼加入網站中，因此在將服務移轉至 GTM 之前，勢必會需要進行內部溝通，調整網站頁面結構。這裡就針對公司官網的利害關係人，探討應該要從哪裡開始導入 GTM：

工程師

對工程師而言，開放使用 GTM 的優點，是不再需要隨時應付行銷人員的需求（「我想要埋這個 code」、「我想要做事件追蹤」、「我想做使用者分析」等），透過提供 GTM 的權限，可以讓行銷人員自行解決基本的代碼安裝需求。

然而，開放 GTM 給不具備網站運作基礎的人，還是有可能造成無法預期的錯誤的，因此我們曾經接觸過客戶總公司的工程師，不願意開放 GTM 權限，甚至不願意改用 GTM 的情形。

針對這樣的擔憂，實作上可以透過限制權限的方式，達到基本的控管。

一般來說，我們會建議工程師可以掌握最終發布的權限，但是賦予行銷人員編輯的能力。這樣子由工程師做最後的程式碼審查 (code review)，就可以在降低錯誤機率的情況下，減少工程師花費的時間。

在首次將代碼移轉至 GTM 的過程中，工程師扮演相當重要的角色，因為在安裝 GTM 移除舊代碼的過程中，需要由工程師協助編輯網站的原始碼。此外，雖然 GTM 提供了行銷人員較大的彈性，但是當網站需要資料層變數等進階資料時，仍然建議請工程師協助設置。

行銷人員

對行銷人員而言，開放 GTM 的優點，在於可以提升自己對網站掌控的能力，以配合行銷活動的需求，或是提升網站的分析能力等。但是相對的，如果沒有做好代碼管理，那麼這些代碼，很有可能都是拖慢頁面載入速度的兇手。

因此，雖然前面提到，即便是沒有工程背景的人，也可以在 1.5 小時內快速學會如何安裝代碼，但是我個人建議在學會如何操作 GTM 後，行銷人員應該更進一步了解基礎的 CSS 選擇器 (CSS Selector) 與 JavaScript，才能夠更進一步發揮 GTM 的價值。

專案管理人員

對於規模較小的公司來說，這個職務可能也會由行銷人員兼任。

相對於上述行銷人員偏重「執行」的職務，專案管理人員在 GTM 導入中，扮演的角色在於制定分析計畫以及制定命名規則。前者包含確定行銷活動目的，以及擬定相關策略等，交由行銷人員去提出細部追蹤的需求並加以執行；後者則是根據分析計畫，擬定 GTM 中的管理、命名規則。

專案管理人員必須能夠在行銷人員安裝代碼後，驗證設定是否能夠取得正確資料為主要職務，比起行銷人員，專案管理人員較需要從分析工具的平台端，驗證資料是否正確的能力。當然，如果專案管理人員本身理解 HTML5、CSS 與 JavaScript，並且能夠執行偵錯的話，可以提升整個執行流程的效率。

首次導入 GTM 應注意事項

對於第一次導入 GTM 的企業，有 3 點需要特別注意：

1. 是否已經按照標準流程建立代碼並發布第一個版本？有關 GTM 的標準作業流程，可以參考下一段。
2. 避免安裝重複代碼，因此需要請工程師與專案管理人員先行確認目前網站中所有代碼，並於建立 GTM 後核對是否都已經完成轉移。
3. 移轉期間的資料空窗期。在作業順序上，應該是「刪除舊代碼」與「新增 GTM」同時進行，但 GTM 容器中可能有部分尚待測試的代碼，因此在轉換的過程中，這些需要測試的代碼，有可能在刪除舊代碼後，沒有辦法發揮原本的效果，導致資料缺漏。這部分建議發布容器前，先在測試環境先進行測試，之後在正式環境直接推送的版本。

針對第三點，如果企業並沒有測試環境可供測試，必須要直接切換的話，這時仍會建議至少先確保各平台追蹤工具的頁面瀏覽設置正確。因為這類型代碼幾乎都有代碼範本可使用，較不會出錯，可以降低資料缺漏的損失。

GTM 管理標準作業流程

下圖是 applemint 針對已有 GTM 容器的客戶管理代碼時的標準作業流程。是針對 Google Tag Manager Best Practices: 24 Actionable Tips 這篇文章中的概念加以整理後建立出來的流程。以下針對幾項重點進行說明：

新增工作區

建立新的工作區，最主要的目的在於獨立出編輯的環境。此外，新增工作區後，在發布版本時，版本的名稱預設就是工作區名稱，因此養成建立工作區的習慣，就是養成建立版本的習慣。

在免費的 GTM 中，除了預設工作區 (Default Workspace) 以外，可以額外新增 2 個工作區，彼此之間的修改不會互相干擾。然而，如果其中一個工作區發布後，另一個工作區需要先更新工作區後，確保沒有發生修改衝突後，再發布第二個工作區。

除錯

在 GTM 的除錯生活，往往是樸實無華且枯燥。

在發布容器前，強烈建議一定要先預覽、偵錯。除了在 Tags 檢查代碼是否正確觸發外，透過 Variables 跟 Data Layer 確保當前資料的正確性，也是除錯過程中非常重要的一環。

如果說代碼無法正確觸發，可以試著在 Tags 的地方，點擊 Tags Not Fired On This Page 中未觸發的代碼，確定是否有 Blocking Triggers 阻止代碼觸發，或是 Firing Triggers 是否符合當下的條件。

如果說不知道該從哪裡檢查起，你也可以試著將預覽的狀態分享給其他人協助偵錯。

分享預覽

分享預覽的使用情境，除了內部檢查外，也可以交由信任的第三方協助除錯。

在 [預覽模式] 開啟後，點選 [分享預覽]，並將對話視窗的連結分享給協助偵錯的對象，就可以讓對方協助進行測試與偵錯了。需要注意的是，對方只有瀏覽偵錯視窗的權限，雖然無法進入 GTM 進行編輯，但是也可以透過偵錯視窗，了解到網站中目前安裝了哪些代碼，有哪些資料層變數等。

結語

隨著行銷工具越來越多樣化，透過提升行銷人員掌控網站追蹤碼的彈性，不僅可以降低部門間溝通的成本，也能將這樣的管理架構，進一步適用到對廠商的關係：透過管理權限劃分，讓企業對網站的代碼保有所有權，但是授與廠商足夠的彈性，可以為企業提供客製化服務。

有的人會以「GTM 會拖慢網站效能」為理由，堅持使用直接安裝代碼的做法。這種想法並不完全錯誤，因為濫用 [自訂 HTML 代碼]，或是安裝過多追蹤碼，對於網頁而言都是負擔。但是這更凸顯出了 GTM「管理重於技術」的角色，透過完善的代碼管理規劃，其實安裝 GTM 的效能並不比直接安裝代碼還要差！

你的公司還沒使用 GTM 嗎？applemint 強烈建議立刻著手跟公司內部的資訊人員討論安裝 GTM 的計畫。