An iframe is a web page embedded in another page. It’s handy little hack that lets you include content from another page in your pages.

I bet you’ve visited many websites that use iframes and you probably didn’t know it. You might even have iframes on your site without you being aware of what they are, how they work or how they might affect your Google Analytics data.

Before I go deeper into the GA issues an iframe could cause, it is important to make sure everyone understands what an iframe is and what it does. In this article I will explore some common use cases for iframes and discuss how they can be used well without wreaking havoc on your GA data.

iframes loading content from the same domain

Lets use an iframe to load Daniel’s biography on this page:

We’re loading content from online-behavior.com on this page which is also on online-behavior.com. This seems pretty trivial but actually, it’s making Daniel’s GA data do some unexpected things.

What happens to Online Behavior’s GA data?

When Daniel checks his GA data he’ll see two pageviews. Unfortunately he’ll see very low values for the time on page and bounce rate metrics for this page…

As this page loads and sends a pageview hit to GA, the very next thing that happens is that the browser displays the iframe. The iframe loads Daniel’s bio page, which in turn sends a pageview hit to GA too. As far as GA is concerned, this looks like you clicked on this article and then very quickly clicked through to Daniel’s bio. GA doesn’t know that the bio is loaded in an iframe. This means the time on page for this page is crazy low and it’s also pretty impossible to bounce from this page as we’re forcing two pageviews to fire in a very small space of time.

This is not great as the data isn’t a true reflection of user behaviour. You may have spent a few minutes reading this far (thanks!) but GA doesn’t show this – it shows a time on page of 1 second or less.

What’s the fix?

Typical Analyst answer – it depends. In this instance, it depends what Daniel wants to have happen to his data. You need to decide what’s right for your data. Let’s explore some options.

You could take page tracking off the iframe. The metrics for this page will be restored but what about the tracking on Daniel’s biography?

What if this wasn’t a trivial example and the iframe contained a form? How’s that going to be tracked?

You could filter the iframe pages into a view for conversion tracking but make sure you know whence the user came when attributing conversions to channels. The solution to preserve your data quickly gets very complex as is normal with an ‘it depends’ type answer.

The actual fix is to not do this in the first place. Your data is compromised as soon as you decide to compromise the page implementation using a iframe.

If you have key content, like a form, that you want on the page, build it properly and track it properly. If it’s key to your business, making the effort to build your pages right is a sound investment that will deliver a return.

iframes loading content from a Subdomain

Loading the content in the iframe from a subdomain is just as bad as loading the content from the same domain. It’s a compromise. Don’t do it.

iframes loading content from a 3rd party domain

You’ve probably seen this scenario a lot. Think about sites where you’ve seen links to news stories with “Recommended by Outbrain” or “Sponsored content by Taboola” on news pages. It’s a common content syndication solution. Most sites showing adverts will display the ad in an iframe. The ad is chosen by another system and displayed from a 3rd party ad server.

These use cases are good examples of where iframe behaviour is desirable. Browser security settings (The Same Origin policy) prevent 3rd party iframe content from interacting with the outer page. This is a good thing for the safety of users.

Whilst this case is well understood and a correct use of the technology, this is actually where you need to be properly terrified. Okay, that’s a little strong but you do need to scrutinise the iframe behaviour very carefully.

Content syndication

So you’ve displayed clickbait content syndication on your site. If you’re syndicating 3rd party content to monetise your site, your data will not be affected. If you’re using Taboola or Outbrain to syndicate your own content you need to check your data and GA configuration.

If you see an increase in sessions and a drop in the average session duration then you need to take a look at the referrers report. Do you see Outbrain or Taboola in there? Yes? Make this change to the Referral Exclusion List (found in GA property Admin under Tracking Info):

This prevents session breakage. All referrals in Universal Analytics create a new session. Clicks on content syndication links to your site should not create a new session. Adding these domains (and their subdomains) to the referral exclusion list stops new sessions from starting and preserves the original traffic source.

If you’ve seen referrals from these domains and you’re syndicating your own content, through these networks, adding the domains to the referral exclusion list now won’t fix your data straight away because of the default 6 month campaign timeout. Read more about referral exclusions at https://support.google.com/analytics/answer/2795830

You could patch your data using a modified channel grouping such as this:

You won’t see the Taboola or Outbrain referrals in your historic data but it won’t fix the session breakage – it’s a patch. The best bet is to get the content syndication domains in the referral exclusion list before using them on your site.

3rd Party Ad Serving

Okay, say your site is a publishing site rendering an ad. Maybe the ad click is heading off to another 3rd party. The advertising tech probably handles the ad serving and click measurement. No worries.

However, there are two scenarios worth considering.

1. The ad click takes users to your site

DoubleClick ads are rendered in iframes. If you’re rendering “internal” banners to drive promotions on your site (sometimes called House Ads), the ad clicks will end up on your site.

Fine, you’re using something smart like DoubleClick for Publishers (DFP) so your measurement (assuming you’ve setup the tool correctly) will be unaffected (read more about the GA360+DFP integration).

Check your data if you use alternative marketing software to render your house ads. Make sure your precious channel data is not polluted by referrals from the iframe 3rd party domain.

2. The iframe loads resources from your site

What if you’re rendering rich media ads and/or there is some communication between advertiser and publisher content? You might use the DoubleClick Rich Media iframe approach.

If these instructions aren’t followed and DARTiframe.html doesn’t exist or can’t be found then you’ll end up with a third party requesting content from your domain on the user’s behalf resulting in a 404 error and session data breakage.

You’ll know you’re in trouble when you see a step change drop in your session duration and an increase in referrals from tcp.googlesyndication.com. You may also see the inflation in requests for DARTiframe.html (with tcp.googlesyndication.com as the referrer) if you’re tracking 404 errors. There is a wealth of documentation out in the wild on the internet that might suggest your ad autotagging is incorrect. This will lead you down a false path. Look for DARTIframe.html requests to confirm ad autotagging is not the issue.

Closing summary

Used properly, iframes are excellent tools to render 3rd party content safely. Used badly, the user experience suffers, your data becomes meaningless and your site becomes a rat nest of hacks and make-do compromises.

Choose your markup carefully and be aware of what the possible effects are on your data.

In a fast moving, complex organisation you may not have 100% control over all pages and all campaign implementations. Maintain visibility of your data and prepare to act if you see symptoms of pollution, reduced data quality and unexpected step changes in key metrics.