Two-way analytics of partner iframe widget using Google Tag Manager
Widgets today are an integral part of many large portals, because they allow the use of complex partner development avoiding long implementation procedures. The web analytics of widgets are interesting for all parties, but in the case of iFrame there are difficulties in transferring 100% of the data to the participants of the partnership. What are the difficulties and how we managed to get around them, I would like to tell in this article. First of all, it will be of interest to everyone who develops and implements widgets on iFrame, as well as to attracted analysts.
For a start, a little background. We are developing both our own solutions for automation in the field of passenger transportation and products for use on partner sites. One of them was the project of automated booking of VIP and business lounges at airports in the world and Russia, aimed at meeting the needs of business and premium customers of various airlines. A single database of thematic services at various airports is primarily interesting for companies associated with passenger air travel, online travel agencies, as well as travel companies with sites on the Internet. For such companies, a “VIP-room” widget was created, allowing users of any partner site to access this database.
The widget is installed in a standard way via iFrame, the partner only needs to place the code on his website and adjust the appearance parameters according to the general design concept. As a result, the site contains a module for selecting and booking VIP lounges at the airport of interest with access to premium airport services, such as a shuttle (individual transfer from the lounge to the plane), meeting in the hall with a sign, escorting the employee and parking access for VIP- customers. The booking process is carried out in a few simple steps within which the user can vary the contents of the order (Fig. 1).
Figure 1 - The appearance of the widget on the site
')
Given the variability of filling data, of course, the question arises of tracking this process from the point of view of analytics. Moreover, web analysis is interesting both for the widget's owner and his partner , who establishes it, therefore, during the development, the task of tracking events inside the widget and transmitting them simultaneously in two directions appeared:
A. From all sites on which the widget is installed, to the web analytics of the owner (developer).
B. From the site where the specific widget is installed, to the partner’s web analytics.
What is the difficulty here? Basically, the partner takes a single widget code that is not configured for a specific partner site, but at the same time wants to see information in the analytics only on its own widget. The second difficulty lies in the fact that the widget developer (owner) must receive data from all partner sites at once in one counter, which runs counter to the partner’s desire to see only his own information. In the end, you just need to distinguish between the data that the partner should see and which the owner will see. The task was solved with the help of Google Tag Manager (hereinafter - GTM).
This tool is widely used for web analytics and tag management on websites; it does not make sense to describe in detail the principle of its operation, for understanding it is enough to familiarize yourself with the concept of GTM from other articles . In this case, it is important to understand that Google Tag Manager (Fig. 2) allows you to consolidate data from the site inside your own containers and distribute it to various web analytics counters using the specified rules.
Figure 2 - Google Tag Manager “Tags” window with already configured tags for the widget
To begin with, we will describe the algorithm itself for solving this problem, in order to immediately understand how we moved to achieve the result. So:
For convenience of understanding, we present a flowchart of the process (Fig. 3)
Figure 3 - Diagram of the data transfer process
To begin with, we will determine that, in addition to the Google Tag Manager code, the site also contains automatically generated counter codes Yandex.Metrics and Google Analytics. When generating code for the site, counter identifiers given by the partner are forwarded to them.
These codes in the widget can not be set, because the possibilities of GTM allow you to automatically generate them on the site as the corresponding tags (type - Custom HTML - Fig.4), but in this case hard writing to the widget code was necessary - some events on the site require so that the counter is immediately installed inside the widget. Basically, these are boot events, preroll appearances. If you do not have such events, then you can generate a counter code via GTM:
Figure 4 - Example of the transfer of the Metrics code to the site via GTM
To transfer data at once to two counters (partner and owner), you need to install not two different Metrics or Analytics codes, but create a special dual code . At the time of writing, the correct codes look like this (Fig. 5):
Figure 5 - The correct use of dual codes Metrics and GA
Next you need to pass inside the counter code identifier specified by the partner. The difficulty here is that the widget code is automatically generated for all sites, and the identifiers are already set in a separate partner room. For the programmer to correctly pass the following solution was implemented:
When the widget is initialized, an iFrame is created, and the counter identifiers of the partner are passed to the parameters (the counters are transferred to the src iFrame, and then they are sent to the widget from the location). iFrame opens the widget's application and in the created widget's life cycle (SPA) hook, before mounting, the input parameters of the counter numbers are processed, and the numbers (identifiers) are stored in localStorage.
The following construction is used to place the Google Analytics code in index.html:
Scripts with src variables are inserted dynamically when the counters are initialized:
Here, UA-15930803-14 is a “dummy” owner’s counter, which is used if the counter’s counter is not set by the partner. This situation may occur if the partner did not specify the identifiers of the counters as a whole or only one identifier was specified - there must always be a substitute code so that the site does not have JavaScript errors related to the absence of an identifier for the correct transmission of the event. UA-15930803-13 in this case - the main identifier of the Owner, in which data comes in any case from any site.
Similarly to GA, the Yandex.Metrica code is generated, which uses the specified owner metric identifier, the replacement owner default identifier of the counter and the construct for transmitting the partner identifier. The code is formed according to the scheme shown in Figure 5 using the constructions from the example above.
Following the counter codes, you need to forward the identifiers given by the partner inside Google Tag Manager. Inside the container, they will already be used as internal variables, whose values ​​can be supplied to the generated events.
For GTM, the most commonly used method is a data level variable (dataLayer). The data tier is a javascript variable whose initialization is described within the Google Tag Manager container automatically. With the help of it, you can transmit both events of the type event occurring on the site, as well as set your own variables for GTM. This is done using the design
Triggered after the announcement of the GTM code on the site. However, in our case, the data level variable did not work, it is possible that the complexity of working with an iframe is the case. If we set the push () construction automatically, then the container does not receive variables, and in this case, we wanted just such an implementation of the task. If you try to set a data level variable manually (for example, for any click on the site), the variable is passed normally.
In order not to waste time on the analysis of the process, we used an alternative solution - the creation of global JavaScript variables via localStorage .
The localStorage property allows you to store variables with the specified values ​​without being tied to an open page of the site, and the data inside this storage cannot be simply deleted. Accordingly, the identifiers of the partner counters were forwarded using the following constructs:
Here, the first construction passes the partner Metric number itself, the second construction passes the collective value of yaCounter for the convenience of creating the “Event” tag in Google Tag Manager (more on this later), and the third - the Google Analytics ID.
This completes the transfer of data and the configuration of the GTM itself comes into play.
First, we’ll decide on how Google Tag Manager works. It presents 3 levels of interaction:
Tag This is a piece of code that can be placed on a site with GTM installed and can be executed like any other code, changing the content of the site or transferring data to web analytics counters.
The tag is triggered if some condition is met on the site.
Trigger This is the actual condition, the fulfillment of which triggers the tag. This can be an event on the site, a change in the value of variables or a standard action — for example, a click or a page view.
Variable It contains some values ​​that can be passed in various ways, and is used as a data provider for tags or a condition marker.
The content of variables entails triggering the trigger, and the trigger in turn calls the corresponding tag. The identifiers of the partner counters are defined precisely as variables; it is worth starting with the formation of data in the GTM container.
We created three main variables of the type “Own JavaScript code” (Fig.6):
Figure 6 - Example of a variable that takes a partner Metric identifier
Here the value of the variable is the value we took from localStorage.
Now, if GTM accesses a variable, then its value will be obtained - the identifier of the partner Metric. In the same way, we created variables under the number of the partner Metric and the identifier of the partner Google Analytics.
What are these variables used for? They solve the problem of sending data on the triggering of events on the site to partner counters. Google Tag Manager has a standard procedure for transferring goals to Google Analytics, where you can use the value of a variable as a counter identifier. And for Metrics, a tag is used in the form of custom HTML code containing standard JavaScript Metrics:
Here TARGET_NAME is the internal name of the target event for the Metric (such goals are created in the counter settings using the “JavaScript event” type), and is the counter number.
Thus, we create corresponding tags for different types of counters.
For Google Analytics:
The tag type is “Universal Analytics”, the tracking ID is from our variable.
Figure 7 - An example of setting up a tag that transfers data to Google Analytics.
Here, Category and Action are the values ​​that Google Analytics should capture as its goal response parameters. Tracking ID is a previously defined variable that takes the partner ID from localStorage.
For Yandex.Metrics:
The tag type is “Custom HTML” using JavaScript constructs.
Figure 8 - An example of setting up a tag that sends data to Yandex.Metrica
Here {{PartnerMetrikaCounter}} is the internal declaration of a variable that takes the ID of the partner Metric from localStorage. Using the window object, we substitute the value of the variable into the executable code, and at the output we get yaCounterXXXXXXXX.reachGoal ('widget_loading'); where widget_loading is the value that the Metric catches as a trigger parameter.
It only remains to set the triggers to trigger the corresponding tags. Triggers in our case were, for example:
Further, in the settings of the Metrics and Google Analytics counters, it remains only to create the corresponding goals:
Figure 9 - An example of setting goals in Yandex. Metric
Figure 10 - An example of setting goals in Google Analytics
Problem solved. Dual counter codes substitute the values ​​specified for them into the Metrics and Partner Analytics identifiers, while the values ​​of the owner identifiers remain unchanged. At the same time, the Google Tag Manager only sends the corresponding targets to the partner’s counters if it receives from the variables exactly the identifiers that were set by a specific partner on its website. In parallel with this, GTM sends to the owner all target events from all sites.
If the partner did not specify one or both identifiers, then the default values ​​are used - the identifiers of test counters specified by the owner in advance.
For a start, a little background. We are developing both our own solutions for automation in the field of passenger transportation and products for use on partner sites. One of them was the project of automated booking of VIP and business lounges at airports in the world and Russia, aimed at meeting the needs of business and premium customers of various airlines. A single database of thematic services at various airports is primarily interesting for companies associated with passenger air travel, online travel agencies, as well as travel companies with sites on the Internet. For such companies, a “VIP-room” widget was created, allowing users of any partner site to access this database.
The widget is installed in a standard way via iFrame, the partner only needs to place the code on his website and adjust the appearance parameters according to the general design concept. As a result, the site contains a module for selecting and booking VIP lounges at the airport of interest with access to premium airport services, such as a shuttle (individual transfer from the lounge to the plane), meeting in the hall with a sign, escorting the employee and parking access for VIP- customers. The booking process is carried out in a few simple steps within which the user can vary the contents of the order (Fig. 1).
Figure 1 - The appearance of the widget on the site
')
Given the variability of filling data, of course, the question arises of tracking this process from the point of view of analytics. Moreover, web analysis is interesting both for the widget's owner and his partner , who establishes it, therefore, during the development, the task of tracking events inside the widget and transmitting them simultaneously in two directions appeared:
A. From all sites on which the widget is installed, to the web analytics of the owner (developer).
B. From the site where the specific widget is installed, to the partner’s web analytics.
What is the difficulty here? Basically, the partner takes a single widget code that is not configured for a specific partner site, but at the same time wants to see information in the analytics only on its own widget. The second difficulty lies in the fact that the widget developer (owner) must receive data from all partner sites at once in one counter, which runs counter to the partner’s desire to see only his own information. In the end, you just need to distinguish between the data that the partner should see and which the owner will see. The task was solved with the help of Google Tag Manager (hereinafter - GTM).
This tool is widely used for web analytics and tag management on websites; it does not make sense to describe in detail the principle of its operation, for understanding it is enough to familiarize yourself with the concept of GTM from other articles . In this case, it is important to understand that Google Tag Manager (Fig. 2) allows you to consolidate data from the site inside your own containers and distribute it to various web analytics counters using the specified rules.
Figure 2 - Google Tag Manager “Tags” window with already configured tags for the widget
To begin with, we will describe the algorithm itself for solving this problem, in order to immediately understand how we moved to achieve the result. So:
- A partner, like the owner, wants to track the widget's work in one of two ways, or two at once - using Yandex.Metrics or Google Analytics.
- A satisfying solution should transfer data to 4 counters: Owner’s Metrics counter, owner’s Google Analytics counter, Partner’s Metrics counter and Partner’s Google Analytics counter.
- Inside the widget, a single Google Tag Manager container is installed that will collect all the data and distribute it in such a way that each participant receives only the information he needs.
- The IDs of the owner counters are set by default, the partner IDs must be specified by him at the time of generating the widget code in the partner room for further installation on the site.
- Since a partner account has already been set up for the partner, identifiers can be set in it and forwarded inside the widget so that Tag Manager uses them.
- Inside GTM, the substitution of identifiers into the trigger codes of target events occurs, as well as the distribution of data transmission over the owner and partner counters.
- At the same time, GTM sends all collected data to the owner’s counters, and the data on the partner’s site - only to the partner’s counters, since during the substitution of identifiers, only the site specified by the partner is tracked.
For convenience of understanding, we present a flowchart of the process (Fig. 3)
Figure 3 - Diagram of the data transfer process
To begin with, we will determine that, in addition to the Google Tag Manager code, the site also contains automatically generated counter codes Yandex.Metrics and Google Analytics. When generating code for the site, counter identifiers given by the partner are forwarded to them.
These codes in the widget can not be set, because the possibilities of GTM allow you to automatically generate them on the site as the corresponding tags (type - Custom HTML - Fig.4), but in this case hard writing to the widget code was necessary - some events on the site require so that the counter is immediately installed inside the widget. Basically, these are boot events, preroll appearances. If you do not have such events, then you can generate a counter code via GTM:
Figure 4 - Example of the transfer of the Metrics code to the site via GTM
To transfer data at once to two counters (partner and owner), you need to install not two different Metrics or Analytics codes, but create a special dual code . At the time of writing, the correct codes look like this (Fig. 5):
Figure 5 - The correct use of dual codes Metrics and GA
Next you need to pass inside the counter code identifier specified by the partner. The difficulty here is that the widget code is automatically generated for all sites, and the identifiers are already set in a separate partner room. For the programmer to correctly pass the following solution was implemented:
When the widget is initialized, an iFrame is created, and the counter identifiers of the partner are passed to the parameters (the counters are transferred to the src iFrame, and then they are sent to the widget from the location). iFrame opens the widget's application and in the created widget's life cycle (SPA) hook, before mounting, the input parameters of the counter numbers are processed, and the numbers (identifiers) are stored in localStorage.
The following construction is used to place the Google Analytics code in index.html:
<script> window.dataLayer = window.dataLayer || []; function gtag() { dataLayer.push(arguments); } gtag('js', new Date()); gtag('config', 'UA-15930803-13'); gtag('config', window[localStorage.getItem('partnerGA')] || 'UA-15930803-14'); </script> Scripts with src variables are inserted dynamically when the counters are initialized:
let script = document.createElement('script') script.setAttribute('src', `https://www.googletagmanager.com/gtag/js?id=${ga || 'UA-15930803-14'}`) document.head.insertBefore(script, document.head.firstChild) Here, UA-15930803-14 is a “dummy” owner’s counter, which is used if the counter’s counter is not set by the partner. This situation may occur if the partner did not specify the identifiers of the counters as a whole or only one identifier was specified - there must always be a substitute code so that the site does not have JavaScript errors related to the absence of an identifier for the correct transmission of the event. UA-15930803-13 in this case - the main identifier of the Owner, in which data comes in any case from any site.
Similarly to GA, the Yandex.Metrica code is generated, which uses the specified owner metric identifier, the replacement owner default identifier of the counter and the construct for transmitting the partner identifier. The code is formed according to the scheme shown in Figure 5 using the constructions from the example above.
Following the counter codes, you need to forward the identifiers given by the partner inside Google Tag Manager. Inside the container, they will already be used as internal variables, whose values ​​can be supplied to the generated events.
For GTM, the most commonly used method is a data level variable (dataLayer). The data tier is a javascript variable whose initialization is described within the Google Tag Manager container automatically. With the help of it, you can transmit both events of the type event occurring on the site, as well as set your own variables for GTM. This is done using the design
dataLayer.push('_': '_'); Triggered after the announcement of the GTM code on the site. However, in our case, the data level variable did not work, it is possible that the complexity of working with an iframe is the case. If we set the push () construction automatically, then the container does not receive variables, and in this case, we wanted just such an implementation of the task. If you try to set a data level variable manually (for example, for any click on the site), the variable is passed normally.
In order not to waste time on the analysis of the process, we used an alternative solution - the creation of global JavaScript variables via localStorage .
The localStorage property allows you to store variables with the specified values ​​without being tied to an open page of the site, and the data inside this storage cannot be simply deleted. Accordingly, the identifiers of the partner counters were forwarded using the following constructs:
localStorage.setItem('partnerMetrika1', ''); localStorage.setItem('partnerMetrika2', 'yaCounter'); localStorage.setItem('partnerGA', 'UA--'); Here, the first construction passes the partner Metric number itself, the second construction passes the collective value of yaCounter for the convenience of creating the “Event” tag in Google Tag Manager (more on this later), and the third - the Google Analytics ID.
This completes the transfer of data and the configuration of the GTM itself comes into play.
First, we’ll decide on how Google Tag Manager works. It presents 3 levels of interaction:
Tag This is a piece of code that can be placed on a site with GTM installed and can be executed like any other code, changing the content of the site or transferring data to web analytics counters.
The tag is triggered if some condition is met on the site.
Trigger This is the actual condition, the fulfillment of which triggers the tag. This can be an event on the site, a change in the value of variables or a standard action — for example, a click or a page view.
Variable It contains some values ​​that can be passed in various ways, and is used as a data provider for tags or a condition marker.
The content of variables entails triggering the trigger, and the trigger in turn calls the corresponding tag. The identifiers of the partner counters are defined precisely as variables; it is worth starting with the formation of data in the GTM container.
We created three main variables of the type “Own JavaScript code” (Fig.6):
Figure 6 - Example of a variable that takes a partner Metric identifier
Here the value of the variable is the value we took from localStorage.
Now, if GTM accesses a variable, then its value will be obtained - the identifier of the partner Metric. In the same way, we created variables under the number of the partner Metric and the identifier of the partner Google Analytics.
What are these variables used for? They solve the problem of sending data on the triggering of events on the site to partner counters. Google Tag Manager has a standard procedure for transferring goals to Google Analytics, where you can use the value of a variable as a counter identifier. And for Metrics, a tag is used in the form of custom HTML code containing standard JavaScript Metrics:
yaCounterXXXXXX.reachGoal('TARGET_NAME'); Here TARGET_NAME is the internal name of the target event for the Metric (such goals are created in the counter settings using the “JavaScript event” type), and is the counter number.
Thus, we create corresponding tags for different types of counters.
For Google Analytics:
The tag type is “Universal Analytics”, the tracking ID is from our variable.
Figure 7 - An example of setting up a tag that transfers data to Google Analytics.
Here, Category and Action are the values ​​that Google Analytics should capture as its goal response parameters. Tracking ID is a previously defined variable that takes the partner ID from localStorage.
For Yandex.Metrics:
The tag type is “Custom HTML” using JavaScript constructs.
Figure 8 - An example of setting up a tag that sends data to Yandex.Metrica
Here {{PartnerMetrikaCounter}} is the internal declaration of a variable that takes the ID of the partner Metric from localStorage. Using the window object, we substitute the value of the variable into the executable code, and at the output we get yaCounterXXXXXXXX.reachGoal ('widget_loading'); where widget_loading is the value that the Metric catches as a trigger parameter.
It only remains to set the triggers to trigger the corresponding tags. Triggers in our case were, for example:
- The events of the successful loading of the widget;
- Events of successful or unsuccessful passage of a step on the widget;
- Filling in certain fields;
- The choice of conditions A or B inside the widget;
- Interaction with forms, buttons and links.
Further, in the settings of the Metrics and Google Analytics counters, it remains only to create the corresponding goals:
Figure 9 - An example of setting goals in Yandex. Metric
Figure 10 - An example of setting goals in Google Analytics
Problem solved. Dual counter codes substitute the values ​​specified for them into the Metrics and Partner Analytics identifiers, while the values ​​of the owner identifiers remain unchanged. At the same time, the Google Tag Manager only sends the corresponding targets to the partner’s counters if it receives from the variables exactly the identifiers that were set by a specific partner on its website. In parallel with this, GTM sends to the owner all target events from all sites.
If the partner did not specify one or both identifiers, then the default values ​​are used - the identifiers of test counters specified by the owner in advance.
Source: https://habr.com/ru/post/424799/
All Articles