User-ID,讓報表更精確
Google Analytics 有一個要手動開啟的好功能:User-ID。
在沒設定 User-ID 時,每一位使用者進到網站,GA 都會自動派發一組 Client-ID,這個 Client ID 就跟臨時識別證一樣,你之後逛的每一個頁面,都會記錄在這組臨時的 ID 上。
這組 Client-ID,GA 是記在 cookies 裡的,問題來了,假設今天小明同學先用桌機打開 Chrome 進入你的頁面,一小時後又用了手機的 Safari 進入你的頁面,再一個小時後又借了朋友的電腦打開 Chrome 進入你的頁面,請問小明會有幾組 GA 的 Client-ID?
3 組,因為 cookies 不會跨瀏覽器,也不會跨裝置,因此不同的瀏覽器、不同的裝置,對 GA 來說這是三位不同的小明。
而 GA 的 User-ID 功能,就像是你主動發給每個人的會員證一樣,假設小明不論用什麼裝置或瀏覽器進到你的網站前,都先秀出會員證,那是不是之後他去了哪個頁面、點了哪些東西,你都可以用小明會員證的 ID 去查找?
GA 的說明文件一開始就寫:
User ID 功能可讓您將單一使用者的永久性 ID 連結至該名使用者的互動資料;這些資料源自使用者在一或多台裝置上開啟的一或多個工作階段。
User ID 功能簡介
Analytics (分析) 會將每一個不重複的 User ID 視為不重複使用者,從而在報表中提供更精確的使用者人數。
這樣一來,當您傳送 ID 以及來自多個工作階段的相關資料給 Analytics (分析) 時,報表就能夠更全面地整合出使用者與您商家的關係。
用前面小明的例子來說,就是雖然小明有三組 GA 給的臨時識別證(桌機、手機、別人的電腦),但因為每一次你都給了他同一個會員證,所以 GA 就會以你提供的這個會員證編號(User-ID),去把這三次的工作階段都視為是小明的。
也因為可以在跨瀏覽器、跨裝置上去做使用者歸戶,在開啟了 GA 的 User-ID 功能後,就能使用 GA 裡的「User ID 報表資料檢視」和「跨裝置報表」。
對前端來說有個大問題
既然 User-ID 可以精確判斷出使用者的數位足跡,那為什麼這項功能 GA 不預設為開啟?
一樣看剛小明的例子,有看出一個不是 GA 本身就有的東西嗎?沒錯,就是「會員證」。
要告知 GA 小明是用哪一個會員證(User-ID),你的網站就必須要先有會員的功能,能針對每個會員給出不同的會員 ID,而 GA 是不會主動提供會員證這項功能的。
因此,如果是純前端,是無法 100% 使用 User-ID 的,得跟後端配合才行。
因此,如果你的網站想用 User-ID 這項功能,那就得先開發出會員系統才行。
本篇範例說明
Let’s Write 本站,August 還沒打算用會員制,因此以下開始寫的範例不是正規的作法,在寫跨裝置報表時的資料會不準,因為 User-ID 純悴是用 cookies 來紀錄而不是用資料庫及會員帳號來判斷。
正規作法
用 GA User-ID 的正規作法應該是以下:
- 讓使用者註冊,註冊完後給一組唯一的會員 ID
- 使用者登入會員後,把他的會員 ID 當作 User-ID 傳給 GA。當然,如果不想洩漏會員 ID,也可以給加密過的或是哈希值什麼的。
- 如果使用者沒登入會員,那就不告知 GA,或是告知為 null。
本篇範例作法
因為本站沒有會員機制,但又必須要有數值可以給 GA,因此作法改為以下:
- 每一位使用者進到本站,背後會 POST 到 Google Apps Script 上 August 寫的一個 API,API 會回傳一組隨機產出的 uuid
- 拿這組 uuid 當作 User-ID 來告知 GA
- 將這組 uuid 寫進 cookies 裡
- 使用者下次再進來時,就先查 cookies 裡有沒有存在 uuid,沒有就重複步驟 1
User-ID 是存在 cookies 裡的,無法跨網域跟跨裝置,所以後面寫到「User ID 報表資料檢視」和「跨裝置報表」時,上面的數字是不準確的,先在此說明。
以下開始筆記如何使用 Google Analytics 的 User-ID 功能。
開啟 GA User-ID 功能
進到 GA 的後台後,點選左下角的「管理」(齒輪的 icon):
接著會進到管理的介面,確認你要加入 User-ID 的資源後,點選中間的「追蹤資訊」後,會展開下拉選單,選單中就會有一項是「User-ID」,點選它:
之後會看到畫面右側展開了 User-ID 的設定項目,共有三步。
1 同意 User-ID 政策
第一步是同意 GA User-ID 的規定,裡面有一項很重要的,就是給出的 User-ID,不會是使用者本人的真實資料。就像我們不會拿會員的身份證字號當作 User-ID 一樣,畢竟之後埋碼的部份會是明碼,如果真的拿身份證字號當作 User-ID 並寫在頁面上,那就是連外星人都看得到,就會觸犯了地球跟外星球的個資法。
另外也有提到說必須告知使用者 User-ID 的資料會到 GA 上,這部份就是各站的會員說明上的事了。為了保險也在這公告一下,本站因為要筆記本篇,在範例說明那段有說用的是隨機碼,而且是記在 cookies 上,不會另外開個資料庫來記錄這組隨機碼的資訊。基本上派發的 User-ID 都是為了有個資料可以呈現報表用,使用者刪掉 cookies 後也就不存在這組 User-ID,所以不會從 User-ID 中去持續追蹤你的數位足跡。
都同意 GA 的說明後,就把「我同意 User-ID 政策」下面的按鈕按成「啟用」就行,接著再按下一步:
2 埋 GA 追蹤碼時,再加一行 User-ID
下一步就會提供要埋的程式碼了,看到程式碼不用緊張,因為來來去去就只有一行,看你網站上原本埋 GA 的方式是 gtag(xxxxxx)
還是 ga(xxxxxxx)
來決定要埋哪一個。
本站用的是 gtag,所以用 gtag 的來說明,要埋的程式碼是這一行:
gtag('set', { 'user_id': 使用者的User-ID });
「使用者的 User-ID」,如果網站本身有會員機制,那就請後端工程師提供直接寫進去或是寫個 API 給前端接。本篇用的是 Google Apps Script 的 uuid 功能,直接產出一組隨機碼來當作 User-ID 來使用,在此也附上寫在 GAS 上的 code:
function doPost() { var id = Utilities.getUuid(); return ContentService.createTextOutput(id); }
不要懷疑,就是這幾行就搞定,這就是提供 uuid API 的程式碼。
以下附上當使用者進入後,檢查 cookies 是否存在 uuid,以及 POST 到 API 取得 uuid 後,設成 User-ID 的 code:
因為 WordPress 預設有引用 jQuery,所以 POST 是用 jQuery 的。
「GAS 發佈後的 URL」可以參考這篇,寫了怎麼使用 Google Apps Script:
工作階段整合
這一步除了提供要埋的程式碼,也有一個選項,叫「工作階段整合」,是一個開關按鈕。
當一個使用者(小明同學)進到你的網站時,會被計算是一個工作階段,之後他所做的每一件事都會計在這次的工作階段裡。
而網站在取得小明的 User-ID 時,可能需要一點時間,比方發 API 給後端,後端回傳這個會員的 User-ID,我們假設這過程花了 10 秒,小明不會一直等,等到你 10 秒確定完 User-ID 後,才開始做捲動、點擊、到下一頁等的動作。
「工作階段整合」是「啟用」的話,就是即使小明在這 10 秒間逛了好幾個頁面、點了好幾個按鈕,在 GA 確定好 User-ID 之後,也會把這 10 秒間的記錄歸進小明的 User-ID 裡,不會因為 User-ID 晚給了就掉漆沒記到。
「工作階段整合」是「關閉」的話就相反,小明前 10 秒做的事情不會歸在這組 User-ID 裡,一定要等 10 秒後確定 User-ID 了,在這之後所做的事才會歸進小明的 Uesr-ID 中。
「工作階段整合」預設是啟用的,確定埋完碼及工作階段整合後,就可以按下一步。
3 新增 User-ID 用的資料檢視
這一步只會有一個「建立」按鈕,按了就會在 GA 中新增一項資料檢視:
新增資料檢視要填的東西不多,就三項:
- 是要看網站還是 App?
- 這個資料檢視的名稱
- 是否開啟 User-ID 功能
因為主要是看 User-ID,所以名稱可以直接填 User-ID 比較好懂。
下面「顯示 User-ID 報表」記得要按成「啟用」,沒按的話上面幾步全白做了。
最後按下「建立資料檢視」,就完成了開啟 GA User-ID 功能的部份。
接著就是等個幾天,讓 GA 開始收資料了。
過了幾天,GA 收到資料,也進到 GA 後,接下來看看有了 User-ID 後有什麼改變吧。
User-ID 帶來的報表改變
一般 VS. User-ID 目標對象報表
首先,看一下有加了 User-ID 後,GA 有什麼不一樣的地方,主要有不一樣的就是「目標對象」這個選項的部份:
比對一下後,發現 User-ID 少了幾個報表:目標對象、客層、興趣。另外跨裝置旁邊也沒有測試版的字樣。
沒有找到說明文件說明少了這些報表的原因,不過 August 可以推測有 2 個原因。
第一個是,User-ID 功能,每個 ID 都是我們自行給出的,假設我們今天給的 User-ID 可以對應到會員 ID,那會員在註冊時所填的資料更加豐富而且精確,因此 GA 就不提供這些數據分析。
第二個,Google 的產品這幾年很重視隱私權。GA 一般報表的 Client-ID 是雜湊碼,你無法用它來比對出特定使用者,比方比對出某一組 Clinet-ID 就是小明本人。而用了 User-ID 後卻可以,因此為了防止提供到太細的資料產生出法律糾紛,GA 就不提供像客層、興趣等的報表。
用了 User-ID 的功能後,最明顯的改變在兩個報表上:使用者多層檢視、跨裝置。
使用者多層檢視
使用者多層檢視,一般報表跟 User-ID 都有,不一樣的是,一般報表是顯示 Client-ID,User-ID 則是顯示你給的 User-ID。
一般報表的部份長這樣:
以 Clinet-ID 當主要維度,除非你會通靈,不然不會知道這些 Client-ID 是誰。
用了 User-ID 後就會變這樣:
以你提供的 User-ID 當主要維度,跟你資料庫中去比對出會員 ID 後,你就可以知道每個會員在你網站上的使用狀況。
使用者多層檢視報表,如果點了 Client-ID 或 User-ID,就會進到使用者報表,點進去長這樣:
一般報表
User-ID
左邊是使用者的基本資料,像是從哪來到你的網站、是用桌機還是手機來、什麼時候來的等等。
右邊的 icon 就是使用者在網站中的瀏覽、事件。
如果有了 User-ID,你可以更清楚的知道你的會員在網站中的使用情形。
跨裝置
現在每個網站幾乎都有 RWD,就是一個頁面可以相容各種尺寸的裝置,而近幾年的趨勢就是使用桌機逛網站的人愈來愈少,用手機逛的愈來愈多。
跨裝置,顧名思義就是你的使用者,同時有用桌機、手機逛你網站的比例。
這可以做些有趣的發現,比方曾經看過文章寫說,大家都用手機在逛商品頁,但下單時都用桌機下單。但你能確定你的站也是這樣嗎?就可以透過跨裝置報表來檢查。
跨裝置報表似乎一般報表也正在研發,不然也不會標個「測試版」三個字,但至少在寫這篇筆記當下,一般報表是還看不到的,資料都是空的:
有了 User-ID 後,就可以看到跨裝置有資料:
因為本站用的都是隨機給的 User-ID,而且又是記在 cookies 上,因此會看見桌機、手機兩個範圍是分開的,如果真的有使用以會員 ID 派發的 User-ID,就會看見有重疊的部份。
如果真的有使用以會員 ID 派發的 User-ID,就會在「路徑中的步驟」維度上看見比較多的標籤,有可能像這樣:
Desktop -> Mobile -> Desktop
報表上也可以看到有一個「使用者交易率」的欄位,就是說,如果你的網站有用了 User-ID 功能,再配上完整的目標設定的話,就可以知道使用者在你網站上購買商品的步驟,那對於「大家都用手機在逛商品頁,但下單時都用桌機下單」這件事也可以確定是不是真的。
筆記後心得
Google Analytics 的 User-ID 功能,是一個更讓你了解使用者的好物。
要確實的使用,就必須要行銷企劃、前端工程師、後端工程師的配合,是一個 GA 的進階用法。
在大家都想要有使用者行為資料的現代,這是一個很加分的免費功能。
參考資源
本篇參考了以下資源寫成:
How to generate an uuid in google sheet?
[…] GA3 也可以開啟 User-ID 的功能,以前有寫過筆記文,請看:User-ID 功能 設定及報表檢視。 […]