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.

Client side tagging means:

1. tracking control, i.e. what data is sent when and where, is controlled by JavaScript in the user’s browser.
2. tracking data is sent directly from the user’s browser to the data receiver without any detours. For example, the browser sends a “pageview” event directly to www.google-analytics.com.

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

As a website operator with client side tagging, you have little control over exactly what data reaches the data recipient: For example, to include Facebook tracking, you load a JavaScript file from Facebook’s servers whose function can change at any time without you necessarily noticing.

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”)
• cookies

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:

Adblocker

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

Running analytics and marketing tracking in the website uses a lot of JavaScript, most of it completely unoptimized as well. This demands a lot of work from the browser, which you quickly notice as a user, especially on slightly older smartphones.

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/103.0.0.0 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

Cookies set by JavaScript are limited by Safari and Firefox to a lifetime of 7 days, which makes it impossible to recognize users over longer periods.
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 of this have to do with owntag - what do you actually do?

Setting up your own Google Tag Manager Server Side Container with a cloud hosting provider used to be complicated and only for DevOps experts. On top of that, there is the ongoing effort for monitoring and updates as well as the complicated questions about the impact of hosting on data protection.

owntag solves these problems:

• Anyone can host a Server Side GTM Container with owntag - with just a few clicks and in a few minutes
• owntag takes care of monitoring and ensures that your container is always reliable
• With owntag, you have a simple pricing model that makes it much easier to plan what you need to budget for your SGTM setup
• Data protection is a top priority at owntag - that’s why we exclusively host on European cloud infrastructure

→ Sign up for an owntag account now and test your own SGTM container for free immediately.