Multiple Google Analytics properties for multilingual websites
One of the difficulties of working with a multilingual website is to decide on how to track it. Specifially, if you should use one single Google Analytics property for the entire site, or one property for each part (language) of the website. That’s what I’ll provide some thoughts on in this post.
Now, this is a huge topic in itself, so this post focuses on the Google Analytics Account Structure only - not on the actual implementation. As such, this is what I’ll cover:
- The difference between languages and countries
- Example URL structures for multilingual sites
- Why you should use separate tracking at all
- What does data separation look like in Google Analytics?
- The case for using multiple properties
- Summary
The difference between languages and countries
But what is a multilingual website? For the purpose of this post, a multilingual website is any website that is localised into several language and/or country specific versions.
Technically, there is a distinction between supporting different languages and/or different countries. The combination of language and country can be an important factor. Specially in bilingual countries such as Belgium (French and Flemish), Canada (English and French) or even the United States (English and Spanish).
Depending on how your company is targeting its website (language or country wise or both), you’ll probably use different terminology. But suffice to say, that in this post, I’ll call everything multilingual. The considerations are pretty much the same regardless.
Example URL structures for multilingual sites
The URL structure of multilingual or localised sites comes in many variations. The most common are probably these which are often used to separate either languages or countries:
Separation by language or country
| Subfolders | Subdomains | Domains |
|---|---|---|
| www.example.com/en/ | en.example.com | www.example.com |
| www.example.com/fr/ | fr.example.com | www.example.fr |
| www.example.com/es/ | es.example.com | www.examle.es |
Separation by country and language
The examples above show URL types of language specific website versions. As mentioned, some websites are not just localised for languages, but also for countries. In those cases, it’s common to use browser language identification codes in the URL:
| Subfolders | Subdomains | Domain + Subfolder |
|---|---|---|
| www.example.com/en-ca/ | en-ca.example.com | www.example.ca/en/ |
| www.example.com/fr-ca/ | fr-ca.example.com | www.example.ca/fr/ |
So you see? There are many ways to structure site URLs to accomodate website localisations for both languages and countries, or just one of them.
Why you should use separate tracking at all
There are multiple reasons why you should setup separate tracking for each country and/or language of a website in the first place. And tracking - in this regard - does not refer only to web analytics (e.g. Google Analytics), but also to marketing tracking.
When a company operates a website in multiple countries, the company might have local marketing or ecommerce teams. These teams benefit from access to their country specific data, since these data are related to their local marketing efforts.
This, in turn, enables the option to more easily setup local custom goals and reports that are more accessible and relevant for their daily operations.
There are even practical implications such as being able to see data based on the local timezone (a Google Analytics view only supports one timezone), linking specific Google Ads accounts and more.
For marketing tracking pixels, it’s likely that not all ad networks and marketing channels are in use in all countries. So why should you fire a DoubleClick or LinkedIn tracking pixel in countries where you don’t use it?
What does data separation look like in Google Analytics?
On the surface, the separation of data by country or language can look quite simple in Google Analytics. But as with everything in web analytics, it often looks simpler than it is. But let’s look at the surface to begin with.
Using multiple views on a single property
This is what it usually looks like when using multiple views on one property:
In the example above, one property has been configured for the global portfolio of country specific websites. The screenshot is from a client of mine (obvisouly, I’ve replaced their actual domain names with something else). This particular company has a domain type separation of their website. In fact, they run one CMS to manage 42 different websites that are each located on individual top level domains.
In addition, Google Analytics is implemented with one global Google Tag Manager container. This container collects data from all websites and send the data to a single Google Analytics property.
By using filters on the View level, each view only include data from its configured hostname (domain name). Furthermore, there is one view that includes all data. This allows the company to not only do country specific reporting and analytics, but also global.
The user management is also relatively easy since users' access can be controlled down to the view level.
Using multiple Analytics properties
Similarly, this is what it looks like when using multiple properties instead:
At first glance, it just looks like a dropdown has moved one column to the left. That’s true, but the implementation that allows for this is a bit different.
This screenshot is also from a client of mine. The implementation is done through Google Tag Manager too - and as with the previous example, the GTM container is global and controls all tracking.
This client, however, differs from the previous. Where the first website used individual domains for each country (e.g. example.co.uk, example.fr), this website is located on a single domain. Instead, the language separation is done with subfolders (example.com/dk/, example.com/en/).
Configuration wise in a GTM container, it doesn’t make much difference. Instead of having a Google Analytics Tracking ID hardcoded in the Settings variable, this site uses a look up table to:
- Determine the language (by looking at the page path)
- Looking up the language in a look up table that returns a GA Tracking Code
That way, all tracking is configured in one place, but data is sent to different properties. In addition, there is a roll-up property that receives data from all language versions of the website.
Both approaches are completely valid. The choice between the two approaches depend on your overall tracking requirements - but will also have implications on what you’re able to do with your data.
The case for using multiple properties
So, now you’ve decided that the local versions of your website should be tracked separately. In Google Analytics there are roughly two ways to go about it:
- Use a single property and setup filtered views for each country/language
- Use one property for each country/language
It seems to be that the best practice or the most common advice is to go for option one. For instance, if you search the internet for solutions, you’ll probably come across on several discussions from StackOverflow or on the Google Advertiser Community. Actually, I’ve only managed to find one good article (Tracking Multilingual Sites in Google Analytics) on the subject myself (at least when filtering for trusted sources only).
Interestingly, the most recommended approach seems to be the single property approach. And this bothers me personally, since there is no such thing as a single best practice. In fact, I often see more cons than pros with the single property approach compared to a multiple property setup.
We will discuss this further, but for now, let’s compare the two approaches:
| # | Requirement | Single Property | Multiple Properties |
|---|---|---|---|
| 1 | Total site reporting | Yes | Yes* |
| 2 | Cross Domain Tracking | Yes | Yes* |
| 3 | Sampling | Worse | Better |
| 4 | Allowed no. of hits | 10 million | 10 million per property |
| 5 | Custom Dimensions/Metrics | 20 each | 20 each per property |
| 6 | Search Console linking | 1 GSC property | 1 GSC property per GA property |
| 7 | Limit on no. of views | 25 | 25 per property |
| * “Yes” indicates that this is possible only if a roll-up property is configured |
These are just the ones that I think are really important. But some of these are what I call deal breakers. Let’s take a look at those:
Total Site Reporting
This one comes down to the reporting requirements on the global level. With a single property, it’s rather straightforward to setup a view that includes traffic from all countries. This is often an implicit requirement in companies where a global overview is needed. With one view with all data, it’s easy to setup custom reports or dashboards with the number of total users, sessions, transactions and so on.
But this can be accomplished with a multiple property setup too. It just requires a roll-up property. Now, roll-up properties have been around for a long time. And a common misconception is that they’re only available for Google Analytics 360 customers. They are. But they’re easy to setup manually for free riders too. One excellent approach is described by Simo Ahava in Send Google Analytics Tag To Multiple Properties.
Cross domain tracking
One global sites where local versions are located on different domains, some companies require cross domain tracking to be setup. This, in turn, requires the use of one Google Analytics property only. Which is also why the single property is often recommended for such sites.
But again, this can also be accomplished in a multiple property setup if using a roll-up property.
Sampling
Google Analytics uses sampling to serve your reports as fast as possible. And to reduce the load on their servers. Generally, I find that sampled reports can be both very accurate, but at times also the opposite.
You need to decide if sampling is something you can live with. Or if you want as little as it as possible. The latter is the most common feeling.
And since sampling is tied to the number of sessions recorded on property level, one easy way to reduce sampling, is to use multiple properties. Problem solved! Well, it depends on your website traffic, but at least, you can get some of the way with multiple properties.
Hit Volume
Each property in Google Analytics is allowed to collect up to 10 millions hits per month. Not sessions or users. Hits. Hits are the raw materials of Google Analytics. A pageview is a hit, an event is a hit. And user timings and transactions are also hits.
The thing is that if you surpass the 10 million limit, Google Analytics reserves the right to either stop processing more data, group high cardinality dimensions into (other) or even suspend the property and ask you to upgade to Google Analytics 360. (Note: The only one of them I have experienced is the grouping of e.g. page URLs into (other)).
See the big bunch of (other) pageviews on this report screenshot? It’s useless:
Almost needless to say, if you have just one property for a large website, you’ll use that 10 million hit quota much faster than if you had multiple properties.
Allowed number of views
If your site has more than 25 different countries then you have to use additional properties. The simple reason being that there is a maximum of 25 views allowed on one property (at least in theory; I’ve seen non-360 clients with up to 50 allowed views).
But with a multiple property setup, you can - in theory - have as many views as you’d like. Yes, there is also a limit on the number of properties per account (it’s 50), but then you could setup an additional account. And 50 it’s still double than 25 :)
Google Search Console
For some companies, even the Search Console integration will be a deciding factor. It’s actually strange. Most Google products that support Google Analytics integrations, can be linked on View level. For instance, Google Ads accounts can be linked to different views. But the Google Search Console integration is performed at the property level.
So if you have separate Google Search Console properties for each country (I hope you do!), then it’s actually only possible to link one of them to a single property setup.
A few words on implementation
So, I promised that this post would not be about implementing multilingual tracking. It still won’t. But since you’ve read this far, it would be fair to provide some general pointers. I also touched upon it briefly in the section about how the data separation looks like in Analytcs.
First of all, the single property approach is what I would call a standard Google Analytics implementation. In a relatively simple implementation, this means there would be no significant customisations in your Google Tag Manager container.
In effect, you would setup your pageview and events tags and any other tags using a single Google Analytics Settings variable with just one Google Analytics Tracking ID.
Instead, the data separation would take place in Google Analytics. This is where you would setup the individual views and configure their filters. I previously linked to a post from Jeffalytics, which has a pretty good walkthrough of setting view based multilingual tracking up.
With a multiple properties approach, the data separation moves from Google Analytics to Google Tag Manager - or even to the templating engine for the websites.
For instance, it’s possible to use a Look-up Table in Google Tag Manager to determine which site is loaded, and - based on that - return a corresponding tracking code. This tracking code is then used in all Google Analytics tags and/or in the Google Analytics Settings variable.
Alternatively, it’s also possible to use separate GTM containers on each website version. This potentially requires a lot of extra maintenance, but that is likely to depend on your organisational setup.
Summary
In summary, my general opinion should be clear: As a rule of thumb, use individual Google Analytics properties to track different country or language versions of a website.
Now, there might be practical considerations and no two implementations are alike, so don’t take this recommendation at face value. There are always exceptions.
I wrote this post mostly because the consensus and best practice seems to be to use just one property. But I think there are so many benefits to using a multiple property setup, that I wanted to share my thoughts.
Please write a comment if you’d like to discuss further!