Google Tag Manager 埋碼埋起乃

現在是個重視數據的時代，在經營網站除了seo優化網站的可見度以外，收集數據也不失為一個非常有力的處理方式，淺至點擊多寡，深一點結合使用者的事件路徑，我們可以更具體的去看到更多可以優化的方向，潛在客群，又或者版面更新要採用何種版本，不過身為工程師，主要就是協助收集這些相關的數據

使用Google Tag Manager，我們可以更有效的去管理我們的埋碼，簡單來說，當我們同時要將加入購物車的資料送到GA跟Facebook，當然我們可以直接加在前端的網站程式做處理，但試想當我有三個五個地方都有加入購物車的資料需要送，在維護管理上就會顯得比較花時間

本篇不太適合對埋碼完全沒接觸過的人類ＸＤ

埋碼方式

分享一下目前有接觸到的埋碼方式，要說有哪個最好，我倒是覺得不太一定，官方GA課程也有提到，其實沒有特定的埋碼方式，基本上還是依據需求去處理，每個網站其實也可能各自有不同的情況跟需求

---

由前端將要送的資料在做的同時推送至datalayer

• 觸發事件的時機
  • 由前端程式碼決定
• 優點
  • 如果埋碼跟前端是分開的，在前端頁面更動時，有高機率（人嘛～有時貴人多忘事），埋碼的事件不會因此而失效
  • 有人會覺得這樣抓事件比較精準ＸＤ
• 缺點
  • debug偏麻煩，尤其頁面跨多部門都這樣處理的時候，還需要借用chrome開發者工具去看前端的程式碼，在跨個部門跟對方解釋，請他調整，然後某天她沒有注意到弄到的話就...再度悲劇（？）
  • 如果前端那邊程式有狀況，就可能會出現不明原因沒觸發，又或者推了異常多次相同資料的情況
• 小記
  • 其實多少會覺得有點浪費GTM的功能，畢竟是個優化管理的工具，反而把一部分東西散在管理的範圍以外的地方，在操作或debug上會有點不便，自己一條龍可能沒什麼感覺，當網站規模大起來，對應的處理人員不一樣的時候，再加上溝通的時間，相對比較消耗時間

---

常見的trigger HTML

• 以送到GA為例
  
• 觸發事件的時機
  • 看trigger的設定條件
    • 頁面的資訊
    • 變數的狀態
    • datalayer的資料狀態
    • 等等....還有很多
• 優點
  • 好理解ＸＤ很簡單的一個對一個，如果網站沒有那麼複雜的話，其實這樣埋起來真的愉快ＸＤ
  • 行銷人員有機會自己處理一些埋碼需求
• 缺點
  • 當事件一多起來，規劃就顯得很重要，有些資訊如果重複使用ＪＳ抓，雖然還沒有驗證過，但其實也是個不必要浪費的效能
  • 搭配一些可能我們避免重複抓就會用Event去觸發另外一個Event去送到另外一個地方，東西一多起來，再加上文件失傳就會開啟大航海尋寶時代

---

Serverside

其實我這塊比較沒有接觸，實作部分可能之後有興趣又或者被逼著弄QQ就再不得不補上(?)

• 觸發事件的時機
  • 其實跟前一個差不多
• 優點
  • 其實我覺得概念有點像網頁前端，對於有前後端接觸的比較好理解
    • 誠如第一個方法，只是我們把前端要做的事情搬到gtm上面，而送資料詳細格式那些就是交給後端(gtm-server)，前端這邊把講好的資料格式(不需要跟目的地的要求一樣)還有資料目的地給後端，後端將對應的資料跟事件送出去
  • GTM放在網頁上的JS可以減少
• 缺點
  • 目前想不到什麼缺點，可能對於新接觸的比較難理解這樣的概念，如果要處理gtm server可能還需要一點研究時間

---

共用元件

簡單來說就是讓拿資料的方式單純化一點，實行上需要前端工程師配合，但其實我們本來埋碼就有可能因為一些特定需求，當無法從網頁上獲得資訊的時候就會需要另外的協助

目前有看到可以將需要的資料放在element的元件，至於要做成一包物件json放在dataset還是一個個資料欄位走不同的dataset就看人看需求，要說目前知道的部分，一個個會讓element的屬性變得有點多ＸＤ可能前端大大們看起來不是很舒適

用講好的classname或id，利用gtm去監聽特定element的觸發

• 觸發時機
  • 含有特定className or Id被觸發點選
• 優點
  • 如果頁面上有大量類似相同的需要追蹤的東西可以省一點埋碼時間
  • 抓資料的方式單純化
  • 觸發元件的方式單純化
  • 資料只抓一次，後面有其他需求有要一樣的資料的話，可以利用事件觸發事件去做延伸，又或是在同一個customHTML處理多送到一個地方的情況（也可以做一點資料調整）
  • 我個人偏向也可以利用customEvent讓抓資料跟送事件的部分分開，主要考量到dubug會比較清楚可能是哪個階段的部分需要調整，另一個就是如果未來有一樣資料要送到不同地方之類的需求，就可以有空間可以操作增加又不用重複在做抓資料的動作
• 缺點
  • 當有更多事件需要送的時候，就需要花點時間判斷接收到的資料
  • 行銷人員比較難自行做這部分的埋設，幾乎由工程師執行

番外篇 - trueview的埋碼

這部分算是常見的需求，到底使用者看到了哪些廣告、商品又或是特定區塊，行銷如果可以獲得相對的數據也可以比較容易去衡量成效

但其實這對我來說是個看起來很容易但其實相對點擊複雜很多的需求，第一眼看到就會想說啊就看到特地元件就把事件送出去就好了呀，當你的網站十分單純，可能需要監聽的區塊只有一點點的時候，這樣其實就還好萬事平安ＸＤ
但回頭想想，當我們網站有

• 大量需要監聽的區塊時（比如有超多的商品跟廣告還有各種輪播），看到一個發送一次真的是個合適的方式嗎？（尤其像ＧＡ免費的次數可能有上限，再多就需要＄＄＄＄又或者這樣一直發送會不會多少對頁面流暢有影響）
• 當使用者點進來立刻離開的時候，這些數據還有沒有必要傳送

目前針對這塊有接觸到的方法，有點像Queue那樣去處理，只是在發送的時機需要多加留意，除了固定個數一組組發送，停留多久、甚至離開網頁以後的發送，這部分應該也沒有所謂正解，畢竟每個網站的介面需要偵測的東西多少有些不一樣，找到合適的方式比較重要

tags: gtm javascript