2026 GA4 教學：自訂維度與自訂指標設定、驗證與報表使用

GA4 自訂維度與自訂指標是什麼？

GA4 教學遇到事件參數進報表前，先分清 GA4 自訂維度與 GA4 自訂指標：維度描述資料類別，指標記錄可計算數值。

自訂維度 vs 自訂指標

自訂維度回答「這筆資料屬於哪一類」，例如 content_type、author_name、form_type。自訂指標回答「數值是多少」，例如 lead_value、score、reading_percent。實務上，我會先把自訂定義當成報表欄位，而不是把所有事件參數都登錄。

項目	GA4 自訂維度	GA4 自訂指標
資料型態	文字、分類、狀態	金額、次數、分數、百分比
回答問題	哪一類內容、哪種表單、哪個會員層級	多少名單價值、多少互動分數、多少加購金額
常見錯誤	把 User ID、時間戳記、Session ID 放進去	把文字分類誤當成數值

事件參數、使用者屬性、自訂定義的關係

事件記錄動作，事件參數補充動作細節，使用者屬性描述使用者長期狀態。自訂定義則是 GA4 後台的登錄動作，讓這些參數能在探索、報表與受眾條件中被選用。

描述型資料與數值型資料

描述型資料適合做維度，例如文章分類、作者、表單類型、商品尺寸。數值型資料才適合做指標，例如名單分數、商品毛利級距分數、估算價值。判斷錯會讓報表無法切分，或讓指標沒有分析意義。

什麼情況才需要設定自訂維度或指標？

需要自訂時，先問預設維度是否已能回答問題；只有缺少可分析欄位，才把參數登錄成自訂維度或指標。

先查是否已有預設維度

GA4 已有頁面路徑、來源媒介、裝置類別、事件名稱、重要事件等常用欄位。若標準報表或探索已能回答問題，重複建立自訂定義只會占用配額。這一步很無聊，但能避免後面一半的資料混亂。

描述型資料用維度

如果分析問題是「哪一種內容帶來轉換」、「哪一類表單品質較好」、「哪個活動素材吸引回訪」，欄位多半是維度。常見命名包含 content_type、campaign_theme、form_type。

數值型資料用指標

如果分析問題是「每次表單提交的名單價值是多少」、「產品被加購時的毛利分數是多少」，欄位才適合做指標。指標要能加總、平均或比較，否則只是披著數字外衣的分類。

不用自訂的情境

判斷問題	建議	原因
GA4 已有預設維度嗎	先用預設	避免浪費自訂定義配額
只是單次檢查埋碼嗎	看 DebugView	不一定需要做成長期報表欄位
值幾乎每筆都不同嗎	不要登錄	容易形成高基數與 other
資料沒有決策用途嗎	不要追	追了也不會改變內容、投放或轉換判斷

設定前要怎麼規劃事件、參數與命名？

設定前先從分析問題倒推事件與參數，命名固定後再交給 GTM 或 gtag.js，才不會追到一堆不能比較的欄位。

從分析問題倒推事件

不要從「我想多追一個參數」開始。先寫下報表問題，例如「哪種文章帶來表單提交」，再決定事件 generate_lead，參數 content_type、author_name、form_type。真正有用的 GA4 設定，通常是先有決策問題，才有追蹤欄位。

事件名稱與參數名稱規則

事件名稱和參數名稱要固定小寫、底線分隔、語意一致。不要今天用 formType，明天用 form_type，後天又用 Form_Type。大小寫與拼字不同，GA4 會當成不同欄位或不同值處理。

哪些值不要送進自訂維度

User ID、Email、電話、Session ID、訂單流水號、完整時間戳記，都不適合做自訂維度。這些值不是分類，而是接近唯一識別或高度分散的資料，會增加隱私與高基數風險。

追蹤規劃表範例

分析問題	事件	參數	登錄方式	報表位置
哪類文章帶來名單	generate_lead	content_type	事件範圍自訂維度	探索
不同表單價值差異	generate_lead	lead_value	自訂指標	探索
電商商品屬性表現	purchase	product_margin_level	商品範圍自訂維度	探索

GA4 自訂維度設定教學

GA4 自訂維度設定重點是選對範圍：事件範圍看單次互動，使用者範圍看長期屬性，商品範圍看電商品項。

事件範圍自訂維度

事件範圍適合描述某次行為的細節，例如 form_type、content_type、cta_position。設定路徑是 GA4 管理，資料顯示，自訂定義，建立自訂維度，範圍選事件，事件參數填入完全一致的 parameter 名稱。

使用者範圍自訂維度

使用者範圍適合長期屬性，例如會員等級、登入狀態、客戶類型。這類資料要來自 user property，不能拿單次點擊細節硬塞。我的判斷是，中小型網站若沒有穩定會員系統，使用者範圍維度要保守使用。

商品範圍自訂維度

商品範圍用在電子商務事件的商品陣列，適合分析商品顏色、尺寸、供應商、毛利層級等品項屬性。WordPress 內容站通常用不到，Shopline、Cyberbiz、91APP 這類電商才比較常見。

各範圍適用案例

範圍	適合欄位	適合網站	常見症狀
事件範圍	content_type、form_type	內容站、B2B 官網	探索想切分事件成效
使用者範圍	member_level、customer_type	會員網站、SaaS	想比較不同使用者群
商品範圍	product_margin_level、item_size	電商網站	想看商品屬性與營收

GA4 自訂指標設定教學

GA4 自訂指標只適合可加總、平均或比較的數值資料，像金額、分數、次數，文字分類不要硬登錄成指標。

什麼資料適合自訂指標

適合的資料包含 lead_value、scroll_score、quote_amount、engagement_points。每個指標都要先定義單位，否則同一欄位可能混入新台幣、分數、百分比，報表會失去可讀性。

事件參數必須是數值

自訂指標依賴數值型事件參數。若 GTM 或 gtag.js 送出的是文字，例如 "high"、"basic"，就該改成自訂維度；若要做分數，請送 1、2、3 這種可計算值。

計算指標怎麼定位

計算指標適合把既有指標組合成新的判讀欄位，例如表單價值除以提交次數。它不是補救命名混亂的工具；底層事件參數錯了，計算指標只會把錯誤包裝得更像報表。

金額、次數、分數案例

案例	參數名稱	單位	適合用途
名單估值	lead_value	新台幣	比較表單品質
互動分數	engagement_score	分數	衡量內容互動深度
加購件數	addon_count	次數	觀察加購行為

GTM 或 gtag.js 要怎麼把參數送進 GA4？

GTM 與 gtag.js 的任務是把 event_name 和 parameter 正確送進 GA4；送出後仍要在自訂定義登錄，報表才可分析。

GTM 事件參數設定

在 Google Tag Manager 中，先建立觸發條件，再到 GA4 事件標籤填入事件名稱與事件參數。參數名稱要和規劃表一致，值可以來自 Data Layer 變數、DOM 變數或固定文字。若 Preview 看得到觸發但 GA4 沒有參數，多半是標籤欄位或變數值沒有正確帶入。

gtag.js 事件參數設定

使用 gtag.js 時，可在事件呼叫中加入參數。概念如下，不需要把整個網站改成大型專案：

gtag('event', 'generate_lead', {
  form_type: 'demo',
  content_type: 'ga4_guide',
  lead_value: 3000
});

Google Developers 的 事件參數文件也明確說明，自訂參數送出後，仍要在 GA4 登錄為自訂維度或指標，才可在標準報表與探索中分析。

參數送出後仍要在 GA4 登錄

這是很多人卡住的地方：DebugView 看得到參數，不代表探索已經能用。送資料是收集層，登錄自訂定義是報表層。少了後者，參數仍可能被收集，但無法被一般報表選用。

常見參數範例

參數	用途	建議登錄
content_type	文章類型	事件範圍自訂維度
author_name	作者表現	事件範圍自訂維度
form_type	表單分類	事件範圍自訂維度
lead_value	名單價值	自訂指標

設定完成後怎麼確認 GA4 有收到資料？

確認 GA4 有收到資料要分層檢查：先看觸發，再看標籤，再看 DebugView，最後才用即時報表與後續報表判讀。

GTM Preview

GTM Preview 用來確認觸發條件、變數與 GA4 事件標籤是否正常。先點擊網站上的實際按鈕或送出測試表單，再檢查該事件是否觸發，參數值是否正確。若這裡失敗，不用急著看 GA4。

Tag Assistant

Tag Assistant 用來檢查 Google tag 或 GTM 是否載入、是否有重複標籤、是否送到正確的 GA4 資源。若同一頁裝了多組追蹤碼，後續報表差異會更難排。

DebugView

DebugView 是確認事件與參數是否進入 GA4 的主力工具。進入 DebugView 後點開事件，檢查參數分頁是否出現 form_type、lead_value 等欄位。我的經驗是，DebugView 看不到，就不要先怪報表延遲。

即時報表

即時報表可輔助確認近期事件，但它不是最終歸因證明。即時報表能回答「有沒有活動」，不能完整回答「所有轉換來源是否正確」。正式分析仍要等資料處理完成後再看探索或標準報表。

48 小時等待規則

檢查層級	看什麼	通過標準
GTM Preview	觸發與變數	事件標籤觸發，參數有值
Tag Assistant	標籤送出	送到正確 GA4 資源
DebugView	事件與參數	事件內看得到參數
報表與探索	自訂定義可用	登錄後資料最多可能需要 48 小時顯示

自訂維度與指標要怎麼用在報表和探索？

自訂維度與指標的價值不在設定完成，而在探索、標準報表、受眾與再行銷中回答實際分析問題。

探索報表使用方式

探索最適合檢查自訂維度與指標。可把 content_type 放到列，把重要事件、工作階段、lead_value 放到值，觀察不同內容類型帶來的轉換品質。若要看漏斗，可銜接 AARRR GA4 漏斗追蹤 與 轉換漏斗流失分析。

標準報表能不能看到

部分標準報表可透過自訂報表調整看到自訂維度，但探索通常更直覺。標準報表適合日常監控，探索適合回答臨時分析問題。不要為了讓所有欄位都出現在標準報表，把追蹤設計變得過度複雜。

受眾與再行銷用途

自訂維度可協助建立受眾，例如看過特定內容類型、送出特定表單、瀏覽高毛利商品的人。這類資料也能支援 A/B 測試資料分析 與 轉換率優化，但前提是命名一致、資料量足夠、轉換定義清楚。

內容站、B2B、電商案例

網站類型	自訂維度	自訂指標	分析用途
內容站	content_type	engagement_score	比較內容成效
B2B 官網	form_type	lead_value	評估名單品質
電商網站	product_margin_level	addon_count	分析商品與加購

常見錯誤與排查流程

排查 GA4 沒資料時，先分辨「沒送到」、「有送但沒登錄」、「已登錄但尚未處理」或「被高基數壓成 other」。

DebugView 有但報表沒有

先確認自訂定義是否已建立、範圍是否正確、參數名稱是否完全一致。若剛建立，報表最多可能需要 48 小時才出現資料。這不是馬上重埋 GTM 的理由。

參數有送但沒登錄

如果 DebugView 看得到 form_type，但探索找不到這個欄位，通常是還沒在自訂定義登錄。到 GA4 管理中的自訂定義建立對應維度或指標，並確認 parameter 名稱沒有大小寫差異。

出現 not set

not set 常見原因是事件發生時參數沒有值、參數只在部分頁面送出、或使用者進入流程時缺少必要條件。排查時要回到事件觸發當下，看參數值是否真的存在。

出現 other

other 常和高基數有關。當維度值過度分散，報表可能把低量項目合併到 other。把時間戳記、唯一 ID、完整網址查詢字串放進自訂維度，是最常見的錯法之一。

事件名稱拼錯或大小寫不一致

症狀	可能原因	修法
DebugView 沒事件	GTM 觸發失敗或 gtag.js 沒執行	先看 Preview 與 Tag Assistant
有事件無參數	變數沒值或參數欄位填錯	檢查 Data Layer 與參數名稱
探索找不到欄位	未登錄自訂定義	建立自訂維度或指標
同一欄位分裂	大小寫或拼字不一致	統一命名並保留一套規則
大量 other	高基數維度	改用分類值，不送唯一值

台灣網站常見追蹤範例

台灣網站常見追蹤差異來自平台能力：WordPress 彈性高，B2B 表單重名單品質，電商要看商品與訂單邏輯。

WordPress 內容站

WordPress 內容站常追 content_type、author_name、topic_cluster。若資料來源穩定，可用 GTM 從頁面變數或 Data Layer 取值。不要把每篇文章 ID 都登錄成自訂維度，分類和主題才比較能支援內容決策。

B2B 官網表單

B2B 官網通常重視表單類型、產業別、名單價值。可用 form_type 做事件範圍自訂維度，用 lead_value 做自訂指標。真正要小心的是表單成功頁與前端驗證，兩邊觸發條件要一致。

Shopline／Cyberbiz／91APP 電商

電商網站常見需求是商品屬性、折扣、加購、會員狀態。若平台能輸出商品陣列，可規劃商品範圍自訂維度，例如 product_margin_level。若平台後台限制較多，先確定能否穩定輸出參數，再決定 GA4 登錄。

Wix 或手動埋碼網站

Wix 或手動埋碼網站要先確認是否能控制事件觸發與參數值。若只能送出基本頁面瀏覽，不必硬做複雜自訂維度。我的建議是先追表單提交與內容分類，等資料穩定後再擴充。

平台	優先追蹤	先避開
WordPress	分類、作者、表單類型	文章唯一 ID
B2B 官網	表單類型、名單價值	個資欄位
Shopline／Cyberbiz／91APP	商品屬性、加購、會員狀態	訂單流水號
Wix	表單提交、頁面類型	不穩定 DOM 值

配額、高基數、隱私與資料品質限制

配額、高基數、User-ID 與 Consent Mode 會直接影響資料品質；追蹤規劃太細，報表反而更難用。

標準資源配額

依 Google 官方 自訂維度與指標說明，標準資源可建立的配額包含使用者範圍自訂維度 25 個、事件範圍自訂維度 50 個、商品範圍自訂維度 10 個、自訂指標 50 個、計算指標 5 個。刪除達上限的自訂維度後，新增前可能要等待 48 小時。

高基數為什麼危險

高基數代表同一維度有太多不同值，例如每個使用者、每次工作階段、每個時間戳記都不同。Google 官方也提醒，高基數自訂維度可能影響報表與探索，並導致資料被壓到 other。這類問題通常不是報表壞掉，而是欄位設計太細。

不要把 User ID 當自訂維度

User ID、Email、電話、Session ID 都不該當自訂維度。User ID 有 GA4 專門功能，個資也牽涉隱私與合規判斷。這裡不提供法律意見，但從資料品質角度，這些值也不適合作為報表分類。

Consent Mode 與資料缺口

Consent Mode 會影響可收集資料與轉換判讀，尤其在廣告、表單與電子商務情境中更明顯。若 GA4 數字和後台不同，先確認 Cookie、同意狀態、付款完成、退款與訂單口徑。相關設定可接續看 Consent Mode，但不要把它當成所有落差的單一答案。

限制	錯誤做法	較穩定做法
配額	每個事件重複登錄同一參數	共用一致參數名稱
高基數	送唯一 ID、時間戳記	送分類值與級距
隱私	送 Email、電話	避免個資進入 GA4
資料品質	把 GA4 當後台訂單系統	先定義報表口徑

FAQ

FAQ 集中回答 GA4 自訂維度、GA4 自訂指標、事件參數、等待時間、配額與資料差異的常見判斷題。

GA4 自訂維度和自訂指標差在哪？

自訂維度回答「是哪一類」，例如內容類型、表單類型、會員等級；自訂指標回答「多少」，例如名單價值、分數、次數。文字分類用維度，數值資料才用指標。

事件參數送到 GA4 後，為什麼報表看不到？

常見原因是只把參數送進 GA4，卻沒有在自訂定義登錄為自訂維度或指標。DebugView 可看到收集狀態，但標準報表與探索仍需要登錄後才可分析。

GA4 自訂維度設定後多久會出現資料？

DebugView 和即時報表可先檢查事件與參數是否進入 GA4；自訂維度或指標登錄後，標準報表與探索最多可能需要 48 小時才顯示相關資料。

什麼資料不適合做成自訂維度？

User ID、Email、電話、Session ID、時間戳記、訂單流水號都不適合。這些值不是穩定分類，容易造成高基數、隱私風險與報表 other 問題。

自訂維度該選事件範圍還是使用者範圍？

動作細節選事件範圍，例如表單類型、內容類型、CTA 位置；長期使用者屬性選使用者範圍，例如會員等級、客戶類型。若屬性每次事件都可能不同，通常不適合使用者範圍。

商品範圍自訂維度適合什麼網站？

商品範圍自訂維度適合電商網站，特別是需要分析商品顏色、尺寸、供應商、毛利層級的情境。一般內容站或純 B2B 官網，多半不需要使用這個範圍。

自訂指標可以拿來追蹤表單分數或名單價值嗎？

可以，但事件參數必須是數值，且要先定義單位。表單分數、名單價值、預估成交金額都可用自訂指標，前提是計算規則固定。

DebugView 有資料，探索報表沒有資料怎麼辦？

先檢查自訂定義是否已建立、範圍是否正確、參數名稱是否完全一致。若剛完成登錄，等待資料處理；若超過處理時間仍沒有，再回頭檢查事件是否只在測試環境觸發。

GA4 自訂維度配額滿了怎麼處理？

先盤點重複、無決策用途、長期沒有使用的自訂定義。刪除前要確認報表是否仍依賴該欄位；刪除達上限的維度後，新增可能要等待 48 小時。

GA4 數字和電商後台不同，是自訂指標設定錯嗎？

不一定。Cookie、Consent Mode、付款狀態、退款、取消訂單、後台認列時間，都會造成 GA4 與電商後台不同。先對齊訂單口徑，再判斷自訂指標是否設定錯。