If you ended-up reading this article, you probably know what an iFrame is and the struggle it can bring when it comes to tracking. If it’s your case, then you can jump to the concrete material of this article and the first alternative.
For the others, here is a definition of an iFrame (source: https://techterms.com): “An iframe (short for inline frame) is an HTML element that allows an external webpage to be embedded in an HTML document. Unlike traditional frames, which were used to create the structure of a webpage, iframes can be inserted anywhere within a webpage layout.” In a nutshell, an iframe is a page within a page.
Why would you need to insert a page within a page? you might ask. Well, first, you should not. IFrames are horrible to track and will probably affect your data quality before you know it.
Why do we still encounter iFrames if they are so vicious and awful to track? Economies of scale or easiness will probably be the two main reasons for iFrames survival. To give you a concrete example, a typical iFrame can be a form. If a development agency built a form for a website and needs the exact same for another one, they will probably insert the original form in an iFrame to be fast and just adapt the layout to the parent frame (main website).
In this article, I will provide you with what I believe are two effective ways to track iFrames after hours of struggle trying to track them the best way possible. Hopefully I can spare you the hassle and make your life easier.
1. iFrame decorator
The first option for tracking iFrames comes from Google Tag Manager guru, Simo Ahava, who shares the same opinion as I do on iFrames.
In his solution, Simo uses a customTask that leverages a setInterval() and decorates the iFrame whenever he finds one. Using a custom script, every x seconds (you can choose the interval yourself), the TMS on the parent frame will look for iFrames in the page that matches the CSS selector you mentioned in the script. When he finds it, he will decorate the iFrame path with the cross-domain linker parameter. This means that the URL of the iFrame will have the _ga= cross-domain linker parameter, which will be used by the cross-domain tag on the parent frame with the allowLinker set to true.
If everything was not clear, this visual representation should help you:
The full script can be found in Simo’s article.
2. postMessage using dataLayer.Push
In this second alternative, we use a more radical approach than the first one. Indeed, where we had a Tag Management System on both the parent frame and the iFrame in the first example, here we will send every hit to Analytics from the parent frame, even the interactions that are coming from the iFrame.
To do so, we will use a Javascript function called postMessage. This function is composed of a message and a targetOrigin. Concretely, we will send a message from the iFrame that will be read by the parent frame. We will thus send our tracking information to the parent frame and push it to the dataLayer. In order for the parent to be able to read the message sent from the iFrame, we will need to install a listener on our parent frame.
Here is a visual representation of the solution:
In terms of data quality and robustness, the second option is probably the best one, but it will require some additional efforts from your development team/agency.
Remember that iFrames should be avoided whenever you can, but if you need to deal with one, hopefully those two proposed solutions can help you manage it without losing too much hair in the process.
Grégoire le Hardy
| LinkedinThis email address is being protected from spambots. You need JavaScript enabled to view it.
