Widgets today are an integral part of many large portals, because they allow you to use complex partner development avoiding long implementation procedures. Web analytics widgets are of interest to all parties, but in the case of iFrame, there are difficulties in transferring 100% of 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.
 
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 them to various web analytics counters using the specified rules.
 
 

 
Figure 2 - The Tag Tags window of the Google Tag Manager with the already configured tags for the widget
 
 
First, we describe the algorithm for solving this problem, so that we can immediately understand which way we moved to achieve the result. So:
 
 
 
The partner, like the owner, wants to monitor the work of the widget in one of two ways, or two at once - using Yandex.Metrica or Google Analytics.
 
A satisfactory solution is to transfer data to 4 counters: the owner metric counter, the owner's Google Analytics counter, the partner metric counter, and the partner's Google Analytics counter.
 
Inside the widget is installed a single container Google Tag Manager, which will collect all the data and distribute them in such a way that each participant receives only the information he needs.
 
The identifiers of the owner's counters are set by default, the partner IDs must be specified by him at the time of generating the widget code in the partner cabinet for further installation on the site.
 
Since the affiliate office is already configured for the partner, IDs can be set in it and sent to the widget to allow Tag Manager to use them.
 
Inside the GTM, the identifiers are inserted into the triggers of the target events, as well as the distribution of the data transfer over the owners and partner counters.
 
In this case, GTM sends all the collected data to the owner's counters, and the data on the partner's site is only in the counter of the partner, because when substituting identifiers, only the site specified by the partner is tracked.
 
 
For convenience of understanding, we give the flowchart of the process (Fig. 3):
 
 

 
Figure 3 - The scheme of the data transfer process
 
 
First of all, let's define that in addition to Google Tag Manager code, there are also automatically generated Yandex.Metrica and Google Analytics counters on the site. In them, when generating the code for the site, the counter identifiers specified by the partner are flushed.
 
 
These codes can not be set in the widget, since the GTM capabilities allow to automatically generate them on the site as corresponding tags (type - Custom HTML - Fig. 4), but in this case a rigid prescription in the widget code was necessary - some events on the site require, so that the counter is immediately installed inside the widget. Basically, this is the boot event, the appearance of the preball. If you do not have this type of event, you can generate the counter code via GTM:
 
 

 
Figure 4 - An example of transferring Metric code to a site through GTM
 
 
To transfer data directly to two counter (partner and owner), you need to install not two different Metric or Analytics code, but create special double code . At the time of writing, the correct codes look like this (Fig. 5):
 
 

 
Figure 5 - The correct version of the use of the dual codes Metric and GA
 
 
Next, you need to transfer the identifier specified by the partner into the counter code. The difficulty here is that the widget code is generated automatically for all sites, while the identifiers are set in a separate partner office. For the correct transfer of the programmer, the following solution was implemented:
 
 
When the widget is initialized, an iFrame is created, the parameters of which are passed counterpart counter identifiers (counters are passed to the src iFrame, then it is parsed in the widget from the location). iFrame opens the widget application and in the created life cycle of the widget (SPA), the input parameters of the counter numbers are processed before mounting, and numbers (identifiers) are stored in localStorage.
 
 
To place the Google Analytics code in index.html, the following construct is used:
 
 

 
Scripts with variable src 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 counter, which is used if the partner does not specify its counter. This situation can occur if the partner did not specify the counter identifiers as a whole or set only one identifier - there must always be a swap code so that the site does not experience jаvascript errors related to the lack of an identifier for the correct operation of the transmission code of an event. UA-15930803-13 in this case is the Master's owner ID, in which the data comes in any way and from any site.
 
 
Similarly to GA, the Yandex.Metrica code is generated, which uses the specified owner owner ID, the owner default counter replacement ID, and the design for the partner ID transmission. The code is generated according to the scheme shown in Fig. 5 using the constructions from the example above.
 
 
Following the codes of the counters, you must throw the IDs specified by the partner into the Google Tag Manager. Inside the container, they will already be used as internal variables, whose values ​​can be supplied to generated events.
 
 
For GTM, the technique of data-level variables (dataLayer) is most often used. The data layer is a jаvascript variable, the initialization of which is described automatically inside the Google Tag Manager container. Using it, you can send events of the type event as occurring on the site, or set your own variables for GTM. This is done using the design
 
 
dataLayer.push ('variable_name': 'variable_value');
 
After the GTM code is declared on the site. However, in our case, the data-level variable did not work, maybe it's the complexity of working with the iframe. If you set the push () construct automatically, then the container does not receive any variables, and in this case it would be desirable for this implementation of the task. If you try to set the data-level variable manually (for example, on any click on the site), then the variable is passed normally.
 
 
In order not to waste time analyzing the process, we used an alternative solution - creating global jаvascript variables via localStorage .
 
 
The localStorage property allows you to store variables with specified values ​​without being bound to an open page of the site, and the data inside this store can not simply be deleted. Accordingly, the identifiers of the partner counters were thrown through using the following constructions:
 
 
localStorage.setItem ('partnerMetrika1', 'UUUUUUUU');
localStorage.setItem ('partnerMetrika2', 'yaCounterУУУУУУУУ');
localStorage.setItem ('partnerGA', 'UA-УУУУУУУ-УУ');
 
Here, the first construct sends the partner Metric number itself, the second construct passes the collection value yaCounter for the convenience of creating the "Event" tag in the Google Tag Manager (about this later), and the third is the Google Analytics ID.
 
 
This completes the transfer of data and the adjustment of the GTM itself comes into play.
 
 
First, let's define the principle of Google Tag Manager. It presents 3 levels of interaction:
 
 
Tag . This is part of the code that can be placed on a site with GTM installed and can be executed like any other code, by changing the content of the site or by passing data to the web analytics counters.
 
 
The tag is triggered if some condition is met on the site.
 
 
Trigger . This is the actual condition, the execution of which triggers the tag. This can be an event on the site, changing the value of variables or a standard action - for example, a click or a pageview.
 
 
The 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 the triggering of the trigger, and the trigger in turn triggers the corresponding tag. Partner counter identifiers are specified exactly as variables, so start building the data in the GTM container.
 
 
We created three main variables of the type "Own jаvascript code" (Fig. 6):
 
 

 
Figure 6 - An example of a variable that takes the partner identifier Metric
 
 
Here the value of the variable = is the value that we took from localStorage.
 
 
Now if GTM turns to the variable, it will get its value - the identifier of the affiliate Metric. Similarly, we created variables for the Metric Partner number and Google Analytics partner ID.
 
 
What are these variables used for? They solve the problem of sending data about the occurrence of events on the site in partner counters. Google Tag Manager has a standard goal transfer procedure in Google Analytics, where you can use the value of a variable as the counter ID. And for Metrics a tag is used in the form of a custom HTML-code containing standard jаvascript Metrics:
 
 
yaCounterXXXXXX.reachGoal ('TARGET_NAME');
 
Here TARGET_NAME is the internal name of the target event for Metrics (such goals are created in the counter settings via the "jаvascript-event" type), and XXXXXX is the counter number.
 
 
Thus, we create corresponding tags for different kinds of counters.
 
 
For Google Analytics:
 
 
The tag type is "Universal Analytics", the tracking ID is from our variable.
 
 

 
Figure 7 - Example of setting up a tag that passes data to Google Analytics.
 
 
Here, the Category and the Action are those values ​​that Google Analytics should capture as parameters for triggering the target. Tracking ID is a previously defined variable that has taken a partner identifier from localStorage.
 
 
For Yandex.Metrica:
 
 
The tag type is "Custom HTML" using jаvascript constructs.
 
 

 
Figure 8 - Example of setting a tag that sends data to Yandex.Metric
 
 
Here {{PartnerMetrikaCounter}} is the internal declaration of a variable that takes the partner Metric ID from localStorage. With the help of the window object, we substitute the value of the variable in the executable code, and on the output we get yaCounterXXXXXXХХ.reachGoal ('widget_loading') ;, where widget_loading is the value that the Metric catches as the target trigger parameter.
 
 
It remains only to set triggers to trigger the appropriate tags. Triggers in our case are, for example:
 
 
 
Widget successful download events;
 
Events of successful or unsuccessful passage of a step on a widget;
 
Filling in certain fields;
 
Select conditions A or B inside the widget;
 
Interaction with forms, buttons and links.
 
 
Next, in the settings of the Metrics and Google Analytics counters, you only need to create the corresponding goals:
 
 

 
Figure 9 - Example of goal setting in Yandex.Metric
 
 

 
Figure 10 - Example goal setting in Google Analytics
 
 
The problem is solved. The dual codes of counters are substituted into Metrics and Analytics identifiers of the partner given to them, and the values ​​of the owner's identifiers remain unchanged. At the same time, Google Tag Manager throws the triggers of the corresponding targets into the counter of the partner only if it receives from the variables exactly the identifiers that the particular partner specified on their site. In parallel, GTM sends the owner all the target events from all sites.
 
 
If the partner did not specify one or both identifiers, then the default values ​​are used - the test counter identifiers specified by the owner in advance.