User parameters. Custom definitions (custom dimensions and metrics). Sending data via tracking code

) are excellent for most users. However, the ESA solution can also use custom delivery parameters.

Open the ESA Management Console on your host computer, navigate to your domain host (acswin2012.com in our example), click Advanced Settings, and then click Delivery Options.

Here you can specify the path to the custom 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 the custom script. For example, to deliver a one-time password (OTP), you need to use the parameter. In addition, you can pass a custom string into the script, which you need to specify for this (see parameter1 in the screenshot above).

Sample Script - Password Delivery OTP by email

Required conditions:

you need to know the SMTP parameters of the email gateway with which you need to send an email containing the OTP password;

need a custom script for sending emails;

We need a custom script in BAT (.bat) format that is set to a path in the ESA Management Console (see screenshot above) and that calls our custom script that sends the email;

For each user who has two-factor authentication (2FA) enabled and receives one-time passwords (OTP passwords) via email, you must enter an email address in the E-mail field on the General tab when viewing details for such users in the Active Directory Users and Computers management interface.

Sample Python script for sending email: We called 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 parameters smtpserver:port , username and password should be replaced with the appropriate parameters SMTP.

Sample .bat script to call the sendmail.py script and pass it the necessary parameters: We called this file CustomMail.bat :

c:\Python\python.exe c:\work\sendmail.py %1 %2

NOTE. To work with this sample script, you need to install the Python library on your host machine (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 necessary parameters, for example (Email addresses) and , and then click Save.

Provisioning (mobile app delivery) can be configured in the same way using the required parameters (Phone) and (URL).

NOTE. : Compared to SMS delivery (or using a prepared mobile application), distribute passwords 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, with their help you can upload such important indicators as or to Google Analytics. You can compare different segments with each other, for example, users who are logged in and not logged in, page authors, get values ​​when filling out fields in various forms, and the like, depending on the specifics of your site.

How do I add a custom dimension or metric?

1. Open section "Administrator" and select the required resource.
2. In column "Resource" click "Custom Definitions"> (or indicators).
3. Click the button "+ Special parameter"(or indicator).
4. Indicate its name.
5. When adding a custom dimension or metric, select "Scope" from the following options: "Hit", "Session", "User", "Product"(more about scope).
6. Also, when adding a custom indicator, select "Format Type" from the following options: "Integer", "Currency" or "Time".
7. Check the box "Active" to start collecting data and adding a dimension or metric to your reports. If you do not want to activate the created setting, clear this check box.
8. Click the button "Create".

Methods for sending to GA

Sending data via tracking code

// Send a custom parameter when viewing a page ga("send", "pageview", ( "dimension1": "My parameter" )); // Send a custom metric along with an event ga("send", "event", "category", "action", ( "metric1": 123 ));

Sending data via GTM

If Google Analytics is implemented on the site via GTM (which is recommended), then during tag activation, you can transfer custom parameters or metrics. To do this, go to "Additional settings", specify the index and value.

Sending data via Measurement Protocol

A guide to using the Measurement Protocol is described in the article “”, in which the user’s Client ID is passed to the cd14 user parameter.

Restrictions

In each resource you can add 20 custom parameters and another 20 indicators.

You can't delete custom dimensions or metrics, but you can turn them off.

Case for bypassing restrictions of 20 parameters and indicators

There are tasks when you need to track the completion of a calculator or some form on a website with a large number of fields. It is not an option to create a separate parameter for each field, since you may run into a limit.

The way out of this situation is to create two parameters: the first for the names of the form fields, and the second for the values ​​​​entered in the fields.

Accordingly, we transfer the values ​​of the form fields to the “Calculator field - value”, and the field name itself to the “Calculator field - name”. And when, for example, 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 field name.

January 29, 2018

There are a large number of standard ones in Google Analytics: source/medium, city, device type, sessions, bounce rate, revenue, transactions, cost, conversion rate, browsers, gender, age, etc.

However, in practice there are often tasks in which it is necessary to monitor additional parameters of user interaction that go far beyond the scope of the current functionality.

For example, for an online store, it is necessary to correctly calculate profitability taking into account the cost of goods. There is no indicator in Google Analytics "Product cost". Or compare statistics for each of the authors of your blog or news resource to see all the necessary information in one table (how much traffic the articles of an individual author bring, how many of his articles are read on average per session, bounce rate, etc.). There is no Author option in Analytics. Or we have the task of identifying a “sales leader” based on online consultations on the site and rewarding him with an additional bonus for the revenue made this month. Standard Google Analytics reports do not contain such data.

All of the above examples and a number of others can be solved using special parameters and indicators.

Custom definitions (custom dimensions, custom dimensions and metrics, custom dimensions, etc) are variables that are not included in standard Google Analytics reports. They are part of Universal Analytics and are created manually by users to solve their own problems.

Using them, you can import data that Google Analytics does not collect by default: data from phone calls, from CRM, from authorized users, etc. and associate them with specific GA metrics.

Custom definitions are created at the resource level and have a number of limitations:

• no more than 20 special parameters and 20 special indicators are available for each resource;
• special parameters cannot be deleted, they can only be disabled;
• they are only available in those resources that use Universal Analytics. With the old library js will not work.

To add a custom dimension in Analytics:

• open the section "Administrator" and select the required resource;
• in the column "Resource" click "Custom Definitions - Custom Parameters" or "Custom Metrics".

Resource - Custom Definitions

• click the button “+ Special parameter” (or indicator)

Creating a Custom Metric

The following settings are specified for special parameters:

• Name– the name of the special parameter in Google Analytics reports;
• Scope– determines which hits the special parameter will be applied to (Hit, Session, User and Product).
• Active– indicates whether the value of the special parameter will be processed. Inactive custom parameters will appear in reports, but their values ​​will not be processed.

The scope determines which hits will be associated with a specific custom parameter value. There are four in total: appeal, session, user And product:

• Appeal (hit)– the value applies only to the request for which it was specified;
• Session– the value applies to all calls in the session (until 30 minutes of user inactivity have passed);
• User– the value applies to all hits in the current session and future sessions until it changes or until the parameter is no longer active;
• Product– the value will be applied to a specific product on your site (requires installation of advanced e-commerce).

Adding a Custom Parameter

Appeal (hit): session, % of new sessions, bounce rate, average session duration.

Examples of standard metrics with scope Product: average price, unique purchases, transactions, return amount for the product,

The following settings are specified for special indicators:

• Name– the name of the special indicator in Google Analytics reports;
• Scope— determines which requests a special indicator (Hit or Product) will be applied to.
• Formatting type– special indicator format (integer number, currency, time is specified in seconds, displayed in reports as HH:MM:SS);
• Maximum/minimum value (optional)– minimum and maximum values ​​that will be processed and entered into reports;
• Active– indicates whether the value of a special indicator will be processed. Inactive custom measures will appear in reports, but their values ​​will not be processed.

Adding a Custom Metric

In addition to these settings, special indicators and parameters have several additional characteristics:

Additional characteristics of special indicators

• Index – a unique identifier that Google Analytics uses to distinguish one dimension/metric from another. The value is an integer, from 1 to 20. This is the number you will use in the library js to send data about a specific indicator or parameter;
• Last change - The date the custom dimension/metric was created or modified.

Note: As we learned earlier, not all standard parameters and indicators can be used with each other. This limitation also applies to custom definitions.

There are several ways to send data to Google Analytics:

• via tracking code;
• via Google Tag Manager;
• through .

The last two methods are deliberately omitted within the framework of this material; a separate series of articles will be devoted to them. Let's create a custom parameter:

Create a custom parameter

After saving the basic settings, a code fragment will become available, which will need to be inserted into certain pages of the site or application.

The number “1” (underlined in green) is the unique index that Analytics uses to distinguish one metric from another. Under no circumstances should it be changed when adding code to site pages, since no data will be collected.

Google Analytics offers us a choice of two codes for the parameter:

1. global library site tag gtag.js

Instructions for setting up custom metrics using gtag.js presented at the link: https://developers.google.com/analytics/devguides/collection/gtagjs/custom-dims-mets

1. traditional JavaScript (for resources that use Universal Analytics)

Pass special parameters and indicators with all requests on this page you can use the command set(as in the example above).

ga('set', 'dimension1', dimensionValue);

• ga(‘set')– this is a command to set a parameter;
• dimension– service designation of the parameter in Google Analytics, it cannot be changed;
• 1 – unique index;
• dimensionValue– value of the special parameter.

Set values ​​using command set For both parameter and indicator you can do this:

Tracking code using the set command

Similar variables in a special indicator, only instead of dimension And dimensionValue another function word is used metric. metricValue can be an integer, currency and time in seconds.

Tracking code for custom metrics

Pass special parameters for type inversion page view (pageview) you can do this:

Code for a page view type request

Pass special indicators for type invocation event (event) can be done as follows:

Code for event type call

In the first option (using the command set) the value is sent for all calls that will be called after the value is set. In the second option, values ​​are transmitted only for those calls where they are listed.

Learn more about custom dimensions and metrics in the official Google Developer Help.

Important! Line ga ('set') is always placed before the page view is sent, and setting any value via set must be executed before calling send.

As an example, let's create a special indicator "Product cost" for our online store and import data about it using a table.csv. In this case, advanced e-commerce must be installed on the site.

Its settings are as follows:

• Name: cost of goods
• Scope: product
• Formatting type: currency (decimal format)
• Maximum/minimum value: do not fill out
• Status: active

Go to the section "Data Import". Let's create a new set of available types and select “Import of extended data – Product data”.

Data import - Product data

Enter a name and select a view that will use the data from this set.

Purpose of the pair “Key - Imported data”

To import product cost data, you need two parameters in pairs "key-value":

• "Product ID"- key specified by the system by default based on the selected data set type;
• "Product cost"— a special indicator that must be selected from the drop-down list.

Analytics asks us to redefine the data (overwrite it). If selected YES, then it will use the imported data, that is, the old ones cannot be restored.

How to include non-standard data in reports

Requirements

Custom dimensions and metrics are only available in properties that use Universal Analytics or have 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 later, as well as in the analytics.js library and the Measurement Protocol platform.

To use custom dimensions and metrics, you must set up an Analytics account and tracking code.

Restrictions

Each resource has 20 indexes available for personalized parameters and another 20 for indicators. For Analytics Premium accounts, these limits are increased to 200 each.

You can't remove 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 may contain both the old version and the new one. As a result, the data will be inaccurate and it will be impossible to filter it.

Working with custom dimensions and metrics

Settings

First, you need to define the values ​​of the custom dimensions and metrics in your 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 a special parameter or indicator with a specific number. The following settings are specified for special parameters:

The following settings are specified for special indicators:

• Name– the special indicator will appear in reports under this name.
• Type– determines how the value of a special indicator will be displayed in reports.
• Minimum/maximum value– minimum and maximum values ​​that will be processed and entered into reports.
• Active– indicates whether the value of a special indicator will be processed. Inactive custom measures 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 special parameters and indicators unless absolutely necessary. .

Data collection

Values ​​for custom dimensions and metrics are sent to Analytics as number-value pairs. This uses the number you specified for the custom dimension or metric during .

Unlike other data, custom dimensions and metrics are sent to Analytics along with other hits (page views, events, transactions). Therefore, their values ​​must be set before calling the tracking code.

For example, this is what the code that sets the value of a special parameter might look like:

Ga("create", "UA-XXXX-Y", "auto"); // Selecting a value for a special parameter with index 1. ga("set", "cd1", "Level 1"); // Passing the value of a special parameter with a request - page view. ga("send", "pageview");

Types of special indicators

Special measures of type Integer or Time are expressed using integers, while special measures of type Currency can be expressed as fixed decimal values ​​in the local currency.

Data processing

The access scope determines which hits this special parameter value will be applied 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 in total: product, appeal, session And user.

• Product– the value applies only to the product for which it was specified. This access area is used for advanced electronic commerce only.
• Appeal– the value applies only to the request for which it was specified.
• 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 the setting is no longer active.

With this scope, the value of the special parameter applies only to the product for which it was set. Several products and, accordingly, several special parameters with different scopes of the “Products” level can be sent in one request.

With this scope, the value of the special parameter applies only to the hit for which it was specified (see rice. 1, rice. 2 And rice. 3 below).

Figure 2. The user submits a third hit H3. There is no special parameter associated with H3.

Figure 3. The user sends the fourth hit H4. The H2 access has a special parameter CD1 with the value B. This value applies only to H4.

Access area "Session"

When two values ​​with the scope "Session" and 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 previous ones for a special parameter with the same index.

Figure 2. In the same session, the user sends a hit to H2 with a special parameter CD1 whose value is A. The value A is also used for H1.

Figure 3. The user submits a third hit H3. For H3, the value CD1 is not defined, but the value A is automatically used within one session.

Figure 4. The user sends a fourth H4 hit with a new B value for CD1. In all previous calls within the same session, the value of A is changed to B.

Access area "User"

If two special parameters with a scope of "User" are specified in the same session, the last value is given priority during the current session, and the same value is used in future sessions of that user.

On Figure 2 the value of special parameter A is applied to all hits in session 2, similar to the special parameter at the session level. However, on Figure 3 the value A also applies to hits in the third session because the special parameter CD1 operates at the user level.

Figure 2. The user returns to the site and makes three calls in the second session. For H3, the value of CD1 is A. This is used for all three hits within the session.

Figure 3. Three hits were logged in the user's third session. The value A for the custom parameter CD1, set at the user level, is used for all hits in 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 transmitted. The access area does not play a role in this case. If such a hit is filtered out of the view, the custom dimension or metric can also be filtered out.

1. Treatment level. When you delete a case, the case-level custom dimensions and custom metrics associated with it are filtered out.
2. Session or user level. Session- or user-level custom parameters will not be filtered, even if the hit they were passed on is filtered. Their values ​​are used for all calls within the session, and with the scope "User" - also in future sessions.

You can also create filters for hits based on the scope of special parameters. For example, if you set a filter to a specific user-level custom parameter value, all user sessions that include that value will be discarded.

Reports

After processing, custom dimensions and metrics appear in Analytics reports.

Custom dimensions and metrics presented in your own reports can be used to create advanced segments. Custom dimensions can also be added as additional dimensions to standard reports.

Examples

The developer recently released a new game to the market.

The current Analytics code counts a screen view every time a user reaches a certain level of the game. The developer already knows how many times users run each level, and now he is interested in more complex questions:

1. How many times have users played levels of varying difficulty?
2. How many levels did users play on different days of the trial period?
3. How many levels did trial and paid app users play?

Grouping hits, sessions, and users using specific dimensions and metrics will help answer these questions.

In addition, the application sells various kinds of improvements to simplify the gameplay. Accordingly, in addition to categories and options, the developer needs a separate field to track the popularity of improvements among users.

Access area "Appeal"

Let's look at how to use special parameters at the hit level to find out how many times users have played levels of different difficulties.

The developer already tracks screen views and knows how many times users launch each level. It remains to find out which level – simple, medium or difficult – is most often chosen by gamers.

Using a specific hit-level parameter, each screen view can be assigned to a specific difficulty level. This will let you know which difficulty level has the most views.

Why exactly the level of circulation?

During one session, the user can visit different levels. If the scope of action is "Handling", the difficulty value will only be assigned to the screen view with which it was passed. As a result, each screen view will be associated with a unique level of difficulty.

Settings

The first step is to define a custom setting in the Admin tab of Analytics. Here's what the definition would look like in our case:

Data collection

The developer already tracks the completion of game levels by screen views. To assign a difficulty level to each of them, you must set a special parameter value before calling the tracking code.

This is what it will look like:

Ga("create", "UA-XXXX-Y", "auto"); // Selecting a value for a special parameter with index 1. ga("set", "cd1", "easy"); // Passing the value of a special parameter with a request - page view. ga("send", "pageview", "/level_1/");

In this example, the custom parameter is set just before screen view tracking. Thus, along with viewing the screen, the difficulty level will be transmitted, by which the requests will then be grouped in reports.

Data processing

This is what the data might look like for one player who has played 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 only associated with the screen view with which it was sent.

Reports

Since each screen view has been assigned a difficulty level, the developer can now create a report using the screen name and difficulty level as parameters, and screen views as metrics:

To find out how many times each level was launched, you can create your own report with the main parameter “Difficulty Level”, by which screen views will be grouped:

The report shows that users preferred the medium difficulty level. Grouping screen views using hit-level parameters helped the developer obtain this important information.

Access area "Session"

Now let's look at how to find out how many levels users played on each of the three days of the trial period.

To do this you need the following report:

Using a custom session-level setting, you can group screen views by day to find out which day users launched the most levels.

Why session level?

By selecting the Session scope, you can group all sessions and hits related to the same Trial Day value.

The same result can be achieved using the Case action scope, but the session level requires minimal code changes to set the Trial Day value.

Settings

The special parameter "Day of trial period" is defined in the Analytics resource settings 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 during a session, you only need to set the custom parameter value once per session.

Ga("create", "UA-XXXX-Y", "auto"); // Selecting a value for a special parameter with index 2. var day = getDayOfTrial(); ga("set", "dimension2", day); // Passing the value of a special parameter with a request - 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 beginning of the session.

Data processing

Custom parameter values ​​passed to Analytics will be applied to hits based on 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 day, 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 transmitted with only one screen view per session.

The Session access scope ensures that the Trial Day value is associated with all hits in that session, not just the one with which it was sent.

Reports

Once processed, session-level custom parameter values ​​will be assigned to all screen views received in a single session. Now the developer can create a report based on the Trial 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 “Day of trial period”:

As can be seen from the report, players completed the most levels on the first day, and noticeably less on the second and third. Grouping sessions and hits by one value using a special parameter at the session level helped to obtain this important information.

Access area "User"

Finally, let's find out how many levels the paid and trial users completed.

To do this you need the following report:

Using a custom user-level parameter, you can associate all screen views of a specific user (both in the current session and future ones) with a player type.

Why user level?

The User access area allows you to easily group all user sessions and accesses. 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 layers, but the user layer is much more convenient since it requires minimal changes to the code.

Settings

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, simply define this special parameter when starting the game and then again when upgrading to its paid version.

The developer will need to define a special parameter when the user starts the game:

Ga("create", "UA-XXXX-Y", "auto"); // Selecting a value for a special parameter with index 3. ga("set", "dimension3", "Free"); // Passing the value of a special parameter with a request - page view. ga("send", "pageview", "/level_1/");

The same special parameter must be set when upgrading to the paid version:

Ga("create", "UA-XXXX-Y", "auto"); // Selecting a value for a special parameter with index 3. ga("set", "dimension3", "Paid"); // Passing the value of a special parameter with a request - page view. ga("send", "pageview", "/level_1/");

Data processing

Custom parameter values ​​passed to Analytics will be applied to hits based on their scope.

For example, this is 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, since the paid value is set only in the third session.

Reports

Player Type custom parameter values ​​will be associated with the sessions in which they were set, as well as all future sessions and hits.

Now a developer can create a report based on the Player Type and Screen Title parameters, as well as the Screen Views metric:

Finally, let's group screen views by player type to compare the number of levels between the free and paid versions. To do this, you need to create your own report with the main parameter “Player Type”:

As you can see, the free version of the game has an advantage in terms of the number of levels. Grouping users and their sessions and hits by one value using a custom user-level parameter helped to obtain this important information.

Access area "Product"

Let's look at how to use special parameters at the product level to find out which upgrades (minimal, 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 be seen which level of improvements are in greatest 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 indicate which level of upgrades users purchase most often. You can also get similar statistics on the number of views, clicks, and other enhanced e-commerce actions.

Why exactly the product level?

The user can purchase several upgrades at the same time. If the scope of action is "Product", the level value will be assigned only to the product with which it was transferred. As a result, each upgrade you purchase will be associated with a unique level.

Settings

The special parameter "Enhancement Level" is defined in the Analytics resource settings as follows:

Data collection

The developer is already tracking purchases of improvements in the game. To assign each of them a certain level, you need to set the value of a special parameter along with 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 the original page view.

In this example, a custom parameter is defined along with the product information and specifies the level of the corresponding enhancement.

Data processing

As in the previous examples, custom parameter values ​​passed to Analytics will be applied to hits based on their scope.

This is what the data might look like for one 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 enhancement is associated only with the product it was shipped with.

Reports

You can then create your own income report for each improvement level:

In this case, the floor level improvements generated the most revenue.

Special indicators

Scope

Special indicators also have their own scope, which allows them to be compared with parameters of the same level. Thus, product level indicators are associated only with the product with which they were sent. The following are two examples of custom metrics.

Special indicator at the circulation level

In the examples above, the developer tracked screen views for each level of the game, so all reports use the Screen Views metric. It indicates the user's attempt to complete the level.

However, the developer is also interested in the completion rate of each level.

To do this, the developer adds a special indicator “Completed levels” and then compares their number with the number of screen views for each level.

Why are special indicators needed?

Custom metrics, as opposed to standard metrics (events, screen views, etc.), allow you to create more flexible and visual reports with the data that interests you most.

In our example, completed levels cannot be tracked as screen views because they will be counted twice for each level.

Although events can be used individually, due to their hierarchical nature, it would be difficult to create the report shown above by combining screen views and levels completed into a single parameter.

Given these facts and the importance of such information for the developer, it is most convenient to track completed levels as a special indicator.

Settings

The special indicator "Completed levels" can be set in the Analytics settings:

Data collection

The developer already tracks the launch of each level using screen views. Now he is interested in how many levels users complete. For this purpose, he creates a special indicator.

Custom metrics, like custom dimensions, are sent to Analytics along with hits. Therefore, the developer will need to send an additional request that registers the completion 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.

This is 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 the Screen Title parameter and the Screen Views, Total Events, and Levels Completed metrics:

This data suggests that the second level is actually more difficult than the first and third, with a completion rate of only 33%. By tracking the progress of levels using a special indicator, the developer can easily obtain the data he is interested in in the form of simple, visual reports.

Product-level custom metric

In the examples above, the developer tracks upgrade purchases and can associate various metrics with each upgrade, such as quantity or revenue generated.

For this purpose, a special indicator “Spent bonuses” is used.

Here's the report you need for this:

Settings

The special parameter "Spent bonuses" is defined in the "Administrator" section:

Data collection

Custom metrics, like custom dimensions, are sent to Analytics along with product data.

This is 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", // Special parameter at the product level (string). "metric2": 5 // Special indicator at the product level (integer). ) ); ga("ec:setAction", "purchase", ( "id": "T12345", "revenue": "20.00" )); ga("send", "pageview"); // Send transaction data with the original page view.

Data processing

Before processing, data about one player who has purchased several 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 "Bonuses Spent" indicators:

Obviously, players prefer to spend bonuses on minimal improvements, and mid-level improvements bring the greatest profit to the developer.

Notes

Here are a few things to consider 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, your data will be affected as follows:

• Editing the title affects already processed data: you will only be able to receive 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 metric 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 is the case with age, then the special parameter only needs to be set once at the user level. Always choose the right scope to avoid mistakes.

Was this information useful?

How can this article be improved?