You are here: Tags / iframe
Updated 15 April 2020: Fix the message forwarder to properly clone objects before they are passed to postMessage Here I am, back with <iframe> and cross-domain tracking. I’ve published a couple of articles before on the topic, with my upgraded solution being the most recent one. These articles tackle the general problem of passing the Client ID from the parent to the <iframe>. By doing so, the <iframe> can take the Client ID from the frame URL and create the _ga cookie in the <iframe>, allowing hits from the parent and the <iframe> to use the same Client ID.

Continue reading

**Last updated 18 September 2020: Due to how most browsers now have third-party cookie protections in place, this solution will be very ineffective going forwards. You should instead take a look at a cookieless solution. Some years ago, I wrote a post on how to track cross-domain iframes when using Google Tag Manager and Google Analytics. That solution relied on hitCallback to decorate the iframe, and now that I look back on it, it has its shortcomings.

Continue reading

NOTE! This solution has been upgraded, and the new approach can be found here. If you’re unfamiliar with the lingo, cross-domain tracking is a hack used by Google Analytics to circumvent the web browser’s same-origin policy. Essentially, the policy dictates that browser cookies can only be shared with a parent domain and all its sub-domains. In other words, and do not share cookies. Since Google Analytics calculates sessions and users by using a cookie, this is problematic.

Continue reading

Author's picture

Simo Ahava

Husband | Father | Analytics developer
simo (at)

Senior Data Advocate at Reaktor