如何用 Google Tag Manager 打造免費的 Data Collection x Streaming Data 架構

Published in

AsiaYo Engineering

10 min readMay 22, 2017

本次 Project 規劃、測試到上線大概花費 Developer x 1 + PM x 1 約莫 3~5 天時間（單純程式架構面，應該 1~2 個工作天內）。

一開始先來聊聊，為何我們需要一個 Data Collection x Streaming Data 架構？

情境一 
行銷人員想用 Google Adwords, Facebook ads 的 re-marketing 廣告機制，三跪九求 Developer 幫忙加入 GA / Facebook 的 SDK or Script，每想針對一個動作做 re-marketing 就需要 Developer 改一次程式，有 N 個服務就要改 N x N 次。情境二 
PM / Marketer 想分析各種使用者行為，建立 Funnel 分析...就要等 Developer 重埋各個事件點，不同服務就要埋一次，一樣需要 N x N 次的工。情境三 
想淘汰某個分析服務，採用新的分析服務， Developer 大崩潰得砍掉重練全部再重埋各個事件點。

可以看到上述三種情境營運起來，各方都勞師動眾非常沒有效率。

而 Segment.com / Google Tag Manager 目標就是解決這樣的問題，協助你從 client side, server side 收集資料，並輕鬆遞送這些資料至各種第三方服務。

以各種解決方案來說，個人蠻推 Segment.com，因為它的確不論是 UI 面或設定端都較簡易。但自從近期發生下述三件事情，我們立馬就決定替換掉它（聽說換了 CEO 文化改很大？）。

Segment.com 誇張事蹟
1. 沒有主動告知改 Pricing Model ，前後價差超過 30~40 倍
2. 業務為了業績、想盡話術 + 回信很嗆 
3. 談判喬很久結果 Segment 自動續舊約功能他們忘記拔掉，我們居然被自動續舊約。當我們冤大頭？

於是我們一怒之下決定立馬把 Segment 抽換掉( 其實是沒預算 XD )用 Google Tag Manager 頂替（看起來 Segment 是沒什麼救了）。

步驟 1. 確認資料需要被串流至哪些分析與行銷服務？

在開始前，第一步是確認目前公司有用到哪些第三方 Analytic Services and Marketing Services。以 AsiaYo 為例，我們使用的應該算是蠻基本款大部分 Startup 會用到的服務，包含：

Google Analytics: Traffic Analysis, Conversion Attribution ModelAmplitude: Funnel Analysis, User AnalysisFacebook Pixel: Ad Performance, Custom Audience, Dynamic AdsGoogle Adwords: Ad Performance, Custom Audience, Dynamic AdsVisual Website Optimizer: A/B Testing, Split Testing

步驟 2. 了解資料收集三要素：Page, Event and Identify

9 成的 Analytic, Marketing Services 基本上不離開下述三個追蹤要素： Page, Event, Identify。

Page: 頁面瀏覽Event: 自訂使用者事件Identify: 使用者相關資訊

Page
一般來說，大多第三方服務只要塞入他們的 Script 就會自動補抓 Page 相關資訊（像是 GA, VWO..），GTM build-in Trigger 有自動內建。

Event
自定義的使用者事件。值得注意的是，有些第三方服務在產出特殊報表(通常是營收相關)、又或是一些特殊用途 e.g., Dynamic Ads…時，需要遵從第三方服務各自制定的準則。

以 Facebook Pixel 的 Standard Event 為例，為了讓廣告報表顯示出轉換營收，需要照 Facebook 自訂的規範去定義事件名稱。像是完成購買來說， Facebook Standard Event Name 為 Purchase，然後可以塞入特定的 Property (currency, value) 進去讓廣告報表得以顯示購買價值以及幣別。另外像是 Google Analytics 如想觀看 Ecommerce 相關報表也需要另外傳遞 ecommerce 事件。

Identify
記錄特定使用者相關資訊，通常大多都不會用到，因為牽扯用戶相關敏感資訊。除非像是 Amplitude, Mixpanel, Outbound 等需要用到使用者區隔/Funnel 分析服務外，否則通常不會太會用到。

而行銷人愛用的 re-marketing, Custom Audience 通常就是用上述三種方式去組出各式使用者區隔。

Facebook Custom Audience (Page base + Event Base)

正式開工前，需要先研究好第一與第二步驟之項目，以這次轉移為例，我們做了下述表格確認需要設定的事項（哪種服務用到哪種追蹤要素）：

步驟 3. 認識 Tag, Trigger, Variable and Data Layer

Google Tag Manager 設定的基本 4 個元素為：Tag, Trigger, Variables, Data Layer。

Tag (像是一包執行檔的概念, 內含執行項目、觸發條件、變數...) 
A tag is a snippet of code that executes on a page. Most of the tags used in Google Tag Manager are designed to send information from your site to a third party. Tags typically execute, or fire, when the page loads, or in response to some interaction on the page.Trigger (觸發條件) 
A trigger is a condition that evaluates to either true or false at runtime. It does this by comparing the value in a variable with the value that you specified when you defined the trigger.Variables (變數，這應該不用多作解釋...)Data Layer (用來儲存各種資訊供 GTM 使用) 
The data layer is an object that can be configured to contain information that you want to pass to Google Tag Manager. Data Layer Variables may be configured in Google Tag Manager to capture these values for later use. In order for GTM to assess the value of a Data Layer Variable, an event has to be pushed as well.

設定 GTM 時會遇到一個狀況，像是我們有許多自訂的追蹤事件（像是各種點擊事件、加入購物車…等動作），如果每個自定義事件都要設定一個 Tag 會設定到天荒地老，且很難維護。

這時候可以善用 Variable 以及 Data Layer 去自動觸發、傳遞 Custom Event Name 與 Property ，如下圖所示：

還有另一個特殊狀況，是我們想將其中一個第三方服務 VWO A/B testing 的實驗數據灌入另一個第三方服務 (e.g., Amplitude)，其實做法跟上述一樣將 VWO 相關實驗資訊萃取出放至 Data Layer，即可透過 GTM 自動將相關實驗數據從 VWO 傳至 Amplitude。

步驟 4. 測試部署

前幾個步驟設定完成後再來就是測試了，第一階段測試可以利用 Google Tag Assistant 以及 GTM 內建的 preview and debug mode 先做第一步檢查。

但為求保險還是得去各家第三方服務驗證資料是否有正常流入，這個測試過程起來其實會碰到一些問題，像是有些服務不是即時顯示資料、或是必須累積 1,000 筆資料後才顯示…，只能放了好幾天才知道是否成功。下述舉例幾個我們在不同服務的測試驗證方法：

Google Analytics + Ecommerce
GA Attribution Model Default 設定為 Last Non-Direct Click Model，可以利用這特性於網址後面加上 utm parameters ，用以驗證 realtime report, pageview, ecommorce, funnel 是否正常運作。