Multiple Domains in Google Analytics

Google Analytics uses cookies to store a lot of information about visits and visitors. Because cookies are tied to a single domain, if your site uses multiple domains, Google Analytics will get very confused.

This is what happens when you use multiple domains on your site:

• A user visits your site, and the tracking code places cookies on their machine.
• The user clicks a link to a page of yours on another domain. The tracking code looks for cookies, but it can't read the other domain's cookies. Assuming this is a new visitor, it attributes the visit to a referral from your other domain.
• As the visitor continues to move between domains, their single visit will count as multiple visitors from different sources.
• You will get angry and smash a keyboard.

Parenthetically, a similar thing can happen with multiple subdomains, but the solutions are different.

The Principles of Cross-Domain Tracking

In order to track a visit seamlessly across multiple domains, you need to make two coding changes.

1. Modify the basic tracking code on every page of each domain
2. Add code to every link where the destination URL is on a different domain

If you want them tracked in the same profile, each of the domains should use the same UA number in their code.

These changes will pass the visitor's cookie information to the other domain where they will be duplicated. From Google Analytics' perspective, it will be one set of cookies because they will carry identical information. In reality, you will be creating a duplicate set of cookies on every domain.

This is worth clarifying. If a link on your site sends a visitor to another domain and you want that domain to be counted as part of the same visit, you must tag the link. It doesn't matter how many domains you have; this principle applies to every link on every site where the domain changes. The only time it's not necessary is if the link sends the visitor to a site you're not tracking.

The emphasis might seem unnecessary, but this fundamental principle is commonly overlooked. Incompletely coding for cross-domain tracking is one of the most common reasons for self-referrals in reports.

Change the Tracking Code

Every domain that needs to be tracked as part of the same visit will need three changes made to the tracking code. These changes are made to the code on every page right before the _trackPageview() method.

Our tracking code generator will make these changes for you automatically for every domain. Otherwise, you can make them manually.

_setAllowLinker()

This method must be set to true: _setAllowLinker(true).

This method essentially tells the code to look for cookie information coming from the other domain. When it sees it, it will duplicate the cookies for the current domain.

This method also enables the code that must be placed on each link. This is why it must be placed on both sending and receiving domains.

_setAllowHash()

This method must be set to false: _setAllowHash(false).

By default, the tracking code ties a set of cookies to a domain by making a hash of the domain name and placing that value in the cookies. If your site utilizes multiple domains, though, this will prevent the code from accepting the other domain's cookies because the hash won't match up. Setting this method to false just inserts the number 1 into the cookies in place of the hash.

_setDomainName()

As explained elsewhere, this method will set the cookie path to the domain root or to a specific subdomain, depending on what you specify. It's best practice to set this for each domain when doing cross-domain tracking.

Adding Code to Each Link

LinkTagger Feature

Finally, every link that sends to a different domain must be tagged with code. You can do this automatically with our LinkTagger script, or you can do it manually.

To do it manually, add an onClick event (or equivalent) that executes the _link() method. You must pass this method the full URL that the link redirects to, and it must be followed by return false if it's in an anchor tag. This gathers the visitor's cookie information and appends it in a query string to the link URL; it then overrides the href value and redirects the visitor to the newly constructed URL.

For example,

becomes

Adding Code to Forms

If it's not a link or button, but a form that sends the visitor to a new domain, Google Analytics has a solution for that, too. It's the _linkByPost() method. This method works the same way as _link(), but it gets added to the form tag as an onSubmit event.

For example,

Adding Code to Frames

If you have an iframe that shows a page on another domain that you have code on, you will need to change the src attribute to include the visitor's cookie information using the _getLinkerUrl() method. This accepts a URL, just like _link() and it returns the URL with the addition of the query parameters.

Sometimes it might be necessary to replace the src attribute dynamically with the onLoad event instead.

Adding Code Dynamically

LinkTagger Feature

For a site with a lot of links, this can become a tedious process. Strictly speaking, it's possible to create a script on your site that would dynamically tag each link or form. This could be done server-side with some type of search and replace function, or it could be done client-side with JavaScript, for example, to dynamically add onclick events to each outbound link. Our LinkTagger script does this client-side.

Another possibility for the _link() method in an anchor tag is to pass it a dynamic parameter (eg. this.href) instead of manually adding each URL.

Troubleshooting Cross-Domain Tagging

After you've added all this code, expect to see some drop in the number of visits being reported. Incorrect implementation inflates visit counts. The other biggest indicators that you were successful are the traffic source reports.

Referrals

The obvious place to look first is the referral reports. Change the date range to include only the time after the code was implemented. Then go to the Referring Sites report. Look for any of your own domains. If you see any, click on the top one. Then change the graph to "Compare to Site" and look at what percentage of overall traffic this constitutes.

It's not unusual to see a few self-referrals, even when the code is on the site properly. However, if it's more than a few percentage points, you may have missed some pages or links.

Direct Traffic

Direct traffic is really traffic that the tracking code couldn't identify a source for. Sometimes different browsers under different circumstances will track referrals as direct traffic. If the percentage of direct traffic seems fishy, check the landing pages for it. If those landing pages are unusual URLs, or if they are URLs you know are unlikely to be referenced by third-parties (eg. the beginning of a checkout process), you may have a problem.

Conversions

Another indicator that something is wrong with your cross-domain tracking is if all (or nearly all) of the transactions on your site are attributed to direct traffic and/or a referral from your own site. The missing code is most likely on one of the pages required during the conversion process.

Finding the Gaps

If there are indications that your cross-domain tracking is not set up completely, start by visiting the pages reported as referring sites. Search through the source code to make sure the _link() method is called consistently.

If the _link() method is everywhere it should be, click on a few of the links. When you reach the next page, look in the address bar at the URL. It should contain a long query string with several query parameters that start with __utm. If it doesn't, confirm that the tracking code on each page has been modified and that the _link() method is always followed by return false. Check for syntax errors in the JavaScript.

If all of your own code is set up correctly, then it's possible that the destination page on the other domain is stripping out the extra query parameters. If it's doing a redirect, that is almost certainly the case.

If you still need help, contact us.