Custom Dimensions can be used as which of the following?
Secondary dimensions in Standard reports
Primary dimensions in Custom Reports
Secondary dimensions in Custom Reports
All of the above
Explanation:
Custom dimensions can appear as primary dimensions in Custom Reports. You can also use them as Segments and secondary dimensions in standard reports.
Read more here: https://support.google.com/analytics/answer/2709828
Custom dimensions and metrics allow you to combine Analytics data with non-Analytics data, e.g. CRM data. For example:
If you store the gender of signed-in users in a CRM system, you could combine this information with your Analytics data to see Pageviews by gender.
If you’re a game developer, metrics like “level completions” or “high score” may be more relevant to you than pre-defined metrics like Screenviews. By tracking this data with custom metrics, you can track progress against your most important metrics in flexible and easy-to-read custom reports.
Custom dimensions can appear as primary dimensions in Custom Reports. You can also use them as Segments and secondary dimensions in standard reports.
Prerequisites
Custom dimensions and metrics are only available for properties that have either been enabled for Universal Analytics or contain at least one app reporting view. Custom dimensions and metrics are supported by the Google Analytics SDKs for Android and iOS v2.x or higher, analytics.js, and the Measurement Protocol.
Custom dimensions and metrics require additional setup in your Analytics account and in your tracking code. Once you complete both steps of the setup, you can use them in your reports.
Limits and caveats
There are 20 indices available for different custom dimensions and 20 indices for custom metrics in each property. 360 accounts have 200 indices available for custom dimensions and 200 for custom metrics.
Custom dimensions cannot be deleted, but you can disable them. You should avoid trying to reuse custom dimensions. When you edit the name, scope, and value of a custom dimension, both the old and the new values can be paired with the either the old or the new dimension name. This conflates data in your reports in a way that cannot be accurately separated with a filter.
Lifecycle of custom dimensions and metrics
The lifecycle of a custom dimension or metric has four stages:
Configuration – you define your custom dimensions and metrics with an index, a name, and other properties like scope.
Collection – you send custom dimension and metric values to Analytics from your implementation.
Processing – your data is processed using your custom dimension and metric definitions and any reporting view filters.
Reporting – you build new reports using your custom dimensions and metrics in the Analytics user interface.
Configuration
Before you can send custom dimension and metric values to Analytics, they must first be defined in an Analytics property. Each Analytics property has 20 available indices for custom dimensions, and another 20 indices available for custom metrics.
When you define a custom dimension or metric, you specify its name and other configuration values at a particular index. Custom Dimensions have the following configuration values:
Name – the name of the custom dimension as it will appear in your reports.
Scope – specifies to which data the custom dimension or metric will be applied. Learn more about Scope.
Active – whether the custom dimension or metric value will be processed. Inactive custom dimensions may still appear in reporting, but their values will not be processed.
Custom metrics have the following configuration values:
Name – the name of the custom metric as it will appear in your reports.
Type – determines how the custom metric value will be displayed in reports.
Minimum / Maximum Value – the minimum and maximum values that will be processed and displayed in your reports.
Active – whether the custom metric value will be processed. Inactive custom metrics may still appear in reporting, but their values will not be processed.
Custom dimensions and metrics can be defined in the Analytics user interface.
Once you define a custom dimension or metric, avoid editing name or scope when possible. See Implementation Considerations to learn more about how changes to these values can affect your reporting.
Collection
Custom dimension and metric values are sent to Analytics at collection time as a pair of index and value parameters. The index parameter corresponds to the index of the custom dimension or metric defined in the Configuration phase.
Unlike other types of data, custom dimensions and metrics are sent to Analytics as parameters attached to other hits, like pageviews, events, or ecommerce transactions. As such, custom dimension or metric values need to be set before a tracking call is made in order for that value to be sent to Analytics.
For example, to set a custom dimension value, your code might look like this:
ga(‘create’, ‘UA-XXXX-Y’, ‘auto’);
// Set value for custom dimension at index 1.
ga(‘set’, ‘dimension1’, ‘Level 1’);
// Send the custom dimension value with a pageview hit.
ga(‘send’, ‘pageview’);
Custom Metric Types
Custom metrics with a type of Integer or Time should be sent using integers, while custom metrics with a type of Currency may be sent as fixed decimal values appropriate to the local currency.
Processing
When custom dimensions are processed, scope determines to which hits a particular custom dimension value will be applied, while view filters determine which hits and their associated values are ultimately included in Reporting.
Scope and Precedence
Scope determines which hits will be associated with a particular custom dimension value. There are four levels of scope: product, hit, session, and user:
Product – value is applied to the product for which it has been set (Enhanced Ecommerce only).
Hit – value is applied to the single hit for which it has been set.
Session – value is applied to all hits in a single session.
User – value is applied to all hits in current and future sessions, until value changes or custom dimension is made inactive.
Product-level scope
When a custom dimension has product-level scope, the value is only applied to the product with which the value is set. Because multiple products can be sent in a single hit, multiple product-level scoped custom dimensions can be sent in a single hit.
Hit-level scope
When a custom dimension has hit-level scope, the value is only applied to the hit with which the value was set. This is demonstrated in Figure A, Figure B, and Figure C below:
Figure A: User sends two hits (H1, H2). H2 has a CD1 value of A. That value is only applied to H2.
Figure B: User sends a third hit (H3). H3 has no CD value.
Figure C: User sends a fourth hit (H4). H4 has a CD1 value of B. That value is only applied to H4.
Session-level scope
When two values with session scope are set at the same index in a session, the last value set gets precedence and is applied to all hits in that session. In Figure D below, the latest value set overwrites any previous values for that index:
Figure A: User sends a hit (H1) with no CD value.
Figure B: In the same session, user sends a second hit (H2) with CD1 value set to A. Session scope causes value A to also be applied to H1.
Figure C: User sends a third hit (H3). Although no CD1 value is sent with H3, session scope causes value A to be automatically applied to H3.
Figure D: User sends a fourth hit (H4) with a new CD1 value B. Session-scope applies value B to all the hits in the session, overwriting value A in the previous hits.
User-level scope
Lastly, if two user-scoped custom dimension values are set within the same session, the last value set gets precedence for the current session, and is applied to future sessions for that user.
In Figure B below, CD value A is applied to all hits in session 2, just like a session-level CD. However in Figure C, unlike with session-level scope, the CD value A continues to be applied to hits in the third session due to CD1 having user-level scope:
Figure A: User shas a session with three hits (H1, H2, H3). No CD values are set.
Figure B: The same user returns and has another session, with three more hits. CD1 value is set to A on H3. CD1 value is then applied to all hits in session.
Figure C: User returns for a third session with three more hits. CD1’s user-level scope causes value A to be applied to all hits in session 3.
Filters
View filters can interact with custom dimensions and metrics in several ways.
Custom dimensions and metric values are each associated with the hit with which they were received, regardless of their scope. If that hit is filtered by a view filter, the custom dimension or metric may also be filtered, depending on its scope:
Hit-scope: Both Custom dimensions with hit scope and custom metrics will be filtered if the hit they are associated with was also filtered.
Session or User-scope: User or session-scoped custom dimensions will not be filtered even if the hit they were attached to is filtered. Their values will still be applied to all hits in the current session, as well as future sessions if the dimension has user scope.
Custom dimensions can also be used to construct view filters. This will cause hits to be filtered according to the scope of the custom dimension. For example, filtering on a user-scoped custom dimension value would filter current and future sessions from the set of users associated with that value.
Reporting
After the collection, configuration, and other processing stages of the pipeline are complete, custom dimensions and metrics become available via the user reporting interface.
Custom dimensions and metrics are available in custom reports and available for use with advanced segments. Custom dimensions can also be used as secondary dimensions in standard reports.
Examples
The following examples show how custom dimensions and metrics can be used by a game developer to learn about player behavior.
A game developer has recently released a new game.
The current Analytics implementation tracks a screen view each time a user plays a level. The developer already knows how many times each level is played. Now they want to answer these more advanced questions:
How many times are easy levels played versus medium or hard levels?
How many levels are played for each day in a 3-day free trial?
How many levels are played by users in the trial versus users who have paid for the game?
To answer these questions, custom dimensions are used to create new groupings of hits, sessions, and users.
Additionally, the developer is selling some extra features to enhance the user experience, such as “powerups”. The developer is already using the category and variant fields, but wants an extra field to measure the strength of the powerup purchased. This way, the developer would be able to determine if certain powerup strengths were more popular than others.