Server Side Tagging
Short preparation: What is tagging?
Tagging in general is setting up and configuring web analytics and marketing tracking implementations, such as Google Analytics or the Facebook / Meta Pixel. Each individual logical unit (“send page view to Google Analytics”) is a tag.
Mostly, you use a tag manager for this, i.e. software that makes this configuration particularly easy and ensures that you don’t have to program everything, but can set up a lot via a convenient interface. By far the most popular tag manager is the Google Tag Manager, but there are also Tealium, the Matomo Tag Manager and a few others.
The classic variant: Client Side Tagging
“Client” in this context is just a more general word for browser.
So, in simple terms, the process looks like this:
Basically, this has been the standard solution since tracking was invented - this is how data has always been collected.
It worked reasonably well for a long time, but the problems with this principle have become more and more obvious over the last few years:
Problem 1: Lack of data protection
Even if you configure the tracking with a lot of effort so that you know exactly which data you are tracking: You have no control over some data! If the browser sends data to facebook.com, for example, this will inevitably always include
- the IP address of the user
- the name and version of the browser (as part of the so-called “user agent”)
are sent along. This is technically not possible otherwise and is nevertheless problematic, because at least if you ask European courts, already this information is personal data, which must be specially protected at the latest since the introduction of the GDPR.
Problem 2: Poor data quality
Data quality is closely related to data protection and is primarily linked to two developments:
More and more users are using adblockers, which often no longer just block ads, but also block purely analytical tracking, even if this would not bother the vast majority of users at all.
Anti-tracking mechanisms of browser manufacturers
Many browser manufacturers have developed rules with which they want to protect the privacy of their users and, in particular, curb cross-website tracking. Safari (Apple) and Firefox (Mozilla) lead the way, along with a few even stricter niche browsers like Brave. Even I, as a tracking professional who thrives on data collection: this is a good thing and a step in the right direction!
Google Chrome, which has by far the largest market share, has not yet adopted any of these restrictions. A shame, but understandable considering Google generates over 90% of its revenue from online advertising.
Problem 3: Load times & performance
In addition, all the tracking data sent also takes up a lot of bandwidth, which is then not available for the really relevant content - text, images, videos; the actual website loads more slowly.
The further development: Server Side Tagging
The solution to the problems explained above: Server Side Tagging. Here, the process described at the beginning is supplemented by a step, the eponymous tagging server:
Instead of sending data directly from the user’s browser to the data recipient, it is sent to the tagging server beforehand and only forwarded from there to the final recipient.
The tagging server belongs legally-organizationally to the operator of the website. At least in the first step, the data does not leave its sphere of influence.
The tagging server could also be called a “server-side tag manager” because it performs the same task as a tag manager in the browser, namely processing incoming data, converting it to the appropriate format if necessary, and then forwarding it.
Technically, however, it works differently: a server side tag manager is a full program,
cking infrastructure has significant advantages:
Advantage 1: Data protection through full control.
The tagging server not only forwards data, but also offers the possibility to edit the data on its way to its destination. You can add, edit, and even remove information from the data. For example, the IP address: From a technical point of view, data recipients such as Google Analytics no longer receive their data from the user, but from the tagging server, and accordingly only see the user’s IP address. This has nothing to do with the user and is irrelevant in terms of data protection.
Or the example of the user agent, i.e. the browser’s automatically sent and rather unique browser ID:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/184.108.40.206 Safari/537.36
You could set up the tagging server to extract only the analytically relevant information (“Chrome”) and discard the rest of the details. This way, in the spirit of data economy, only the user’s data is collected that is actually analyzed.
Advantage 2: More complete data
Browser restrictions on client side tracking may sound annoying at first, but they make sense if you realize that they are chosen to still allow data collection - just under more user-friendly and secure conditions. A few examples:
Longer cookie lifetimes
However, longer durations can be achieved via HTTP cookies and these can be set by the tagging server. The special thing about this is that HTTP cookies can be configured so that scripts embedded in the website cannot read the cookie, but only the server has access to it (via the “httpOnly” flag). The information in the cookie is thus better protected.
Less influence through adblockers
Adblockers are intended to block not only advertising banners, but also the uncontrolled outflow of personal data from the browser. With server side tagging, the data does not leave the organization, at least in the first step, and the requirement of adblockers is met. Most of them do block outgoing data to external domains like google-analytics.com, but not to an own subdomain like data.example.de.
Advantage 3: Better browser performance, tagging server does the work
With client side tagging, a data packet must leave the browser for each tracked event and each connected tracking recipient. On tracking-intensive pages, hundreds of outgoing requests quickly accumulate:
The home page of spiegel.de makes over 350 requests as soon as the page loads, the vast majority of which are for analysis and advertising tracking. The 4.4 MB transferred could have filled 3 floppy disks at the time.
With server side tagging, information (“Product X has been added to the shopping cart”) theoretically only has to be sent once from the browser to the tagging server. Only from there - without any negative impact on the user experience - this information is then redistributed many times to the respective recipients. The computing and bandwidth effort remains the same, but now it is rightly borne by the website operator.
What does a tagging server not do?
Server side tagging is not a suitable means to avoid legal and moral obligations in data collection. The fact that the paths of the data are no longer traceable in the browser, but take place on the tagging server, invisible from the outside, has no impact on privacy requirements.
The vast majority of tracking will continue to require user consent. So server side tagging is also not a path to “consentless tracking.”
What does all this have to do with owntag - what do you even do?
Setting up a tagging server is not trivial, and even once it’s up and running, you have to make sure it remains accessible and make regular updates.
And that’s exactly what owntag does with the most popular tagging server: the Google Tag Manager Server Side Container. While you can also run the software directly on Google’s infrastructure, that has two major drawbacks:
It’s not really easy and intuitive Google is a US company and therefore does not offer sufficient protection for your users’ data from the perspective of European data protection law
With owntag you get
- a really simple setup, even if you don’t know how to program
- a completely European infrastructure, i.e. a server physically located in the EU and owned by a European company.