How to include custom data in reports
Requirements
Custom dimensions and metrics are only available in resources that use Universal Analytics or there is at least one view for the application. Custom dimensions and metrics are supported in the Analytics SDK for Android and iOS versions 2.x and above, as well as in the analytics.js library and on the Measurement Protocol platform.
To use custom dimensions and metrics, you must set up an Analytics account and a tracking code.
Restrictions
Each resource has 20 indexes for personalized dimensions and another 20 for metrics. For Analytics Premium accounts, these limits have been increased to 200 each.
You can't delete a custom setting, but you can turn it off. It is not recommended to reuse custom parameters. After changing the name, scope, and value of a custom parameter, the report might end up as old version, and new. As a result, the data will be inaccurate, and it will be impossible to filter it.
Working with custom dimensions and metrics
Setting
The first step is to define the values for custom dimensions and metrics in the Analytics resource. Each resource can have up to 20 special parameters and the same number of special indicators.
You need to specify the name and other properties of the custom dimension or measure with certain number. The following settings are made for special parameters:
The following settings are made for special key figures:
- Name– under this name the special indicator will appear in the reports.
- Type– determines how the value of the custom measure will be displayed in reports.
- Minimum/Maximum value– minimum and maximum values that will be processed and reported.
- Active– indicates whether the value of the custom key figure will be processed. Inactive custom key figures will appear in reports, but their values will not be processed.
You can create custom dimensions and metrics in the Analytics interface.
Do not change the names and scope of custom dimensions and metrics unless absolutely necessary. .
Data collection
Custom dimension and metric values are passed to Analytics as number-value pairs. This uses the number that you set for the custom dimension or metric during .
Unlike other data, custom dimensions and metrics are passed to Analytics along with other hits (page views, events, transactions). Therefore, their values must be set before calling the tracking code.
For example, the code that sets the value of a special parameter might look like this:
Ga("create", "UA-XXXX-Y", "auto"); // Select value for special parameter with index 1. ga("set", "cd1", "Level 1"); // Passing the value of a special parameter with a call - page view. ga("send", "pageview");
Types of custom key figures
Special measures of type Integer (integer) or Time (time) are expressed using integers, and of type Currency (currency) can be transmitted as fixed decimal values in the local currency.
Data processing
Access scope determines which hits the custom parameter value will apply to, and profile filters determine which hits and their corresponding values will be included in .
Access scope and priorities
The access scope determines which hits will be associated with a specific custom parameter value. There are four such areas: product, appeal, session And user.
- Product– the value applies only to the product for which it was set. This access area is only used for enhanced e-commerce.
- Appeal– the value applies only to the hit for which it was set.
- Session– The value applies to all hits in the session.
- User- The value applies to all hits in the current session and future sessions until it changes or until the option is no longer active.
With this scope, the value of the custom parameter applies only to the product for which it was set. In one hit, several products can be sent and, accordingly, several special parameters with different scopes of the "Products" level.
Access area "Contact"With this scope, the value of a custom parameter applies only to the hit for which it was set (see rice. 1, rice. 2 And rice. 3 below).
Picture 1. The user sends two hits: H1 and H2. The H2 call corresponds to the special parameter CD1 with the value A. This value applies only to H2.Figure 2. The user sends a third hit H3. There is no special parameter associated with H3.
Figure 3 The user sends the fourth hit H4. The H2 call corresponds to the special parameter CD1 with the value B. This value only applies to H4.
Access scope "Session"
When two session-scoped values with the same sequence number are specified in the same session, the first one takes precedence. This value applies to all hits during the session. On Figure 4 you can see that the last value overrides all the previous ones for the special parameter with the same index.
Picture 1. The user sends an H1 hit without a custom parameter value.Figure 2. Within the same session, the user sends an H2 hit with a special parameter CD1 whose value is A. The value A is also used for H1.
Figure 3 The user sends a third hit H3. For H3, the CD1 value is not defined, but within the same session, the value A is automatically used.
Figure 4 The user sends a fourth hit H4 with a new B value for CD1. In all previous hits within the same session, the value of A is changed to B.
Access area "User"
If two custom settings with scope "User" are set in the same session, the last value is given precedence during the current session, and the same value is used in future sessions of that user.
On Figure 2 the value of custom parameter A applies to all hits in session 2, similar to the custom parameter at the session level. However, on Figure 3 the value A applies to hits in the third session as well, because the special parameter CD1 operates at the user level.
Picture 1. There were three hits during the user session: H1, H2, and H3. None of them have special parameters.Figure 2. The user returns to the site and makes three hits in the second session. For H3, the CD1 value is A. It is used for all three hits within the session.
Figure 3 Three hits were registered in the third user session. The value A for the special parameter CD1, set at the user level, is used for all hits within the third session.
Filters
View filters can be applied to custom dimensions and metrics in several ways.
The values of special parameters and indicators are associated with the treatment with which they were transferred. The access area does not play a role in this. If such a hit is filtered out of the view, the custom dimension or metric can also be filtered out.
- Level of circulation. When a case is deleted, the case-level custom parameters and custom metrics associated with it are filtered out.
- Session or user level. Special parameters at the session or user level will not be filtered, even if the hit with which they were sent is filtered. Their values are used for all hits within the session, and if the scope is "User" - for future sessions.
You can also create filters for hits based on the scope of custom settings. For example, if you set a filter to a specific user-level custom setting value, then all user sessions that the value applies to will be dropped.
Reports
Once processed, custom dimensions and metrics appear in Analytics reports.
Custom dimensions and metrics provided in your own reports can be used to create advanced segments. Special parameters can also be added as additional parameters to standard reports.
Examples
The developer recently launched a new game on the market.
The current Analytics code counts a screen view each time a user enters a certain level of play. The developer already knows how many times users run each level, and now he is interested in more complex questions:
- How many times have users played levels of varying difficulty?
- How many levels did users play on different days of the trial period?
- How many levels did the trial and paid app users play?
You can help answer these questions by grouping hits, sessions, and users using custom dimensions and metrics.
In addition, various improvements are sold in the application to simplify game process. Accordingly, in addition to categories and options, the developer needs a separate field to track the popularity of improvements among users.
Access area "Contact"
Let's see how to find out how many times users have played levels of different difficulty using special parameters at the level of appeal.
The developer already tracks screen views and knows how many times users play each level. It remains to find out which level - easy, medium or difficult - gamers most often choose.
Using a special parameter at the level of the appeal, each screen view can be attributed to a certain level of complexity. This will allow you to find out which level of difficulty corresponds to the most views.
Why the level of circulation?
In one session, the user can visit different levels. If the "Hit" action scope is selected, the difficulty value will only be assigned to the screen view with which it was submitted. As a result, each screen view will be associated with a unique level of difficulty.
Setting
The first step is to define a custom setting on the Admin tab in Analytics. Here's what the definition would look like in our case:
Data collection
The developer already tracks the passage of the levels of the game by screen views. To assign a difficulty level to each, you must set the value of the custom parameter before calling the tracking code.
Here's what it will look like:
Ga("create", "UA-XXXX-Y", "auto"); // Select value for special parameter with index 1. ga("set", "cd1", "easy"); // Passing the value of a special parameter with a call - page view. ga("send", "pageview", "/level_1/");
In this example, the custom parameter is set just before the screen view is tracked. Thus, along with viewing the screen, the level of complexity will also be transmitted, according to which the calls will then be grouped in reports.
Data processing
This is what the data might look like for a single player who visited six levels in a session:
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
The "Hit" scope ensures that the difficulty value is associated only with the screen view with which it was sent.
Reports
Because each screen view has been assigned a difficulty level, the developer can now create a report using the screen title and difficulty level as parameters, and the screen views as metrics:
To find out how many times each level has been run, you can create your own report with the main parameter "Difficulty Level", which will group the screen views:
It follows from the report that users preferred the medium level of difficulty. Get this important information the developer was helped by grouping screen views using parameters at the hit level.
Access scope "Session"
Now let's see how to find out how many levels users played on each of the three days of the trial period.
This requires a report like this:
Using a special session-level setting, you can group screen views by day to find out which day users launched the most levels.
Why the session level?
By selecting the "Session" scope, you can group all sessions and hits that belong to the same "Trial Period Day" parameter value.
You can achieve the same result using the Hit scope, but the session level will require minimal code changes to set the value for the Trial Day parameter.
Setting
The special parameter "Day of trial period" is defined in the settings of the Analytics resource as follows:
Data collection
The developer already tracks screen views for each level of the game. To associate a trial day with all screen views in a session, you only need to set the custom parameter value once per session.
Ga("create", "UA-XXXX-Y", "auto"); // Select a value for the special parameter at index 2. var day = getDayOfTrial(); ga("set", "dimension2", day); // Passing the value of a special parameter with a call - page view. ga("send", "pageview", "/level_1/");
A custom session-level setting can be set at any time during a session. However, in our example, it is easier for the developer to do this at the start of the session.
Data processing
Custom parameter values passed to Analytics will be applied to hits according to their scope.
For example, here's what the data would look like for a user who played the game twice on the first day, once on the second, and again on the third:
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
Note that custom parameter values are only passed with one screen view per session.
The Session access scope ensures that the value of the Evaluation Day parameter is associated with all hits in that session, not just the one it was sent with.
Reports
Once processed, session-level custom parameter values will be assigned to all screen views received in a single session. The developer can now create a report based on the "Trial Period Day" and "Screen Title" parameters, as well as the "Screen Views" metric:
By grouping screen views by day, the developer will see how many levels users played on each of the three days of the trial period. To do this, you need to create your own report with the main parameter "Trial period day":
As you can see from the report, the players completed the most levels on the first day, and noticeably less on the second and third. This important information was obtained by grouping sessions and hits by one value using a special parameter at the session level.
Access area "User"
And finally, let's find out how many levels the users of the paid and trial version went through.
This requires a report like this:
Using a special user-level setting, you can link all screen views specific user(both in the current session and in future ones) with the player type.
Why user level?
The "User" access area makes it easy to group all user sessions and hits. This works ideally with values that remain the same for a specific user, such as "Player Type", as in our case.
The same result can be achieved using the hit and session layer, but the user layer is much more convenient because it requires minimal code changes.
Setting
The special parameter "Player Type" is defined in the "Administrator" section as follows:
Data collection
As in the previous examples, the developer already knows the number of screen views for each level of the game. To group these screen views by player type, it is enough to define this special parameter when starting the game and then again when switching to it. paid version.
The developer will need to define a special parameter when the user launches the game:
Ga("create", "UA-XXXX-Y", "auto"); // Select a value for the special parameter at index 3. ga("set", "dimension3", "Free"); // Passing the value of a special parameter with a call - page view. ga("send", "pageview", "/level_1/");
The same special parameter must be set when upgrading to a paid version:
Ga("create", "UA-XXXX-Y", "auto"); // Select a value for the custom parameter at index 3. ga("set", "dimension3", "Paid"); // Passing the value of a special parameter with a call - page view. ga("send", "pageview", "/level_1/");
Data processing
Custom parameter values passed to Analytics will be applied to hits according to their scope.
For example, here's what the data would look like for a user who played the game twice for free and once for a fee:
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/
Note that the free value set in the first session applies to all hits from the first and second sessions because the paid value is only set in the third session.
Reports
The values of the special parameter "Player Type" will be associated with the sessions in which they were set, as well as with all future sessions and hits.
The developer can now generate a report based on Player Type, Screen Title, and Screen Views:
Finally, let's group the screen views by player type to compare the number of levels when playing the free and paid version. To do this, you need to create your own report with the main parameter "Player type":
As you can see, in terms of the number of levels, the preponderance of free version games. This important information was obtained by grouping users and their sessions and hits by one value using a special parameter at the user level.
Access area "Product"
Let's take a look at how we can use special parameters at the product level to find out which upgrades (minimum, medium, or strong) players purchase more often than others.
So, the developer is already tracking the number of upgrade purchases using enhanced e-commerce. It remains to find out which level of improvements are most in demand among users.
The report will look something like this:
Previously, it was possible to find out the total income from the sale of improvements in the game, but without a breakdown by level.
A special parameter at the product level allows you to assign an improvement level to each product. The reports will show which level of upgrades users are most likely to purchase. You can also get similar statistics on the number of views, clicks, and other enhanced ecommerce activities.
Why exactly the level of goods?
The user can purchase several upgrades at the same time. If the "Product" scope is selected, the level value will only be assigned to the product with which it was transferred. As a result, each purchased upgrade will be associated with a unique level.
Setting
The special parameter "Improvement level" is defined in the settings of the Analytics resource as follows:
Data collection
The developer is already tracking purchases of improvements in the game. To assign a certain level to each of them, you need to set the value of a special parameter along with the product data.
Here's how to add a parameter to a product:
Ga("ec:addProduct", ( // Adding product data to the productFieldObject. "id": "P12345", // Product ID (string). "name": "Powerup", // Product name (string) . "category": "Extras", // Product category (string). "variant": "red", // Product variant (string). "price": "10.00", // Product price (currency). " quantity": 2, // Quantity of products (number). "dimension4": "strong" // Special parameter at the product level (string). )); ga("ec:setAction", "purchase", ( "id": "T12345", "revenue": "20.00" )); ga("send", "pageview"); // Send transaction data with original pageview.
In this example, a custom parameter is defined along with the product information and sets the level of the corresponding enhancement.
Data processing
As in the previous examples, custom parameter values passed to Analytics will be applied to hits according to their scope.
This is what the data might look like for a single player who purchased three upgrades in a session:
UserId = 5555 Session 1: H1: product_name=powerup cd4_value=weak product_name=powerup cd4_value=strong H2: product_name=powerup cd4_value=weak
Using the "Product" scope ensures that the parameter value for each improvement is associated only with the product with which it was sent.
Reports
After that, you can create your own income statement for each improvement level:
In this case, the minimum level improvements generated the most revenue.
Special indicators
Scope
Special measures also have their own scope, which allows them to be compared with parameters of the same level. For example, product level indicators are associated only with the product with which they were sent. The following shows two examples of custom indicators.
Special indicator at the circulation level
In the examples above, the developer was tracking screen views for each game level, which is why all reports use the Screen Views metric. It indicates the user's attempt to pass the level.
However, the developer is also interested in the passing rate of each level.
To do this, the developer adds a special indicator "Levels Completed" and then compares their number with the number of screen views for each level.
| Screen title | Screen views | Passed levels |
|---|---|---|
| /level_1/ | ||
| /level_2/ | ||
| /level_3/ |
Why are special metrics needed?
Special metrics, unlike standard ones (events, screen views, etc.), allow you to create more flexible and visual reports with the data that interests you the most.
In our example, completed levels cannot be tracked as screen views, as they will be counted twice for each level.
Although events can be used on their own, due to their hierarchical nature, it would be difficult to create the report shown above by combining screen views and completed levels with a single parameter.
Given these facts and the importance of such information to the developer, it is most convenient to track completed levels as a special indicator.
Setting
A special indicator "Passed levels" can be set in the Analytics settings:
Data collection
The developer already tracks the launch of each level with screen views. Now he is interested in how many levels users go through. To do this, he creates a special indicator.
Custom metrics, like custom dimensions, are passed to Analytics along with hits. Therefore, the developer will need to send an additional call registering the passage of the game level. In this example, at the end of the level, an event will be triggered, with which a special indicator will be associated.
Here's what it will look like:
Ga("create", "UA-XXXX-Y", "auto"); // Increase the completed level by 1. ga("set", "metric1", 1); // Passing the value of a special parameter with an event call. ga("send", "event", "Level", "completion");
Data processing
Before processing, data about one user who launched three levels of the game in one session will look like this:
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
Reports
You can now create a report with Screen Title and Screen Views, Total Events, and Levels Completed:
These data indicate that the second level is actually more difficult than the first and third, with a passing rate of only 33%. By tracking the passage of levels using a special indicator, the developer can easily get the data he is interested in in the form of simple, visual reports.
Special key figure at item level
In the examples above, the developer keeps track of upgrade purchases and can associate various metrics with each purchase, such as quantity or revenue generated.
For this, a special indicator "Bonuses spent" is used.
Here is the report for this:
Setting
The special parameter "Spent bonuses" is defined in the "Administrator" section:
Data collection
Custom metrics, like custom dimensions, are passed to Analytics along with product data.
Here's what it will look like:
Ga("ec:addProduct", ( // Adding product data to the productFieldObject. "id": "P12345", // Product ID (string). "name": "Powerup", // Product name (string) . "category": "Extras", // Product category (string). "variant": "red", // Product variant (string). "price": "10.00", // Product price (currency). " quantity": 2, // Quantity of products (number). "dimension4": "strong", // Custom product-level parameter (string). "metric2": 5 // Custom product-level metric (integer). ) ); ga("ec:setAction", "purchase", ( "id": "T12345", "revenue": "20.00" )); ga("send", "pageview"); // Send transaction data with original pageview.
Data processing
Before processing, the data for a single player who has purchased multiple upgrades will look like this:
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 cm4_value=5 product_name=powerup cd4_value=strong cm4_value=5 H4: type=screen_view screen_name= /level_2/ product_name=powerup cd4_value=medium cm4_value=1 product_name=powerup cd4_value=weak cm4_value=10
Reports
Now you can create a report with the "Improvement Level" parameter, as well as the "Product Revenue" and "Points Spent" indicators:
Obviously, players prefer to spend bonuses on minimal upgrades, and mid-level upgrades bring the most profit to the developer.
Notes
Here are a few things to keep in mind when working with custom dimensions and metrics.
Editing an Existing Dimension and Metric
If you change the name of an existing custom dimension or measure, it will affect your data in the following ways:
- Title editing affects already processed data: you can only get it under a new name.
- Changing the scope does not affect processed data: the new scope will only apply to new data.
- Change of status. The status field determines whether the values of a custom dimension or measure will be processed. If the status is inactive, they will appear in reports, but there will be no data for them.
Choosing the Right Scope
When choosing a scope for a custom parameter, consider how often the value will change. If this will happen multiple times per session, as is the case with the game level, select the hit level and set the value before each hit. If the value does not change during the session, as in the case of age, then the custom parameter need only be set once at the user level. Always choose the correct scope to avoid mistakes.
Was this information helpful?
How can this article be improved?
4 User Options
Review
Sometimes you may want to perform agent validation which is not predefined in Zabbix. In this case, custom parameters will come to your rescue.
You can write a command that will return the data you need and add this command as a user parameter to the agent's configuration file ("UserParameter" configuration parameter).
The user parameter has the following syntax:
UserParameter=<ключ>,<команда>
As you can see, the user parameter also contains a key. The key will be required when setting up the item. Enter a key of your choice that can be easily referenced (must be unique within the host). Restart the agent.
IN operating systems UNIX interpreter used command line /bin/sh. User parameters are subject to the timeout of checks per agent; if the timeout is exceeded, the process created by the user parameters will be terminated.
See also:
Examples of Simple Custom Parameters
Simple command:
UserParameter=ping, echo 1
The agent will always return "1" for an item with the key "ping".
More complex example:
UserParameter=mysql.ping,mysqladmin -uroot ping|grep -c alive
The agent will return "1" if the MySQL server is available, "0" otherwise.
Flexible user options
Flexible user options allow options with the specified key. In this case, flexible user options can be the basis for creating multiple data items.
Flexible user options have the following syntax:
UserParameter=key[*],command
| Parameter | Description |
|---|---|
| Key | The unique key of the item. [*] specifies that the key can accept parameters from brackets. The parameters are specified when setting up the item. |
| Team | The command that is executed to get the value of the key. Only for flexible custom options: You can use references to positions $1…$9 to refer to the corresponding parameter in the item key. Zabbix parses the parameters enclosed in the item key and replaces $1,…,$9 in the command accordingly. $0 will be replaced by the original instruction (before expanding $0,…,$9) to be executed. Position references are interpreted by the Zabbix agent whether they are enclosed in double (") or single ("") quotes. To use position references without modification, specify a double dollar sign - for example, awk "(print $$2)". In this case, $$2 will actually turn into $2 when the command is executed. |
Position references starting with a $ sign are searched and replaced by Zabbix agent only in case of flexible user options. In the case of simple custom options, such references are skipped and therefore no escaping of any $ signs is required.
By default, some characters are not allowed in user settings. See the UnsafeUserParameters documentation for complete list such characters.
Example 1
A very simple example:
UserParameter=ping[*],echo $1
We can create an unlimited number of items to monitor anything by specifying ping[whatever] in this format.
ping - will always return '0'
ping - will always return 'aaa'
Example 2
Let's add more meaning!
UserParameter=mysql.ping[*],mysqladmin -u$1 -p$2 ping | grep -c alive
This parameter can be used to monitor the availability of databases MySQL data. We can pass a username and password as parameters:
mysql ping
Example 3
command result
The output of the command is standard output plus standard error.
A text data element (character, log, or text information types) will not become unsupported if an error is printed on standard output.
Custom options that return text (character, log, text information types) can return a space. In case of an erroneous result, the item will become unsupported.
) are excellent for most users. However, you can also use custom delivery options in an ESA solution.
Open the ESA Management Console on the host computer, navigate to the domain node (acswin2012.com in our example), click Advanced Settings ( Additional settings), and then click Delivery Options.
Here you can specify the path to the user script (or find it by clicking the button) with which you want to prepare or deliver the OTP password. Click to display a list of parameters that can be passed to a custom script. For example, to deliver a one-time password (OTP), you need to use the parameter. It is also possible to pass a custom string to the script, which must be specified for this (see parameter1 in the screenshot above).
Sample Script - Password Delivery OTP by email
Mandatory conditions:
need to know the SMTP gateway settings Email with which to send email A containing the OTP password;
need a custom script for sending emails;
we need a custom script in BAT (.bat) format that is pathed in the ESA Management Console (see screenshot above) and calls our custom script that sends an email;
for each user who has two-factor authentication (2FA) enabled and who receives one-time passwords (OTP passwords) by email, you must specify an email address in the E-mail field on the General tab when viewing details of such users in the Active Directory Users and Computers management interface.
Sample Python script for sending email: we named this file sendmail.py :
import sys, smtplib
server = smtplib.SMTP(" smtpserver : port" )
server.starttls()
server.login("username","password")
server.sendmail(sys.argv , sys.argv, "Subject: OTP is "+sys.argv)
server.quit()
NOTE. In the sample Python script above, the options smtpserver:port , username and password should be replaced with the appropriate parameters SMTP.
A sample .bat script for calling the sendmail.py script and passing it the required parameters: we named this file CustomMail.bat :
c:\Python\python.exe c:\work\sendmail.py %1 %2
NOTE. To run this sample script, you need to install the Python library on the primary computer (where the solution is installed ESA core component ) and know the path to the python.exe file.
In the Sending OTP by field, we specify the path leading to our CustomMail.bat script, select the required options, such as (E-mail addresses) and , and then click Save.
Provisioning (delivery of the mobile application) can be configured in the same way with the required parameters (Phone) and (URL).
NOTE. : Compared to SMS delivery (or using a provisioned mobile app), perform password distribution OTP using email is not as secure as the email can be read on any user's device. This method cannot confirm that the target recipient owns the registered phone (phone number).
Custom parameters and indicators allow you to send the necessary data to Google Analytics specifically for your tasks. For example, they can be used to upload important metrics such as or . You can compare different segments with each other, for example, users who logged in to the site and did not log in, page authors, get values when filling out fields of various forms, and the like, depending on the specifics of your site.
How to add a custom dimension or metric?
- Open section "Administrator" and select the required resource.
- In column "Resource" click "Custom Definitions"> (or indicators).
- Click the button "+ Special Parameter"(or index).
- Specify its name.
- When adding a custom dimension or metric, select "Scope" from the following options: "Hit", "Session", "User", "Product"(more on scope).
- Also, when adding a custom measure, select "Format Type" from the following options: "Integer", "Currency" or "Time".
- Check box "Active" to start collecting data and add a dimension or measure to reports. If you do not want to activate the created setting, clear this checkbox.
- Click the button "Create".
How to submit to GA
Sending data via tracking code
// Sending a custom parameter when viewing a page ga("send", "pageview", ( "dimension1": "My parameter" )); // Send custom metric along with event ga("send", "event", "category", "action", ( "metric1": 123 ));
Sending data via GTM
If Google Analytics is implemented on the site through GTM (which is recommended), then during the activation of the tag, you can pass custom parameters or metrics. To do this, go to "Additional settings", provide an index and a value.
Sending data via Measurement Protocol
A guide to using the Measurement Protocol is described in the article "" in which the Client ID of the user is passed to the user parameter cd14.
Restrictions
In each resource, you can add 20 custom parameters and 20 more indicators.
You can't delete custom dimensions or metrics, but you can turn them off.
Case for bypassing restrictions in 20 parameters and indicators
There are tasks when you need to track the completion of a calculator or any form on a site with a large number of fields. Entering a separate parameter for each field is not an option, since you can run into a limit.
The way out of this situation is to create two parameters: the first for the name of the form fields, and the second for the values entered into the fields.
Accordingly, we pass the values of the form fields to the "Calculator field - value", and the name of the field itself to the "Calculator field - name". And when, let's say, we need to display all the values of the "City" field, we simply set the filter for the special indicator "Calculator field - name" equal to the name of the field.
Loading...