GTM 發送 GA User ID 追蹤訊號

開始前，請確認是否已經建立 Google Analytics user id 專屬的資料檢視。

注意：user id 資料檢視使用的 user id 是由網站給予使用者的，如果網站沒有相關的登入機制與 user id (會員編號)，則無法使用此功能！

事前準備

進行 Google Tag Manager 的設定以前，必須確保網站已經準備好相關的認證系統，大多數的情況下，認證系統即是使用者的登入狀態憑證，並帶有會員編號資訊；透過認證系統，我們可以選擇將會員編號儲存到網站第一方 cookie 或是 dataLayer(建議)。

備註：根據 Google Analytics user id 政策規定，一旦使用者登出網站，就必須停止追蹤 user id。

使用網站第一方 cookie

Step 1: 確認網站已從認證系統取得 user id 並儲存為第一方 cookie 。

上面使用的 cookie 檢查工具

Step 2: 建立 GTM user id cookie 變數

使用 dataLayer (建議)

Step 1: 確認網站已從認證系統取得 user id 並發送到 dataLayer，有關 dataLayer 的說明，可以參考 GTM Data Layer 資料層 基礎介紹。

備註：建議將 user id 訊號(authentication)在 GTM 載入前(Container Loaded) 就送出，上圖範例就是 user id 在 GTM 載入以後才送出(比較不好)，後面會講原因。

Step 2: 建立 GTM user id 資料層變數

Google Tag Manager 發送 User ID 訊號設定

由於 user id 資料檢視是使用匹配(hit)來串接使用者行為，代表每一個匹配都必須要有 user id 才能進到 user id 資料檢視內，即便開啟工作階段統合功能， user id 的欄位資訊只會向前整合，並不會向後整合(詳細說明可參考官方文件的範例)，建議將 user id 欄位資訊設定在 GA 變數內，確保所有使用此 GA 變數的代碼都能夠擁有 user id 欄位資訊。

在欄位名稱填入 userId，值填入剛剛建立的 userId 變數(dataLayer 或 cookie變數)。

注意： user id 的欄位名稱格式是固定的，一定要叫 “userId” GA 才會認得。

檢查訊號是否正確送出

開啟預覽模式，檢查並確認每一個匹配是否都帶有正確的 user id 欄位訊號；如果有， user id 數據很快就會出現在 user id 資料檢視。

補充說明

前面有提到，使用 dataLayer 來存取 user id ，建議在 GTM 載入以前就送出(使用 第一方 cookie 也一樣)；原因就是這會造成所有在能夠存取 user id 資訊以前就發送的匹配並不會有 user id 資訊，即便有開啟工作階段統合功能，我們也無法確認使用者在同工作階段一定還會產生其他帶有 user id 的匹配；如果沒有，這個工作階段所產生的數據將不會進到 user id 資料檢視。

如果真的無法將 user id 資訊在 GTM 載入前就送出，建議在能夠存取 user id 資訊的當下立刻送出一個事件(帶有 user id 的匹配)，透過工作階段統合功能將前面的匹配一併串接起來，但這麼做也不是 100% 準確，而且表示每個頁面瀏覽都要多使用一個事件(匹配)，最好的方式還是確保所有的匹配都能夠自己帶有 user id 。

進階應用

開始使用 user id 資料檢視後會發現，雖然 user id 資料檢視是依據網站發送的 user id 建立的，但是在預設的情況下，除了使用者多層檢視，我們並不能夠在其他報表使用 user id 這個欄位，想要在其他報表使用 user id 這個欄位，可以參考 GTM 搜集 GA client ID ，將 client id 改成 user id 即可；這麼做不僅能夠在其他報表使用 user id 這個欄位，而且不會被侷限在 user id 資料檢視，在一般的資料檢視一樣可以使用這個欄位。