如果你是數位行銷人,相信你對 Google Analytics 這類的第三方追蹤工具並不陌生,如果你有下臉書廣告,那你應該埋過 Facebook Pixel Code ,一些對數位行銷比較熟稔的企業可能還會用到 Mixpanel 、 Crazy Egg 或是 Hotjar 這類更進階的追蹤工具。

要使用這些追蹤工具,都需要事先在產品上安裝追蹤代碼(Tracking Code) ,然而傳統不懂程式的行銷人,往往看到 Tracking Code 就像看到天書一樣,只知道要埋 Code,但具體怎麼埋、埋在哪裡、埋的 Code 到底在幹麻,卻是一點也不了解,這會造成幾個問題:

(1)埋 Tracking Code 的時候總是複製貼上就丟給工程師,如果追蹤數據突然發生異常(譬如網站某次改版之後,數據突然收不到了),但你也不知道怎麼 debug,而工程師也因為忙著開發而懶得理你,最後數據收集端爆掉,後面分析報表自然也做得亂七八糟。

(2)很多分析工具都有提供進階的功能可以使用,這些功能往往需要調整 Tracking Code 才有辦法使用,如果不懂程式,就只能用到最基本的皮毛。

這篇文章將帶你走過 Tracking Code 的運作原理,並且會以最常見的 Google Analytics、Facebook Pixel 為例,一步步帶你看懂這些像天書的程式碼到底在幹麻。

解析 Tracking Code 

Tracking Code 是一段 JavaScript ,它主要用來追蹤用戶行為並把資訊傳送回第三方追蹤工具的伺服器,所有的 Tracking Code 都有三個特色:

(1)會先載入一個外連的 JavaScript 檔,這個 JavaScript 檔由第三方工具提供,裡面包含了「這個追蹤工具」會用到的 Base Code,你可以把 Base Code 想像成是一個工具箱,裏頭有各式各樣追蹤用戶行為時會用到的工具,沒有先載入工具箱,工具就沒辦法使用。

(2)JavaScript 會按照 HTML 的順序載入,一般 Tracking Code 都會明確告訴你要埋在哪裡,埋的越上面,載入的優先順序越高,一般而言我們會建議埋在<head>之間,這樣可以儘早讀取 Tracking Code ,避免資料遺失。

(3)Tracking Code 會包含一組獨特的 ID,這組 ID 是用來告訴第三方工具的伺服器,這次收集的數據要送到哪個帳號。

以下我們以 Google Analytics 的 Tracking Code 作為例子:

Breakdown Google Analytics Tracking Code
上圖 1 的部分看起來很複雜,其實就是在載入 Google Analytics 的 Base Code,這些 Base Code 被儲存在 www.google-analytics.com/analytics.js 這個 JS 檔案中,如果這個檔案沒有先被載入,後面 ga 這個函式就無法使用,所以這段 code 才會被放在最上方。

另外,1 片段中的 async=1 的意思是 Google Analytics 採取的是非同步(asynchronous)載入模式。一般而言,瀏覽器是採取逐步載入的方式讀取 HTML ,如果你的網站比較龐大,<head> 中有很多外連檔案,瀏覽器就要花比較多時間在處理 <head>,那麼讀取 <body> 的時機就會往後延,網速快的地方使用者可能沒感覺,但如果網速較慢,就會感覺到明顯的讀取延遲。而非同步(asynchronous)的技術讓瀏覽器在載入 Google Analytics 的 JS 檔時,也能夠同時讀取剩下的 HTML 檔,這種多工讀取的方式,就可以避免 Tracking Code 拖慢網頁的讀取速度。

接下來讓我們看 2 跟 3 ,這兩行都用了同一個 ga 函式,只是參數不同所以做的事情不同:

  • 2 的代碼會觸發 Google Analytics 追蹤器,將數據發送到相應的 Property ID。
  • 3 的代碼發送1次瀏覽記錄至 Google Analytics。

接下來再來看看 Facebook Pixel Code:

FB Pixel Code

有沒有覺得很像?仔細比較 Google Analytics 跟 FB Pixel Code 的 Tracking Code,你會發現基本上都分成三個部分 —— 讀取 Base Code、指定回傳的帳號(透過ID)、回傳一個初始 event,瞭解了 Tracking Code 的基本架構,接下來我們來看看常遇到的幾種追蹤。

事件追蹤(Event Tracking)

一般而言行銷人員會想要追蹤的事件不外乎幾種:點擊、送出表單、交易成功、捲動網頁滾軸等等,要做到這類的事件追蹤,必須做兩件事情——在 HTML 物件上設定監聽器、寫好傳送 Event 的 Tracking Code。

所謂的 HTML 物件,就是構成網頁的元素,譬如按鈕、表單等等,而監聽器就是 HTML 物件的事件觸發機制,至於傳送 Event 的 Tracking Code 就因追蹤工具而會有所不同,讓我們以 Google Analytics 的點擊事件追蹤為例:

Google Analytics Event Tracking
這段代碼的意思是:
1. 當 ID 名為 button 的 HTML element 被點擊的時候,會觸發事件監聽器。

2. 這個事件監聽器會幫你傳送一個 event 給 Google Analytics。

3. 這次傳送的 event 有包含三個屬性 —— category 是 customer-acquire,action 是 click,label 是 sign-up。

到現在你看過了好幾次 ga 函式了,前面有提到 ga 會根據參數的不同而做不一樣的事,如果你要傳送 event 給 Google Analytics,ga 的函式指令前兩個參數必為 ‘send’ 跟 ‘event’,後面三個參數則可以自行定義,其意義分別為種類(category)、動作(action)與標籤(label),相關的技術文件可以參閱 Google 官方說明

那如果你也想要用 Facebook 追蹤點擊呢?其實只要在 ga 下面再加上 Pixel code 就可以了:

Google Analytics Event Tracking2

如此一來,當按鈕被按下時,除了會傳送 event 給 Google Analytics,也同時會記錄一個 Facebook 的 conversion 。在這個例子中,因為這個按鈕是 sign up ,所以我們用的是 Facebook 九大標準追蹤事件中的 Lead。

以上是點擊的例子,不管你要做哪種類型的事件追蹤,基本上原理都是這樣,先找出你想觸發事件的 HTML element,然後加上事件監聽器,接著再填入事件觸發後要傳送的 event tracking code。

你可能會問,我真的需要懂這麼多程式才能做事件追蹤嗎?如果你可以獨立完成這三個步驟,那當然最好,如果你對埋監聽器不是很熟,那你至少要把 event tracking code 提供給工程師(就是上圖 ga 跟 fbq 的部分),因為一個正常的網站工程師應該都知道怎麼埋事件監聽器,但他可能沒有時間幫你讀懂追蹤工具的 document,所以你可以這麼對工程師說:

我想要在這個按鈕被點擊的時候,觸發這兩段代碼:

ga('send','event','customer-acquire','click','sign-up');
fbq('track', 'Lead');

這兩段代碼會傳送 event 給 Google Analytics 跟 conversion 給 Facebook,代碼的位置要放在 Google Analytics 跟 Facebook Pixel 的 base code 下面,不然代碼內的函式無法發動,就交給你啦!謝啦!

如果你要請工程師幫你埋代碼,最好說明清楚三件事:代碼是幹嘛的、代碼要放在哪個位置、什麼時候要觸發,以上就是很好的範例啦!

電子商務追蹤(E-commerce Tracking)

電子商務追蹤跟事件追蹤很像,一樣是在某個時機點(譬如加入購物車、結帳時),透過 Tracking Code 傳送資料給第三方追蹤工具,比較要注意的是,電子商務追蹤所帶入的值基本上都是動態的,因為產品名稱、價格、種類等資料都會隨著使用者下單而有所不同,所以這必須要透過工程師從後端擷取資料,把動態的值填入 Tracking Code。

以 Google Analytics 為例,假設你的客戶買了兩件 T-shirt,那你在結帳的完成頁的代碼應該會長這樣:

Google Analytics E-commerce Tracking

圖中代碼的參數都會隨著訂單而動態變化,所以必須由後端工程師把值填入,如果你網站用的是 PHP ,可以參閱 Google 官方文件的教學

如果要把電子商務追蹤講得完整一點,可以寫成另外一篇完整的文章,因為今天只是 Tracking Code 的 overview,礙於篇幅只講到這裡,網路上還有很多相關的教學,大家可以再自行研究囉!

跨網域追蹤(Cross-domain Tracking)

有時候你的客戶行為會橫跨兩個不同的網域,譬如電商網站主站的網址是 shop.xxx.com ,但結帳程式寫在 checkout.xxx.com,由於 Google Analytics 的 cookie 是跟著 domain 的,所以當使用者從主站連到結帳站的時候就會被視為離站,而且從結帳頁回到主站時還會被視為推薦連結流量,如果我們希望整段交易的過程不要被打斷,就會用到 Google Analytics 的跨網域追蹤功能,這會需要做一些特別的設定,步驟如下:

(1)修改 shop.xxx.com 的 tracking code
(2)修改 checkout.xxx.com 的 tracking code
(3)設定 Google Analytics 的網址呈現方式

為什麼要做(1)跟(2)呢?Google 官方說明得很清楚:

系統通常會在使用者點擊前往新的網域時建立新的工作階段,並設定第一方 Cookie。為了保留第一個網域的工作階段資訊,您必須將 Cookie 從第一個網域傳送至第二個網域,而第二個網域則必須授權允許您這麼做。

簡單來說,在沒有設定跨網域追蹤之前,使用者在主站跟第二個網域之間切換,會被視為兩個不同的 session(工作階段),如果要把這兩個 session 「連」在一起,必須要讓主站跟第二個網域可以互相傳送 Cookie,而(1)跟(2)修改的部分就是為了實現這個傳送 Cookie 功能的必要設置。

(1)的做法:

在 shop.xxx.com 的程式碼片段中找出 create 這一行,應該會長這樣:

ga('create', 'UA-XXXXXXX-Y', 'auto');

對這段程式碼進行下列變更 (您需要進行的變更會以粗體紅色文字顯示):

ga('create', 'UA-XXXXXXX-Y', 'auto', {'allowLinker': true});
ga('require', 'linker');
ga('linker:autoLink', ['checkout.xxx.com'] );

(2)的做法:

在 checkout.xxx.com 的程式碼片段中找出 create 這一行,應該會長這樣:

ga('create', 'UA-XXXXXXX-Y', 'auto');

對這段程式碼進行下列變更 (您需要進行的變更會以粗體紅色文字顯示):

ga('create', 'UA-XXXXXXX-Y', 'auto', {'allowLinker': true});
ga('require', 'linker');
ga('linker:autoLink', ['shop.xxx.com'] );

至於為什麼要做(3)呢?那是因為如果你沒有特別設定的話,Google Analytics 只會顯示網頁路徑和網頁名稱,不會顯示網域名稱。換句話說,你只會在「網站內容」報表中看到網頁的相對路徑,而非絕對路徑,你可能會看到以下的內容:

  • /products/A12345.html
  • /cart/promotion.html
  • /payment.html

由於網域名稱不會列出,因此要分辨每個網頁所屬的網域不是很容易。

我們會希望 Google Analytics 顯示完整的域名:

  • shop.xxx.com/products/A12345.html
  • shop.xxx.com/cart/promotion.html
  • checkout.xxx.com/payment.html

如此一來就清楚多了!

(3)的做法(直接抄 Google 大神的官方說明):

若要在報表中顯示網域名稱,您必須進行兩個動作:建立報表資料檢視複本 (包含所有網域的資料),並在這項新資料檢視中加入進階篩選器。這樣一來,篩選器便會讓 Analytics (分析) 在報表中顯示網域名稱。跨網域追蹤設定完畢後,請按照本例設定資料檢視篩選器,以便在報表中顯示網域名稱。對於部分欄位,您必須選取下拉式選單中的項目。至於其他欄位,您必須輸入下列字元:

  • 篩選器類型:自訂篩選器 > 進階
  • 欄位 A:主機名稱擷取 A:(.*)
  • 欄位 B:要求 URI 擷取:(.*)
  • 輸出至:要求 URI 建構函式:$A1$B1

按一下 [儲存] 即可建立篩選器。

(1)+(2)+(3)做完之後,跨領域追蹤就完成啦!

跨裝置追蹤(Cross-device Tracking)

現代人常常是多裝置的上網者,當使用者用不同裝置造訪同一個網站時,追蹤工具很難去判斷他們是不是同一個人,就連同樣用電腦上網,如果是用不同瀏覽器,也會被追蹤工具視為是不同的訪客,因為第三方工具一般是使用 Cookie 來辨別使用者,而 Cookie 是存在瀏覽器的資料夾底下,換瀏覽器 Cookie 自然也就不同了。

為了解決這個問題,Google Analytics 特別推出 User ID 的功能,他的原理是當使用者「登入」你網站的時候,透過客製化的 Tracking Code 塞給使用者一個由「你的會員系統」所產生的一組獨特 ID,這組 ID 會被保留在 Google Analytics 上面,下次使用者透過其他裝置登入時,由於因為也會被塞同樣的 ID ,所以在 Google Analytics 上就會被視為同一個人。

所以要啟用 User ID 的功能,你的網站需要能做到兩件事情:

(1)你的網站必須有可以讓使用者登入的會員系統

(2)你的會員系統必須有能力產生一組獨特的 User ID 給每一個會員,且不管透過哪種裝置登入,這個 User ID 都不會改變

要塞 User ID 給每個登入後的使用者,需要用以下的 Tracking Code:

ga('set', 'userId', -- USER_ID);

粗體紅色的部分,就是必須請工程師動態填入的「網站會員系統」的 User ID。這段代碼發送的時機,必須是 User ID 已知的情況,也就是使用者登入成功後才需要發動。啟用 User ID 之後,只要是登入過後的使用者,不管他們透過什麼裝置造訪你的網站,你都能夠在 Google Analytics 的報表中辨別他們的身份。
(要啟用 User ID 功能,必須先在 Google Analytics 的資源設定下開啟 User ID  ,礙於篇幅在此不再贅述,有興趣者可自行參閱官方教學。)

線上到線下追蹤(O2O Tracking)

在某些狀況下,你會想要追蹤線上的行銷活動是否真的有帶動線下使用者的行為。

想像你是一間餐廳的數位行銷人員,你們老闆要你幫忙做一個發送折價券的行銷活動,拿著折價券到場用餐可享八折優惠,藉此看看是否能吸引買氣,3個月下來總共發了 8000 張折價券,總共有 1500 人實際到場消費,平均客單價是 400 元。而這個時候行銷主管給你了一個難題,他想知道各個行銷渠道的 ROI 是多少,是 Facebook 廣告有用還是請部落客宣傳更有用?XX 部落客一天到晚吹噓自己的粉絲有多少,到底多少人是真的透過他的文章到我們餐廳消費的?

我們來看看若要做到這個情境下的 O2O Tracking,要滿足哪些條件:

(1)每張折價券必須有獨特的 coupon code
(2)用戶在線上取得折價券時,第三方追蹤工具要能夠知道他是哪裡來的,而且還要記錄下他的               coupon code
(3)如此一來,當用戶真的拿折價券到店消費時,你才能夠透過 coupon code 去比對第三方工具上        的資料,計算出每個行銷渠道的線下轉換數,然後再從店內的營收去反推 ROI

我們需要分成兩個部分——記錄用戶的來源跟 coupon code,前者本來就是第三方工具的強項,用 Google Analytics 的話不管是直接看推薦連結來源,或是更細一點用 UTM Link 應該都不成問題,比較麻煩的是記錄 coupon code,你必須在 Google Analytics 自創一個欄位來儲存 coupon code 的值,這時候就會用到「自訂維度」的功能了。

要啟用自訂維度功能,必須先到管理–>資源–>自訂定義–>自訂維度中新增維度:

custom dimension

然後自訂一個叫做 Coupon Code 的維度,範圍勾選使用者。

custom dimension2

接下來 Google 提供以下的程式碼(就是剛剛設定的 Coupon Code 是編號1,所以 ga 的參數是 dimension1。):

var dimensionValue = ‘SOME_DIMENSION_VALUE’;

ga(‘set’, ‘dimension1’, dimensionValue);

粗體紅字的部分,就是要動態填入的 coupon code 值,這部分就需要請工程師幫忙了。只要用戶在取得折價券的時候,發動這段代碼,coupon code 的資料就會跑到 Google Analytics了。

接下來在報表就會新增一個 Coupon Code 的欄位,因為我們只是範例,所以筆者沒有真正的資料可以截圖給大家看,我在網路上找到了這張圖,大家可以想像一下 Clothing Size 的部分改成 Coupon Code 的樣子:

analytics

如此一來,就可以看到透過各個行銷渠道發送出去的 coupon code,只要把這張報表 export 出來,對照餐聽內 coupon code 使用的狀況,用 excel 拉一拉,就可以計算出不同管道送出的 coupon實際被使用的張數,自然也算得出 ROI。

總結

看完了以上的教學,是不是對 Tracking Code 有了更深一層的了解呢?「行銷人員不可不知的程式知識」系列文就到這裡告一段落,若大家還有什麼其他的問題,歡迎在底下留言!

Image Credit: bannersnack blog