Google Server-Side Tagging
With the introduction of server-side tagging in August 2020, Google has listened to the wishes of many customers and delivered an attractive alternative to the established, “conventional” tag manager, which improves a lot in the area of data sovereignty and data protection.
But here you can find out what you should be aware of.
Server-side tagging vs. traditional tagging: What's the difference?
The difference between traditional tagging and server-side tagging (SST) is the data flow. This refers to the path that the collected data from visitors takes until it is processed.
Whereas a Google Tag Manager (GTM) sends the data directly to Google’s servers, when using SST the data takes a detour via a self-defined server. This server can be your own local server, or the server of a service provider, and of course it can also be a Google Cloud Server.
What are the advantages of server-side tagging?
The advantages of SST are actually very versatile. One could probably best summarize the advantages under the terms data sovereignty and data protection. To be more precise, the GTM offers a variety of setting options as to which user actions should be recorded and when, but the customer has no precise insight into what data is actually sent to Google. In terms of data protection, this is not a pleasant situation.
Google offers a variety of documentation and emphasizes again and again how much they take data protection and the correct handling of personal data seriously, but a review of the documentation quickly reveals points that appear at least questionable from a data protection perspective.
That’s why SST comes in handy. It gives you the opportunity to check exactly which data is forwarded to Google for analysis, so that you can intervene if necessary and ensure data protection.
The choice of the server
If you have decided to use SST, you still need to consider what kind of server you want to use. What sounds trivial sometimes has far-reaching consequences in practice. So let’s talk about the different variants.
1. the use of an own local server
A local server would be the best choice from the point of view of data protection, as sensitive data may not leave the company’s own four walls. However, high initial investments as well as maintenance and provisioning costs must be taken into account here. Protection against cyberattacks is then also completely in the company’s own hands, which means that this option could quickly prove to be disproportionately costly.
2. the assignment of a service provider
Alternatively, a service provider can be commissioned with provision, maintenance and security. Preferably, a European provider should be chosen here who can also serve with server locations in Europe, better still in Germany. We advise against American providers or server locations in the USA due to the situation described below.
3. the use of Google servers
The simplest and cheapest option for most users is to use Google servers. However, since Google is not only an American company, but also Google’s business model is based on the collection of data, we have taken a closer look at this variant and asked ourselves what needs to be done in order to be able to deploy SST on Google servers in a way that complies with data protection laws.
Google and other American companies
Since the Schrems II ruling in July 2020, when the EU-US Privacy Shield was overturned, the processing of personal data by US companies is no longer allowed. For European website operators, this means that they have to pay close attention to what data is passed on to Google or other American companies (and their subsidiaries).
This, of course, leads to far-reaching issues that will want to be addressed. We’ve covered some of them here:
- Google’s data must also be stored on European, or better yet, German servers, and the data must be encrypted. It must be taken into account that Google must not have access to the keys for decrypting the data.
- The IP address represents a personal data. To prevent Google from obtaining the user’s IP address, we recommend using a reverse proxy that can disguise the user’s address. This ensures that Google cannot obtain the IP address of the users by, for example, logging the server accesses.
The following graphic shows the use of Google servers as an example:
- If cookies are to be set, the consent of the users is mandatory. However, this eliminates the advantage of tracking without consent and only a fraction of users may be tracked, because tracking can be disabled in the cookie banner with just one click.
- An alternative to setting cookies would be to use cookieless tracking, in which a custom ID is generated by a fingerprint procedure, with which a user can be recognized across sessions, but the ID cannot be interpreted by Google. However, this is also not easily implementable.
- In June 2022, the French CNIL issued a statement on Google Analytics, from which some things can be derived. Thus, much data must be trimmed or removed completely. The CNIL also advises the use of reverse proxies. The fingerprint should be adapted so that it contains a temporal component and thus the individual user can no longer be precisely identified, since each access generates a new ID.
Under these conditions, tracking is made considerably more difficult and the question must be asked whether the use of Google and its various products is worthwhile if the data is hardly suitable for analysis purposes.
Conclusion
It is advisable to start thinking about alternatives to Google and to find out about other providers. Tracking options are already severely limited under normal circumstances, and the use of Google and other American service providers exacerbates this problem.
So until there is a Privacy Shield 2.0, you might want to take a look at providers like Matomo, eTracker or Mapp and consider switching.
Any questions?
Then feel free to call us. We will help you with questions about our product and features or generally about all data protection topics:
