工作的經驗上常發現很多人把 GA 及 GTM 這兩個東西混淆， 所以簡單介紹兩者差異，並提出對於 GTM 的一些想法。
Google Analytics
GA 是 Google Analytics 的簡稱，是 Google 提供的免費的分析工具， 可以用來分析網站流量、使用者的行為、轉換率…等等。
近期又有一個比較常見的新名詞 GA4，特指新版 GA； 相較也會看到一個名詞「通用型 GA」或稱 UA(Universal Analytics)代表舊版的 GA， 通用型 GA 即將在 2023 年 7 月停止服務， 所以近期 GA4 的討論掀起了熱潮，大家都在為轉換到新版 GA4 做準備。
Google Tag Manager
GTM 是 Google Tag Manager 的簡稱， 是 Google 提供的網站代碼管理工具，本身的功能與分析完全無關。 只要安裝一組代碼到網站上，理想上就可以讓行銷人員(也可以是開發人員本身)在不需要更動網站原始碼的情況下， 安裝各式各樣的追蹤工具(GA 只是其中一種)，這種方式有點像外掛，從外部去添加要安裝的代碼。
簡單想，安裝 GTM 就是在網站的「前端」開一個後門，擁有這個後門權限的人可以設定任何代碼到網站上， 追蹤工具 GA、Facebook Pixel、Line Tag、Yahoo Pixel…等，所有你能想到的工具安裝終究只是將一段代碼放在網頁上而已， 插入代碼一個關鍵的問題就是「該什麼時候發生？」因此 GTM 存在很多強大的功能，其中之一就是可以製作「觸發條件」。 不用接觸到網站原始碼，就能在設定好的條件(瀏覽某個頁面、某個按鈕被點擊…)發生的時候運行指定代碼，這就是 GTM 在做的事情， GTM 主要就是由一堆代碼、觸發條件組成。
所以使用 GA 不代表一定要用 GTM；使用 GTM 也不代表是為了 GA，兩者沒有強烈的關係。
對 GTM 的一些看法
網路上可能會看到一種資訊把 GTM 塑造成不用在依賴工程師的強大工具， 前面講到這是一個理想上的可能，GTM 確實強大，能力越強責任越大。 我會認為如果是在簡單的情況，也就是代碼、觸發條件不多且單純的情況或許可以讓非開發人員使用 GTM 執行簡單的作業， 但最好還是要由開發人員審核過被建立的項目，才進行 GTM 版本的發佈。
由非開發人員操作 GTM 可能的問題：
- 不當的代碼，直接影響網頁性能： 從網路上複製了一段能達成目的的代碼，監聽網頁滾動事件，事件處理器又使用了造成網頁重繪的程式，所以在網頁滾動時影響網頁本身動畫的表現。
- 不當選擇器的使用： 想要追蹤某個元素的點擊，寫了一段複雜的選擇器
.a-menu .b-menu #c-menu a，覺得當下能達成目的就好，沒想過更好的寫法或未來可能失效的問題。 - 無法理解自己設定的項目： 因為不理解程式面的行為，第三方提供的代碼就照貼，但當中可能有些代碼在「所有頁面」已經運行過，結果又在特定條件發生時多運行了一次，可能產生錯誤的分析結果還不知道問題的存在。 也因為不了解設定的項目，可能製作了更多但不必要的代碼、觸發條件來達到目的。
- 選擇不正確的觸發條件： 取決於開發人員使用的技術，有些事件的發生不是單純的網頁網址改變，導致安裝的代碼沒有被觸發，最後還是得由開發人員參與除錯。
- 資安或個資外洩可能： 前面說到 GTM 就是開一個後門，所以要監聽使用者行為、輸入，將資訊傳到第三方去，這是做得到的。
- 合作的第三方要求在 GTM 裡面添加了另一個 GTM 的安裝，這個 GTM 在背後運行的代碼就不為人知。
- 合作的第三方要求安裝不常見的追蹤碼，即便當下驗證沒問題，這組追蹤碼的程式在日後是可以改變原來的行為而不為人知的。
- 疏於管理： 想到做什麼就做，隨著時間過去， 有些早該移除或已經沒有在合作的第三方代碼仍存在於 GTM 上，不會「主動」想到那些已棄用的代碼，資料還在送給第三方。
以上就想到的可能舉了幾個簡單的例子，即便是由開發人員操作 GTM 還是可能會有上述問題，取決於開發人員的能力跟自我要求。 重點就看你要用什麼心態去看待 GTM，如果不拘小節開大門走大路，上面講到很多的問題就是無視且承擔風險， 如果只是自己的專案沒有涉及到客戶隱私、系統的專案也確實不用想太多； 如果是關係到有一定規模公司的網站 GTM 且合作的第三方又多，要駕馭 GTM 讓路走得長走得遠，就要相對謹慎一點。
GTM 對開發人員也是一個好用的工具，並不是說不想更動網站原始碼才使用 GTM， 而是 GTM 提供了一個分離的環境，可以讓我們分離出行銷、分析、追蹤相關的代碼， 讓網站的程式碼僅需專注在本身的功能上。與其說分離，或者說這些代碼本來就更適合存在於 GTM 上。
留言