Track
Subdomains, several domains and hash routes
Count a site that spans subdomains or several domains, tell the hostnames apart, and record pages in apps that keep their routes in the URL hash.
This page shows how to count a site that lives on more than one hostname, and how to record pages in an app whose addresses differ only after the #. After reading it you will know what one tag on several hostnames gives you, and what it does not.
One site across subdomains #
Use the same tag, with the same site key, on every subdomain you want counted together: the main site, a blog on its own subdomain, a help centre, an app. All of them report to one site in the dashboard.
Subdomains of the domain you entered for the site are treated as one place:
- A visitor who moves from one subdomain to another on the same day stays one visitor, and the visit goes on.
- A link from one of your subdomains to another never counts as a source. Your own pages are not a referrer.
- A leading
www.makes no difference to either rule.
Every hit is stored with the hostname it came from, so you can still take the numbers apart.
- On the Overview, the Sources card has a "Hostnames" tab that lists each hostname with its visitors. Select a row to filter the whole dashboard by it.
- The Hostname filter works on every screen that takes filters. It can match one hostname, leave one out, or match every hostname that contains a piece of text. Filters and saved segments explains filters.
If you never want to look at two subdomains together, give each its own site, and with it its own key. To keep a hostname such as a staging server out of your numbers altogether, add an exclusion rule for it. See excluding visits.
Several domains #
The same tag can also sit on a second domain, for example a shop on a domain of its own next to your main site. Nothing has to be set up for that. Every hostname that sends hits with your site key reports to the same site, and the Hostnames tab and the Hostname filter tell them apart in the same way as subdomains.
One thing is different, and it matters for your numbers. A visitor who moves from one domain to another is counted once on each. A visitor is recognised within one domain, and by default without cookies and for one day. On a second domain the same person is a new visitor with a new visit, also when Remember returning visitors is on: its cookie belongs to one domain and its subdomains. For a site on two domains this means:
- The visitor total of a day is higher than the number of people, by everyone who crossed over.
- A visit that crosses over is split in two. The first half can look like a bounce, and the second half shows your other domain as the site it came from.
- A funnel whose steps lie on different domains is not completed by a visitor who crosses over.
Following a visitor from one domain to another is not built. What works today lists it under the parts that are missing.
The cross-domain option #
You will find an option for this in two places: the attribute data-cross-domain on the tag, and a "Cross-domain" switch with a list of allowed hostnames under Settings, Installation, Tracking options. Neither follows a visitor across domains yet, and the text next to the switch says so. The script reads the option and then ignores it: no id is made, no link is changed and nothing is stored in the browser.
Two side effects are real, so you know what you are switching:
- With the switch on, a visit that arrives from one of the hostnames on the list is no longer shown as coming from that hostname. It is treated like a link between your own pages.
- With the switch on, Settings, Installation prints the tag for the full script. Counting is the same with either script.
Neither makes two domains share a visitor. With debug logging on, the script writes one line to the browser console saying that the option is ignored.
Hash routes #
Some apps keep the current page in the part of the address after the #, and the part before it never changes. Without help, every page of such an app looks like the same path, because the script leaves that part out.
Switch on "Hash page paths" under Settings, Installation, Tracking options, or add data-hash-paths="true" to the tag. Owners and Admins can change the setting, and a change takes up to 5 minutes to reach your site. From then on:
- The part after the
#belongs to the path. A page is recorded as/#/pricing, or as/app#/settingswhen the app does not sit at the root. - A change of that part counts as a new page view.
- A query string is still removed, also when it stands inside the part after the
#.
Only switch this on for an app that really routes this way. On a normal site the # marks a jump to a heading on the same page, and with the option on every such jump would be counted as another page view. That inflates your views and uses up your allowance.
The option changes how paths are written from the moment it is on. Pages recorded before keep their old paths. Page steps of funnels and page goals follow the same rule: write them with the # part once the option is on.
Client-side navigation needs no extra code #
An app that changes pages without a full reload, a single-page app, is counted without any code of yours. The script notices when the app changes the address and records a page view whenever the path is different from the last one. Going back and forward in the browser is covered too.
A change of the query string alone is not a new page, since the query string is never part of a path. The install guides show where the tag goes in each framework.
Next: Script options, Filters and saved segments, Excluding visits