自訂維度和自訂指標就像 Analytics 帳戶中的預設維度和指標一樣，但必須由您自行建立。您可以運用這兩者收集並分析 Analytics 未主動追蹤的資料。
本文內容：總覽
自訂維度和指標可讓您整合 Analytics 資料與非 Analytics 資料 (例如客戶關係管理資料)。例如：
- 只要將儲存在客戶關係管理系統中的已登入使用者性別資料與 Analytics 資料整合，就可以按性別查看「網頁瀏覽量」。
- 若您是遊戲開發人員，則「關卡完成數」或「高分」等指標的重要性，可能會比「畫面瀏覽次數」等預先定義的指標更高。只要以「自訂指標」追蹤這些資料，就可以在靈活又一目瞭然的自訂報表中，追蹤重要指標的趨勢變化。
自訂維度可以在自訂報表中列為主要維度，也可以在標準報表中列為區隔和次要維度。
先決條件
只有已啟用通用 Analytics (分析)，或至少包含一項應用程式報表資料檢視的資源，才適用自訂維度和指標。Android 和 iOS 專用的 Google Analytics SDK (v2.x 以上版本)、analytics.js 和 Measurement Protocol 均支援自訂維度和指標。
若要使用自訂維度和指標，您必須在 Analytics 帳戶和追蹤程式碼中額外設定。自訂維度和指標個別完成設定步驟後，就可以在報表中使用。
限制和注意事項
每個資源的自訂維度以及自訂指標都各有 20 種索引可使用，Analytics 360 帳戶的自訂維度和自訂指標則分別有 200 項索引可用。
您無法刪除自訂維度，但可以停用。請避免重複使用自訂維度，因為一旦修改自訂維度的名稱、範圍和值，系統就可能會將舊有和更新後的值與原有或更改後的維度名稱配在一起，導致合併的報表資料無法準確地以篩選器分隔。
某些自訂維度與客層資訊合併後，不會顯示在報表中。因此，要求包含客層資料的自訂維度時，您可能會遇到報表或 API 套用閾值或存在不相容限制的問題。
自訂維度和指標的生命週期
自訂維度或指標的生命週期可分為四個階段：
- 設定 – 使用索引、名稱和其他資源 (例如範圍) 定義自訂維度和指標。
- 收集 – 將已導入的自訂維度和指標值傳送至 Analytics (分析)。
- 處理 – 使用自訂維度和指標的定義及報表資料檢視篩選器來處理資料。
- 報表 – 在 Analytics 使用者介面中，利用自訂維度和指標建立新報表。
設定
您必須先在 Analytics 資源中定義自訂維度和指標值，才能將它們傳送至 Analytics (分析)。每個 Analytics 資源中的自訂維度和自訂指標，都各有 20 種索引可使用。
定義自訂維度或指標時，必須指定名稱和其他設定值，然後 Analytics 會分配一個索引號，供您參照該維度或指標。自訂維度包含下列設定值：
- 名稱 – 在報表中顯示的自訂維度名稱。
- 範圍 – 用來指定要將自訂維度或指標套用至哪些資料。進一步瞭解範圍。
- 有效 – 是否要處理自訂維度或指標的值。報表中可能還是會出現無效的自訂維度，只是系統並不會處理這些值。
自訂指標包含下列設定值：
- 名稱 – 在報表中顯示的自訂指標名稱。
- 類型 – 用來決定自訂指標值在報表中顯示的方式。
- 最小/最大值 – 報表所能處理及顯示的最小值和最大值。
- 有效 – 是否要處理自訂指標的值。報表中可能還是會出現無效的自訂指標，只是系統並不會處理這些值。
您可以在 Analytics 使用者介面中定義自訂維度和指標。
將自訂維度或指標定義完成之後，請盡量避免修改其名稱或範圍。請參閱導入方面的注意事項，瞭解這類修改可能對報表造成的影響。
收集
自訂維度和指標值會在資料收集期間，以索引和值參數組合的形式傳送至 Analytics (分析)。索引參數會對應至 Analytics 在「設定」階段指派的自訂維度或指標的索引號碼。
與其他類型的資料不同，自訂維度和指標會以附加在其他命中資料 (例如網頁瀏覽、事件或電子商務交易等) 中的參數形式，傳送至 Analytics (分析)。因此，您必須在送出追蹤呼叫前先設定自訂維度或指標的值，系統才會將該值傳送至 Analytics (分析)。
例如，設定自訂維度值的程式碼看起來可能會像這樣：
ga('create', 'UA-XXXX-Y', 'auto');
// 設定索引 1 的自訂維度值。
ga('set', 'cd1', 'Level 1');
// 隨網頁瀏覽命中送出自訂維度值。
ga('send', 'pageview');
自訂指標類型
「整數」或「時間」類型的自訂指標應以整數形式傳送，「貨幣」類型的自訂指標則應以當地幣別適用的固定位數值傳送。
處理資料
系統會在處理自訂維度時，依據範圍決定特定的自訂維度值應套用至哪些命中，資料檢視篩選器則會決定最後要將哪些命中及其相關值納入報表中。
範圍和優先順序
系統會依據範圍，決定要將哪些命中連結至特定的自訂維度值。範圍可分為四種層級：產品、命中、工作階段和使用者：
- 產品 – 將值套用至已設定此值的產品 (僅限「加強型電子商務」)。
- 命中 – 將值套用至已設定此值的單次命中。
- 工作階段 – 將值套用至單一工作階段中的所有命中。
- 使用者 - 將值套用至目前和未來工作階段中的所有命中，直到此值變更或自訂維度不再有效為止。
當某個自訂維度的範圍設為產品層級時，值只會套用至已設定此值的產品上。由於多個產品可以在單次命中中送出，因此範圍設為產品層級的多個自訂維度也可以在單次命中中送出。
命中層級範圍當某個自訂維度的範圍設為命中層級時，值只會套用至已設定此值的命中上，如下方的圖 A、圖 B 和圖 C 所示：
工作階段層級範圍
若您為某工作階段中的同一個索引設定了兩個工作階段範圍的值，系統會優先採納最後設定的值，並套用至該工作階段中的所有命中。如下方圖 D 所示，最後設定的值會覆寫該索引所有先前的值：
使用者層級範圍
最後，若在同一個工作階段中設定了兩個使用者範圍的自訂維度值，目前的工作階段將優先採用最後設定的值，並套用至該使用者未來的工作階段。
如下方圖 B 所示，CD 值 A 會套用至工作階段 2 的所有命中，就像工作階段層級的 CD 一樣。但在圖 C 中，CD 值 A 會繼續套用至第三個工作階段中的命中，因為 CD1 的範圍設為使用者層級而非工作階段層級：
篩選器
資料檢視篩選器可以透過好幾種方式與自訂維度和指標互動。
各個自訂維度和指標值 (不論範圍為何) 會分別連結至其來源命中。如果該次命中遭到資料檢視篩選器篩除，則自訂維度或指標也可能一併遭到篩除 (視其範圍而定)：
- 命中範圍：如果相連結的命中遭到篩除，則命中範圍的自訂維度及自訂指標也將一併篩除。
- 工作階段或使用者範圍：即使相連結的命中遭到篩除，使用者或工作階段範圍的自訂維度也不會被篩除。這兩種範圍的自訂維度值仍會套用至目前工作階段的所有命中 (使用者範圍的自訂維度值還會套用至未來工作階段的所有命中)。
自訂維度也可以用來建構資料檢視篩選器，如此一來，系統就會根據自訂維度的範圍篩選命中。舉例來說，依據某個使用者範圍的自訂維度值篩選的話，就能從與該值相連結的一組使用者中篩選掉目前和未來的工作階段。
報表
完成特定管道的資料收集、設定和其他處理階段之後，就可以從使用者報表介面啟用自訂維度和指標。
自訂維度和指標將顯示在自訂報表中，且可與進階區隔搭配使用。另外，自訂維度也可在標準報表中列為次要維度。
範例
以下舉例說明遊戲開發商如何運用自訂維度和指標來瞭解玩家的行為模式。
一家遊戲開發商最近推出一款新的遊戲。
他們目前導入的 Analytics 會追蹤使用者在玩每個關卡期間瀏覽的畫面。因此，該開發商知道玩家在每個關卡玩了多少次，但還想進一步探討以下問題：
- 簡單、中等和困難等級的關卡分別被玩過多少次？
- 在為期 3 天的免費試用期間內，使用者每天分別玩了多少關卡？
- 試用版及付費使用者分別玩了多少關卡？
為了回答上述問題，開發商必須使用自訂維度建立新的命中、工作階段和使用者群組。
另外，這家開發商同時也在銷售一些有助於提升使用者體驗的額外功能 (例如「強化道具」)；目前已使用「類別」和「變數」欄位，但還想多用一個欄位來追蹤強化道具的銷售情況，藉此評估哪一種等級的強化道具銷量最好。
命中層級範圍
讓我們先從下面的例子來看看，該遊戲開發商如何運用命中層級自訂維度，得知玩家在各種難度的關卡 (簡單、中等和困難) 分別玩了幾次。
開發商原本就以畫面瀏覽計算追蹤各關卡玩過的次數，但還想進一步知道哪個難度的關卡玩過的次數最多。
報表看起來會像這樣：
| 難度 | 畫面瀏覽 |
|---|---|
| 簡單 | |
| 中等 | |
| 困難 |
使用自訂維度之前，該開發商可以查看各關卡的畫面瀏覽總次數，卻無法按關卡難度劃分這些畫面瀏覽。
使用命中層級自訂維度之後，每個畫面瀏覽都能對應不同的關卡難度，如此便能從報表中看出哪種難度玩過的次數最多。
選擇命中層級範圍的原因
使用者可能會在一次工作階段中一連玩好幾個關卡。選用命中層級範圍，難度值就只會連結至與它同時送出的畫面瀏覽，確保在各個關卡瀏覽的畫面只會與一種特定難度產生連結。
設定
導入自訂維度的第一個步驟，就是在 Analytics (分析)「管理」區段的資源設定中定義自訂維度。本例中的自訂維度定義看起來會像這樣：
| 索引 | 1 |
| 名稱 | 難度 |
| 範圍 | 匹配 |
| 有效 | 是 |
收集
開發商原本就在遊戲中利用畫面瀏覽計算追蹤每個關卡被玩過的次數。為了建立難度和各關卡之間的連結，開發商必須在送出畫面瀏覽追蹤呼叫的前一刻設定自訂維度值。
導入結果看起來會像這樣：
ga('create', 'UA-XXXX-Y', 'auto');
// 設定索引 1 的自訂維度值。
ga('set', 'cd1', 'easy');
// 隨網頁瀏覽命中送出自訂維度值。
ga('send', 'pageview', '/level_1/');
在本例中，開發商在追蹤關卡畫面瀏覽的前一刻設定了自訂維度。這個動作建立了難度和畫面瀏覽之間的連結，讓開發商可以在報表中按關卡難度劃分畫面瀏覽命中。
處理資料
將收集到的命中資料傳送至 Analytics 之後，系統便會處理這些資料，並依據其範圍套用自訂維度值。
假設有位玩家在一次工作階段中玩了 6 個關卡，系統收集到的資料看起來會像這樣：
userId = 5555 Session 1: H1: screen_name=/level_1/ cd1_value=easy H2: screen_name=/level_2/ cd1_value=medium H3: screen_name=/level_3/ cd1_value=hard H4: screen_name=/level_4/ cd1_value=easy H5: screen_name=/level_5/ cd1_value=medium H6: screen_name=/level_6/ cd1_value=medium
請注意，使用命中層級範圍是為了確保每個難度值只會連結至與它同時送出的畫面瀏覽。
報表
資料處理完畢之後，由於每個畫面瀏覽都已連結至對應的難度值，開發商便能以畫面名稱和難度做為維度，並以畫面瀏覽計算做為指標，製作出所需的報表：
| 畫面名稱 | 難度 | 畫面瀏覽計算 |
|---|---|---|
| /level_1/ | 簡單 | 1 |
| /level_2/ | 中等 | 1 |
| /level_3/ | 困難 | 1 |
| /level_4/ | 簡單 | 1 |
| /level_5/ | 中等 | 1 |
| /level_6/ | 中等 | 1 |
接著，開發商可以製作自訂報表，以「難度」做為劃分畫面瀏覽計算的主要維度，藉此瞭解各種難度的關卡分別被玩過幾次：
| 難度 | 畫面瀏覽計算 |
|---|---|
| 簡單 | 2 |
| 中等 | 3 |
| 困難 | 1 |
這份報表顯示，中等難度的關卡被玩過的次數最多。開發商使用命中層級自訂維度劃分畫面瀏覽計算，進而成功取得了這項深入分析數據。
工作階段層級範圍
讓我們再用下面的例子說明遊戲開發商如何運用工作階段層級自訂維度，瞭解玩家在為期 3 天的免費試用期間內，每天分別玩了多少關卡。
開發商原本就藉由追蹤各關卡的畫面瀏覽計算，得知每個關卡被玩過的次數，但還想進一步知道玩家在試用期間每天玩了多少關卡。
開發商心目中的報表看起來會像這樣：
| 試用天次 | 畫面瀏覽計算 |
|---|---|
| 第 1 天 | |
| 第 2 天 | |
| 第 3 天 |
開發商使用工作階段層級自訂維度，因此能依據試用天次劃分畫面瀏覽計算，進而看出該數據在免費試用期間內的逐日變化。
選擇工作階段層級範圍的原因
本例選用工作階段層級範圍，是因為它能依據單一「試用天次」值，有效劃分整個工作階段及其所包含的所有命中。
雖然使用命中層級範圍也可以達到相同目的，但如果想要在不對程式碼多做修改的情況下輕鬆設定「試用天次」值，就必須使用工作階段層級範圍。
設定
開發商在 Analytics 使用者介面的資源設定部分中，使用下列值定義了「試用天次」自訂維度：
| 索引 | 2 |
| 名稱 | 試用天次 |
| 範圍 | 工作階段 |
| 有效 | 是 |
收集
開發商原本就在遊戲中利用畫面瀏覽計算追蹤每個關卡被玩過的次數。現在，他們只需要為每個工作階段設定一次自訂維度值，就能建立試用天次與單一工作階段中所有畫面瀏覽之間的連結。
此自訂維度的設定時機是在使用者初次啟動遊戲時：
ga('create', 'UA-XXXX-Y', 'auto');
// 設定索引 2 的自訂維度值。
var day = getDayOfTrial();
ga('set', 'dimension2', day );
// 隨網頁瀏覽命中送出自訂維度值。
ga('send', 'pageview', '/level_1/');
請注意，開發商可以在工作階段期間的任一時間點，設定工作階段層級自訂維度，但在本例中，最簡單的方法還是在工作階段開始時，判斷「試用天次」並設定對應的值。
處理資料
將收集到的命中資料傳送至 Analytics 之後，系統便會處理這些資料，並依據其範圍套用自訂維度值。
假設有位玩家在第一天、第二天和第三天，分別玩了兩次、一次和一次，系統收集到的資料看起來就會像這樣：
userId = 5555 Session 1: H1: screen_name=/level_1/ cd2_value=1 H2: screen_name=/level_2/ H3: screen_name=/level_2/ Session 2: H4: screen_name=/level_3/ cd2_value=1 H5: screen_name=/level_4/ H6: screen_name=/level_4/ Session 3: H1: screen_name=/level_1/ cd2_value=2 H2: screen_name=/level_2/ H3: screen_name=/level_3/ Session 4: H1: screen_name=/level_3/ cd2_value=3
請注意，在每個工作階段中，自訂維度值只會隨其中一次畫面瀏覽送出。
選用工作階段層級範圍，是為了確保「試用天次」值會連結至該工作階段的所有命中，而不只是連結至與它同時送出的命中。
報表
資料處理完畢之後，工作階段層級自訂維度值會與同一個工作階段中收集到的所有畫面瀏覽產生連結。開發商現在可以製作一份以「試用天次」和畫面名稱做為維度，並以畫面瀏覽計算做為指標的報表：
| 試用天次 | 畫面名稱 | 畫面瀏覽計算 |
|---|---|---|
| 1 | /level_1/ | 1 |
| 1 | /level_2/ | 2 |
| 1 | /level_3/ | 1 |
| 1 | /level_4/ | 2 |
| 2 | /level_1/ | 1 |
| 2 | /level_2/ | 1 |
| 2 | /level_3/ | 1 |
| 3 | /level_3/ | 1 |
最後，為了按試用天次劃分畫面瀏覽計算，並確認玩家在試用期間內每天分別玩了多少關卡，開發商製作了一份以「試用天次」做為主要維度的自訂報表：
| 試用天次 | 畫面瀏覽計算 |
|---|---|
| 1 | 6 |
| 2 | 3 |
| 3 | 1 |
資料顯示，玩家在第一天玩的關卡最多，後兩天玩的關卡數目則明顯減少。開發商運用工作階段層級自訂維度，按單一值劃分多個工作階段及其命中資料，進而成功取得了這項深入分析數據。
使用者層級範圍
最後我們將利用以下例子，說明該遊戲開發商如何運用使用者層級自訂維度，得知付費及免費試用使用者分別玩了多少關卡。
和前幾個例子一樣，開發商原本就以畫面瀏覽計算追蹤每個關卡玩過的總次數，但還想進一步按免費和付費使用者劃分畫面瀏覽計算。
他們心目中的報表看起來會像這樣：
| 玩家類型 | 畫面瀏覽計算 |
|---|---|
| 免費 | |
| 付費 |
只要利用使用者層級自訂維度，開發商就能將特定使用者在目前和未來工作階段中的每次畫面瀏覽，連結至特定的玩家類型值，進而得知付費及免費試用使用者分別玩了多少關卡。
選擇使用者層級範圍的原因
本範例選擇使用者層級範圍，因為這樣您就能按單一值，輕易劃分同一位使用者的所有工作階段和命中資料。當同一位使用者的某個值很少發生變化時 (例如本例中的玩家類型)，就十分適合選用使用者層級範圍。
請注意，雖然使用命中或工作階段層級範圍也可以達到相同目的，但如果想要在不對程式碼多做修改的情況下輕鬆完成本例所需設定，就必須選用使用者層級範圍。
設定
該開發商在「管理員」區段中使用下列值定義了「玩家類型」自訂維度：
| 指數 | 3 |
| 名稱 | 玩家類型 |
| 範圍 | 使用者 |
| 有效 | 是 |
收集
和先前的範例一樣，開發商原本就利用畫面瀏覽計算追蹤每個關卡玩過的次數。現在，開發商只需要在使用者初次啟動遊戲時，設定一次玩家類型維度，就能按玩家類型劃分畫面瀏覽計算；如果使用者隨後付費購買完整版遊戲，才需要再設定一次玩家類型維度。
此自訂維度的設定時機是在使用者初次啟動遊戲時：
ga('create', 'UA-XXXX-Y', 'auto');
// 設定索引 3 的自訂維度值。
ga('set', 'dimension3', 'Free' );
// 隨網頁瀏覽命中送出自訂維度值。
ga('send', 'pageview', '/level_1/');
為了在使用者付費購買完整版遊戲時再設定一次自訂維度，開發商加入了以下程式碼：
ga('create', 'UA-XXXX-Y', 'auto');
// 設定索引 3 的自訂維度值。
ga('set', 'dimension3', 'Paid' );
// 隨網頁瀏覽命中送出自訂維度值。
ga('send', 'pageview', '/level_1/');
處理資料
和前幾個例子一樣，系統在處理完所收集到的命中資料之後，就會依據其範圍套用自訂維度值。
假設有位玩家以免費使用者的身分玩了兩次遊戲，接著又以付費使用者的身分玩了一次遊戲，系統收集到的資料看起來就會像這樣：
userId = 5555 Session 1: H2: screen_name=/level_1/ cd3_value=free H3: screen_name=/level_2/ Session 2: H1: screen_name=/level_2/ H2: screen_name=/level_3/ H3: screen_name=/level_3/ Session 3: H1: screen_name=/level_3/ cd3_value=paid H2: screen_name=/level_4/
請注意，在工作階段 1 設定的值「免費」(free) 會套用至工作階段 1 和 2 中的所有命中，直到在工作階段 3 設定新的值「付費」(paid) 為止。
報表
資料處理完畢之後，「玩家類型」自訂維度值會與它們的來源工作階段產生連結，並與未來的所有工作階段和命中資料產生連結。
開發商現在能以「玩家類型」和畫面名稱做為維度，並以畫面瀏覽計算做為指標，製作出所需的報表：
| 玩家類型 | 畫面名稱 | 畫面瀏覽計算 |
|---|---|---|
| 免費 | /level_1/ | 1 |
| 免費 | /level_2/ | 2 |
| 免費 | /level_3/ | 2 |
| 付費 | /level_3/ | 1 |
| 付費 | /level_4/ | 1 |
最後，為了按「玩家類型」劃分畫面瀏覽計算，並確認免費和付費使用者分別玩了多少關卡，該開發商製作了一份以「玩家類型」做為主要維度的自訂報表：
| 玩家類型 | 畫面瀏覽計算 |
|---|---|
| 免費 | 5 |
| 付費 | 2 |
資料顯示，免費使用者玩的關卡數目比付費使用者更多。該開發商運用使用者層級自訂維度，按單一值劃分使用者及其工作階段和命中資料，進而成功取得了這項深入分析數據。
產品層級範圍
接下來我們要從下面的例子來看看，遊戲開發商如何使用產品層級自訂維度，追蹤哪種等級 (低、中或高) 的強化道具收益最好。
開發商原本就以加強型電子商務功能追蹤強化道具的銷售量，但還想進一步知道哪一種等級的強化道具最多人購買。
報表看起來會像這樣：
| 強化道具等級 | 產品收益 |
|---|---|
| 低 | |
| 中 | |
| 高 |
使用自訂維度之前，該開發商已能查看強化道具帶來的產品總收益，卻無法按強化道具的等級劃分收益。
使用產品層級自訂維度之後，每個產品都會產生一個相連結的等級，如此便能從報表看出銷量最好的道具等級 (包括最多玩家查看、點擊和執行其他加強型電子商務動作的道具)。
選擇產品層級範圍的原因
使用者一次可能會購買多種強化道具。本例選用產品層級範圍，是為了讓等級值只連結至與它同時送出的產品，確保每次賣出的強化道具只會與一種等級產生連結。
設定
開發商在 Analytics (分析)「管理」的資源設定部分中，使用下列值定義了「強化道具等級」自訂維度：
| 索引 | 4 |
| 名稱 | 強化道具等級 |
| 範圍 | 產品 |
| 有效 | 是 |
收集
開發商原本就在遊戲中追蹤每筆強化道具銷售。現在，他們直接在產品資料中設定自訂維度值，為每種強化道具建立一個相連結的等級。
在產品資料中加入此維度之後看起來會像這樣：
ga('ec:addProduct', { // 在 productFieldObject 中提供產品詳細資料。
'id': 'P12345', // 產品 ID (字串)。
'name': 'Powerup', // 產品名稱 (字串)。
'category': 'Extras', // 產品類別 (字串)。
'variant': 'red', // 產品變數 (字串)。
'price': '10.00', // 產品價格 (貨幣)。
'quantity': 2, // 產品數量 (數字)。
'dimension4': 'strong' // 產品範圍自訂維度 (字串)。
});
ga('ec:setAction', 'purchase', {
'id': 'T12345',
'revenue': '20.00'
});
ga('send', 'pageview'); // 隨初次網頁瀏覽送出交易資料。
在本例中，開發商直接在產品資訊中設定了自訂維度，以便為此強化道具產生相連結的等級。
處理資料
和前幾個例子一樣，將收集到的命中資料傳送至 Analytics 之後，系統便會處理這些資料，並為與它們同時設定的產品套用自訂維度值。
假設有位玩家在單一工作階段中購買了 3 項強化道具，系統收集到的資料看起來會像這樣：
userId = 5555
Session 1:
H1: product_name=powerup cd4_value=weak
product_name=powerup cd4_value=strong
H2: product_name=powerup cd4_value=weak
請注意，使用產品層級範圍是為了確保每個道具等級值只會連結至與它同時設定的產品。
報表
資料處理完畢之後，由於每項產品都已連結至對應的等級值，開發商便可以製作出一份按「強化道具等級」顯示收益的自訂報表：
| 強化道具等級 | 產品收益 |
|---|---|
| 低 | 20.00 |
| 高 | 10.00 |
這份報表顯示，等級為「低」的強化道具收益最好。
自訂指標
範圍
和自訂維度一樣，自訂指標也可以設定不同的範圍。命中層級的自訂指標會連結至與其同時送出的所有命中層級維度；同樣地，產品層級的自訂指標也只會連結至與其同時送出的產品。以下舉例說明這兩種類型的自訂指標。
命中範圍自訂指標範例
在前幾個例子中，遊戲開發商原本就以畫面瀏覽計算，追蹤每個關卡被玩過的次數。每當使用者想要完成一個關卡，系統生成的每份報表就會用畫面瀏覽計算指標來表示。
不過開發商還想要進一步知道每個關卡的破關率。
為了計算破關率，開發商將使用名為「關卡完成數」的新自訂指標，並與每個關卡的畫面瀏覽計算做比較。
開發商心目中的報表看起來會像這樣：
| 畫面名稱 | 畫面瀏覽計算 | 破關次數 |
|---|---|---|
| /level_1/ | ||
| /level_2/ | ||
| /level_3/ |
選用自訂指標的原因
在大多數情況下，您可以自由選擇使用事件、畫面瀏覽計算和/或自訂指標來追蹤重要指標。然而，若想製作更靈活又一目瞭然的自訂報表來追蹤重要指標，最簡單的方法就是使用自訂指標。
在此範例中，系統必須重複計算每個關卡的畫面瀏覽次數，才能以畫面瀏覽計算的方式追蹤關卡完成數，因此您需要利用其他做法。
雖然也可以單獨使用事件來追蹤關卡完成數，但受限於事件的階層特性，恐怕很難製作出如上所示可在單一維度中同時列出畫面瀏覽計算和關卡完成數的報表。
由於有上述限制，加上開發商十分重視這項指標，因此最簡單的方法還是使用自訂指標來追蹤「關卡完成數」。
設定
開發商在使用者介面的管理部分中，使用下列值定義了「關卡完成數」自訂指標：
| 索引 | 1 |
| 名稱 | 破關次數 |
| 範圍 | 命中 |
| 格式設定類型 | 整數 |
| 有效 | 是 |
收集
開發商原本就以畫面瀏覽計算追蹤玩家進入每個關卡的時機，但還想進一步使用新的自訂指標來追蹤「關卡完成數」。
和自訂維度一樣，自訂指標也是以附加於其他命中資料的參數形式傳送至 Analytics (分析)。為了傳送自訂指標值，開發商還需要傳送其他命中資料以記錄使用者完成某個關卡。在本例中，系統會在玩家破關時觸發一個事件，並將一個自訂指標連結至此事件。
導入結果看起來會像這樣：
ga('create', 'UA-XXXX-Y', 'auto');
// 將關卡完成數指標加 1。
ga('set', 'metric1', 1 );
// 隨事件命中送出自訂指標值。
ga('send', 'event', 'Level', 'completion');
處理資料
假設有位玩家在單一工作階段中玩了三個遊戲關卡。該玩家的資料在處理前看起來可能會像這樣：
userId = 5555 Session 1 H1: type=screen_view screen_name=/level_1/ H2: type=event screen_name=/level_1/ cm1_value=1 H3: type=screen_view screen_name=/level_2/ H4: type=screen_view screen_name=/level_2/ H5: type=screen_view screen_name=/level_2/ H6: type=event screen_name=/level_2/ cm1_value=1 H7: type=screen_view screen_name=/level_3/ H8: type=event screen_name=/level_3/ cm1_value=1
報表
資料處理完畢後，開發商就能以畫面名稱做為維度，並以畫面瀏覽計算、事件總數和關卡完成數做為指標，製作出所需的報表：
| 畫面名稱 | 畫面瀏覽計算 | 事件總數 | 破關次數 |
|---|---|---|---|
| /level_1/ | 1 | 1 | 1 |
| /level_2/ | 3 | 1 | 1 |
| /level_3/ | 1 | 1 | 1 |
由於開發商使用自訂指標追蹤「關卡完成數」，日後將不需要從全部事件中篩選出破關事件。
未來，開發商可以直接使用「關卡完成數」自訂指標，輕鬆產生下列自訂報表：
| 畫面名稱 | 畫面瀏覽計算 | 破關次數 |
|---|---|---|
| /level_1/ | 1 | 1 |
| /level_2/ | 3 | 1 |
| /level_3/ | 1 | 1 |
資料顯示，第 2 關其實比第 1 關和第 3 關更難，因為其破關率只有 33% (依據畫面瀏覽計算得出)。開發商使用自訂指標追蹤關卡完成數，不但輕鬆取得了這項重要指標，還成功製作出能讓所有人一看就懂的報表。
產品範圍自訂指標範例
在前幾個例子中，遊戲開發商已經在追蹤強化道具的每筆銷售，且能將部分指標連結至各筆銷售，例如數量和產品收益。
但該開發商最近開始進行一項促銷活動，為所有使用者提供 $100 美元的抵免額，因此想要評估使用者用這筆抵免額買了哪些強化道具。
為了判斷玩家每次購買產品時使用了多少抵免額，開發商將使用名為「已用抵免額」的新自訂指標。
開發商心目中的報表看起來會像這樣：
| 強化道具等級 | 產品收益 | 已用抵免額 |
|---|---|---|
| 高 | ||
| 中 | ||
| 低 |
設定方式
開發商在「管理員」區段中使用下列值定義了「已用抵免額」自訂指標：
| 指數 | 2 |
| 名稱 | 已用抵免額 |
| 範圍 | 產品 |
| 格式設定類型 | 整數 |
| 有效 | 是 |
收集
和產品層級自訂維度一樣，產品層級自訂指標也是以附加於產品資料中的參數形式，傳送至 Analytics (分析)。
導入結果看起來會像這樣：
ga('ec:addProduct', { // 在 productFieldObject 中提供產品詳細資料。
'id': 'P12345', // 產品 ID (字串)。
'name': 'Powerup', // 產品名稱 (字串)。
'category': 'Extras', // 產品類別 (字串)。
'variant': 'red', // 產品變數 (字串)。
'price': '10.00', // 產品價格 (貨幣)。
'quantity': 2, // 產品數量 (數字)。
'dimension4': 'strong', // 產品範圍自訂維度 (字串)。
'metric2': 5 // 產品範圍自訂指標 (整數)。
});
ga('ec:setAction', 'purchase', {
'id': 'T12345',
'revenue': '20.00'
});
ga('send', 'pageview'); // 隨初次網頁瀏覽送出交易資料。
處理資料
假設有位玩家購買了一些強化道具，在處理前的資料看起來會像這樣：
userId = 5555
Session 1
H1: type=screen_view screen_name=/level_1/
H2: type=screen_view screen_name=/level_2/
product_name=powerup cd4_value=weak cm2_value=5
product_name=powerup cd4_value=strong cm2_value=5
H4: type=screen_view screen_name=/level_2/
product_name=powerup cd4_value=medium cm2_value=1
product_name=powerup cd4_value=weak cm2_value=10
報表
資料處理完畢後，開發商就能以「強化道具等級」做為維度，並以「產品收益」和「已用抵免額」做為指標，製作出所需的報表：
| 強化道具等級 | 產品收益 | 已用抵免額 |
|---|---|---|
| 低 | 20 | 15 |
| 高 | 10 | 5 |
| 中 | 10 | 1 |
資料顯示，大部分的抵免額都用來購買等級為「低」的強化道具，但等級為「中」的強化道具收益最好。
導入方面的注意事項
導入自訂維度或指標時，請注意以下幾點：
修改現有維度或指標
修改現有自訂維度或指標的名稱或範圍時，可能會對您的資料造成下列影響：
- 修改名稱：會對處理後的資料造成影響。您只能用新名稱來存取舊資料。
- 修改範圍：不會對處理後的資料造成影響。只有新資料的處理會採用新範圍。
- 變更有效狀態：系統會依據有效欄位，判斷自訂維度或指標值是否確實經過處理。請注意，有效欄位為
否的自訂維度或指標仍會在報表中列出，但由於值未經處理，因此不會顯示任何相關資料。
設定範圍前應事先做好規劃
決定特定自訂維度的適用範圍之前，請先考慮該自訂維度值的預期變更頻率。如果自訂維度值可能會在同一個工作階段內多次變更 (例如遊戲中的關卡名稱)，請使用命中範圍，並在每次命中之前設定維度值。但如果是不常變更的自訂維度 (例如性別)，則只需要在使用者層級設定一次即可。隨每次命中送出性別值會增加不必要的工作量，而如果設定的自訂維度常會隨著使用者範圍改變，則會誤將多筆命中資料連結至該值。