What do you do when you’re stuck with Legacy GA tracking on a third-party platform?
When a website is running an old version of Google Analytics (GA) code, our first step is to upgrade them to the current code set, Universal. But, on occasion, part of the user journey may happen on another domain on some third-party platform where updating code is not feasible. If you’ve setup that third-party platform to track to the same GA Property as the rest of your website(s), you’ll want cross-domain tracking. Without cross-domain tracking, sessions will break when visitors navigate between domains, losing attribution and inflating user and session counts.
Methods for achieving cross-domain tracking between domains that all use the same generation of GA tracking are well documented, but there is no built-in solution when one domain is on Universal and the other is on legacy code (Traditional or Async/Classic). However, you can partially achieve this with a bit of custom code.
Before we delve into how to set this up, let’s look at the caveats of this solution.
In order for this to work, users on your main website have to actually click on a link that takes them to the legacy-tracked domain. This same stipulation applies when using GA’s autolinker. To handle cases where users might visit different domains without clicking between them (either via iframes, or perhaps in separate sessions) then none of these solutions will work and you’re in need of an advanced custom solution.
This solution applies cross-domain linking when users navigate from Universal to legacy, but not the other way around. Note that this Universal-to-legacy navigation only needs to happen once, and thereafter the user’s sessions will be preserved between the domains, regardless of direction.
This unilaterality is only a problem if you have new users arriving directly on your legacy-tracked domain. For example: a user clicks on a paid ad and lands directly on a landing page of the third-party platform (tracked via legacy), then goes to your main website (tracked via Universal), then clicks back to the third-party platform and converts. That would be tracked as two users: one that bounced from a paid ad, and one with a conversion attributed to whatever channel last brought them to your main website (or if they’re a new user, a self-referral or direct, depending on your Referral Exclusion List settings). This method will not solve that issue.
This solution will only work if the legacy tracking is setup to accept cross-domain parameters. In Traditional syntax, this setup would look something like this: pageTracker._setAllowLinker(true), and in Asynchronous syntax it would be: _gaq.push([‘_setAllowLinker’, true]). Without “setAllowLinker”, the legacy tracking will ignore any cross-domain parameters, whether they were sent via another legacy implementation, the method described in this article, or any other means.
To easily check if setAllowLinker is active, you can drop this code into the console on a page running legacy. It will list the GA tracking id and whether or not setAllowLinker is set. If it prints ‘true’ next to the tracking id you want cross-domain tracking on, you’re good to go! If it says false, the best you can do is ask the support team for the platform to activate it.
This is done using a small custom script. It emulates GA’s link decorators, but instead pulls the GA Client ID from Universal and populates it in the URL according to the GA legacy link decoration format.
To implement, grab this script and replace GA_LEGACY_DOMAIN_HEREwith a regex matching the URLs where legacy tracking is present.
Then, place the script on every page running Universal where the user could click over to the legacy-tracked domain. If using GTM, you can deploy using a Custom HTML tag firing on All Pages (or at least on the URLs where outgoing cross-domain behavior occurs).
Once this is published, it should start working automatically! If you have any thoughts or questions about this method, leave a comment below!