Appearance
工作的經驗上常發現很多人把 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 上。