When it comes to Google Analytics implementations, I must admit, I have swagger. Most of the time, there’s nothing I can’t track.
But I have one nemesis. They bring my confidence crashing down like a deck of cards. Who is this beast that can take away all my glory?
The iFrame.
I was going to write a four-letter-world laden tribute to our fine filthy friend. But someone beat me to it. Simo Ahava, the master of all things Google Tag Manager and Google Analytics, hates the iFrame as much as I do.
Simo Ahava
IFRAMES SUCK!
They are horrible, Lovecraftian subterranean beings of horror that crawl from the nether pits of darkness after the tolling of the midnight bell. They are playground bullies; entitled little brats that wreak havoc on innocent markup. They are artefacts of human laziness, true examples of Conway’s Law in motion. They are, in essence, untrackable little shit-monsters that exist in the void between websites, accountable to none and hazardous to all.
If you’ve got iFrames, you’ve got problems. And if you need to track that iFrame, you need to admit your problem before you can move forward.
When Do iFrames Become an Analytics Problem?
There are a few situations when having an iFrame becomes an analytics problem, and fast.
Your iFrame has no analytics, but there’s something vitally important in it that needs tracking.
I had a client that had several hundred lead generation forms on their website. Some were internally created. Some used a third-party form generator. Some were in a marketing tool. It was a giant headache trying to track them all. To be safe, I made a wide variety of events that triggered on a combination of form submits and button clicks. It was a mess of data, but we were able to make sense of most of it.
Most, that is, except from the third-party form generator. Those forms were being delivered in iFrames. And the form generator did not appear to have any way to add analytics.
I tried every hack in the book, both in GTM and within the form generator. But there was nothing we could do. We couldn’t track the forms.
Your iFrame does have analytics in it, and it’s flooding your analytics with extras.
Sticking the analytics snippet on your iFrame doesn’t solve the problem.
A few years back, I was working with an organization on their website usability. We had a meeting to go over analytics. They came to that meeting, everyone grinning from ear to ear.
“I bet you’ve never seen a bounce rate as good as ours before! Our homepage is so great! Our usability is awesome!”
They were right. I had not seen a bounce rate so low before on a public-facing homepage. It was 8%. But everything was not awesome.
The main feature of the homepage was an interactive map. It was in an iFrame. That iFrame had the same analytics snippet as the homepage. The bounce rate was low because a complete load of the homepage loaded two pageviews. When you have two pageviews, you don’t get a bounce.
Other metrics were also a mess. Their pageviews and pages per session were also inflated. Self-referrals were rampant.
Looking for iFrames?
In the above examples, our iFrame problem was easy to spot. But maybe it’s not always so obvious. How can you tell if you have an iFrame problem?
Run an Extract
I like to use Screaming Frog. Screaming Frog is a website scraping tool that is used for SEO purposes. But I love using it to scrape large websites to find issues. You can do this with almost any scraping tool. Or, if you’re blessed with incredible coding schools, you can build your own custom scraper in Python.
In Screaming Frog, I create an XPath extraction that looks for iFrames.
Warning #1: There is such a thing as a benign iFrame.
If you have Google Tag Manager properly installed on your site, you have iFrames on your site. There are other tools like it. Don’t panic if you see them.
Warning #2: You’re still not going to find all the iFrames.
Some third-party tools deliver iFrames via a JavaScript snippet. If your scraper isn’t look at rendered HTML, or the iFrame is triggered by a click, it may not catch it.
Just Ask
Find out all the third-party tools you are using. Over time, you’ll come to know those that are dependent on iFrames.
Okay, I have an iFrame Problem
You’ve reached an important milestone. You’ve admitted you have a problem.
Be upfront early with your stakeholders about this. Not all stakeholders easily understand what it means to have iFramed content. I love Simo’s assessment of iFrames. But now may not be the time to tell folks they (or their developers) are a bunch of lazy SOBs for using iFrames.
I use a variation on a theme of the following language.
When auditing the site, I discovered that xyz feature is delivered through iFrames. Although it looks like it’s on your website, it’s not. It’s coming from somewhere else, and your website is just displaying it.
IFrames can be useful to deploy complex features quickly to a website. Implementing them does not require large amounts of technical know-how. They won’t interfere or interact with other parts of your website.
But they do not lend themselves to integrated analytics tracking.
There is a chance that we will not be able to track activity that happens within the iFrame. And even if we can, it may take substantially more work to get it up and running and maintain it in the long-term.
You’ve set the stage for gloom and doom. Now, let’s see if we can save the world from iFrames.
The iFrame is on your domain.
If the iFrame your referencing is on the same domain as your website, you may be okay. If the parent page and the iFramed page are of the same origin, you should be able to have JavaScript on the parent page “read things” on the iFramed child page.
Note: the domain MUST BE the exact same domain. Not subdomains. Same domains.
The iFrame is not on your domain.
This is where the fun begins. And by fun, I mean your embarkation into an endless and vast hellscape.
Most of the time, if an iFrame is not from your domain, it’s coming from a third-party tool. You need to find out what this third-party tool is and who is responsible for it. Then ask the following questions.
Does this third-party tool integrate with analytics?
Lots of third-party tools have their own analytics integrations. Research the integration. Does it suit your needs? If yes, go ahead and integrate. Just be wary of the pageview (see below).
Can I put analytics snippets in the tool itself?
Can you find a sustainable away, maybe through a template, to place a snippet on the page?
Sustainable is important. It may not be reasonable to ask your client to forever manually add a Google Analytics code snippet on hundreds of pages.
Okay, I can get analytics on the tool.
Congratulations! The hard work is now going to begin.
If you are using Google Tag Manager to implement Cross Domain iFrame tracking. It’s a little bit more than a copy/paste job. But it works, most of the time.
Then, suppress the pageview at all costs. Otherwise, the bounce rate nightmare scenario I described above will come to visit you.
In Google Tag Manager:
- Create a trigger that encompasses the domain on the third-party tool;
- Place that trigger in the exception of the tag that fires your primary pageview.
If it’s not that simple (like, some pages within the domain are “real” pages, and some are iFrames), you can also try this solution from Simo’s Blog: Prevent Tag from Firing in iFrame.
In Google Analytics, you will also want to make sure all domains are in your referral exclusion group.
Now, within GTM, you can start creating custom tags to target the iFrame. You can do clicks and form submissions.
I wouldn’t exactly call it bliss. But hopefully, you’ll get some of your swagger back.