If there’s one topic that caused uncertainty in marketing within the last years, it’s data quality. And if there’s one topic that has been sold as the shiny amazing solution to get all your data back, it’s Server Side Tracking.
And honestly, Server Side Tracking is great. It can lead the path to higher data quality and it can even “bring back” some of the data that seemed to be lost for so long. But let’s be real: It won’t solve all the issues we’ve got with marketing- and analytics-data.
I’ve been talking about that a lot within the last 3 years, on-stage, as well as off-stage, on Measurecamps, with colleagues, with customers and partners and sometimes even on LinkedIn. The interesting thing: No matter where, when and how we talked about Server Side Tracking, the questions stayed the same.
So I figured, why not write a very long blog post to answer all the questions and talk about everything in detail. Let’s go?
If you’re actually thinking about taking the time to read the next 4000ish words, you’ll know
- what server side tracking..
- and what server side tagging is and why these two things are not the same
- what problems we’re even talking about when we’re talking about “problems with data quality”
- how server side tracking can help with that and what advantages it has
- what the disadvantages and the limits of server side tracking are
- which ways there are to set up server side tracking and which way might work the best for you
- how exactly you set up and test it
Probably I’ll even write a little more, but these should be the key points. Obviously, 5000ish words are a lot to read – therefore you can just skim and skip to whatever sections are relevant for you. On desktop, you’ll see the table of contents in the left sidebar, on mobile there’s a tiny icon on the bottom right.
Ready? Let’s start!
Server Side Tracking, Server Side Tagging, Server Side GTM, Tagging Server, Tracking Server – what do all of these even mean? A quick definition.
Server Side Tracking, Server Side Tagging, Tagging Server, Hybrid Tracking, Cookieless Tracking, Consentless Tracking, Tracking Server, Client Tracking, Client Side Tracking, Tagging Server, Server Container – I’m not sure how it could get any more confusing.
Therefore, let’s begin at the very beginning with a tiny definition:
Client Side Tracking
When speaking of client side tracking, we’re talking about the setup most of us think of as the “standard” tracking. With Client Side Tracking, a tracking script is loaded in the user’s browser and the information is sent directly to the pixel vendor.
Still sounds complicated, here’s a picture to make it clear:
As it’s super easy and convenient to implement (and probably because it’s free), Client Side Tracking has been the Web Standard for as long as webtracking existed. Most of us didn’t really think about data control, ownership and privacy 15 years ago anyways, if we’re totally honest, so webtracking seemed to be the best solution back then.
Server-To-Server Tracking
Talking about what we cared about 15 years ago.. Do you remember these tiny little website visit counters we had back then on all the crappy blogs and web pages that existed? Yeah, this was basically a very early version of server side tracking.
With Server Side Tracking (Server to Server), we’re omitting the user’s browser by sending tracking pings directly from the web server to the analytics- and marketing-vendors. That way, we avoid all the browser side tracking restrictions as for example ITP or Ad- and Cookie-Blockers that take a toll on our data quality.
The big disadvantage with classic server side tracking is that it’s kinda rigid and not really easy to implement. You’ll need developers for every single tiny change as well as for the initial setup, and, as we all know, good developers are hard to find and very seldomly have time for tracking.
Another thing we need to note: Pure, classic server-to-server-tracking dosen’t quite work that well for Marketing-Tools. While it’s okay for tracking, most of the relevant features like remarketing and audience-building are primarily designed for the user’s browser being involved to some extent.
Server Side Tagging (psst, this is probably what you’re looking for)
That’s where Server Side Tagging enters the game. In Marketing Context, Server Side Tagging and Server Side Tracking are often being used as synonyms, when, technically, Server Side Tagging is only one form of Server Side Tracking.
Nowadays, the most common solution for Server Side Tracking is Server Side Tagging via Google Tag Manager, at least since Google launched the GTM Server Container Public Beta in 2020. In order to keep that blog post as short and lean as possible, I’ll focus on the GTM Server Side Tagging Solution for the time being.
Here’s a picture of how Google sets the best practise for Server Side Tagging via GTM:
What you can see here is what I’m calling Client-Server-Hybrid-Setup. Let’s talk about that in a bit more detail:
Client-Server-Hybrid:
With this Setup, you’re still using the Client Side GTM you’re used to from webtracking, but instead of sending data directly to your Ads- and Analytics-Tools, you send them to a dedicated Server, oftentimes a Google Cloud Server, called “Tagging Server”.
We’ll talk about that later on in more detail. The Tagging Server is connected to your Server Side Google Tag Manager Container, which is the place where you pick up the incoming hits, modify them to your liking and send them to your Analytics- and Ads-Tools.
Server Container Only:
Theoretically, you could ditch the Client Side GTM altogether and just send your hits from your Webserver to your Tagging Server directly. While this is a possibility, I feel like it kind of takes away the flexibility you gain with the Client-Server-GTM-Setup, as you get not that many more advantages, but at the same time the disadvantages from the ancient Server-To-Server-Tracking-Solutions.
In my opinion, Server Side Tagging with the Client-Side-GTM-Server-Side-GTM-Hybrid-Setup is the best of both worlds. The Setup is comparably easy, you only need minimal developer resources for the initial configuration, all further adaptations and extensions can be done by whoever is able to operate the Google Tag Manager, without access to the website source code. Simultaneously, you get the data control you want and – depending on the setup – the higher data quality we’re all longing for.
The Client-Side-GTM-Server-Side-GTM-Hybrid-Setup might be the worst of both worlds, too, though, as it’s still highly dependant on the Client Side GTM, therefore on the user’s browser and it also still leverages Cookies – which is exactly why we’ll be talking about the advantages and disadvantages in more detail later, let’s just quickly finish the definitions of the technical terms we’ll be working with for the rest of this post.
Tagging Server
The Tagging Server is – as the name tells – a Server with the sole purpose to receive, store and process incoming hits and send outgoing Tracking Calls to Ad- and Analytics-Tools.
It’s usually not the same server as the web server (that’s responsible for running the website). Most of the time, it’s a Google Cloud Server, as this is the official Google Best Practise.
If you take away only one thing from this blog post, let it be this one: Stick to the best practice. Use the Google Cloud Server. It’s possible to use another Server and it might be a few bucks cheaper, but in all the years I’ve set up and maintained tracking, I’ve never, like really never, not had any troubles with using another server.
Cookieless Tracking
Cookieless Tracking means Tracking without Cookies.
Oftentimes “Server Side Tracking” is being used synonymously to “Cookieless Tracking”, which might be one of the biggest misconceptions around Server Side Tracking or Server Side Tracking – which is not always cookieless after all!
Server Side Tracking as well as Server Side Tagging can still rely on Cookies of some sort, technically. The other way round, Client Side Tracking can also be set up cookieless. I generally wouldn’t advise to go full-cookieless, as most marketing tools and features just still do work better when cookies are involved.
And after all, cookieless doesn’t mean consentless.
Consentless Tracking
Consentless Tracking means “Tracking without Consent”, so without getting the users’ to agree with being tracked before sending any tracking pings out – and by that, I mean all tracking pings, not just the cookie based ones.
At least in Germany, I’d strongly recommend thinking twice before setting up any kind of tracking without consent. It’s not cool and, depending on your setup, it might not be legal either.
Reminder: From this point on, we’ll narrow down all the following content to the Client-Side-Server-Side-GTM-Hybrid-Setup, as that’s the right setup for most of the companies out there and we’re already at about 1.500 words and we’ve still got quite a few topics to cover. We’ll also refer to it as “Server Side Tracking”, as “Client-Side-Server-Side-GTM-Hybrid-Setup” might have been the accurate description for the term clarifications, but is not exactly a catchy term to use.
The advantages and disadvantages of Server Side Tracking
We already scratched the surface of this topic, but if you’re really thinking about putting the time, effort and money into setting up Server Side Tracking, I think, we should talk about advantages and disadvantages in more detail.
That’s why I made a (probably still non-comprehensive, but very long) list of all the pros and cons that came to mind:
The Pros: Why Server Side Tracking can bring your marketing to the next level
- It’s less vulnerable to browser-side tracking restrictions
- You can adapt, manipulate and adjust the data (in a good way) before sending it to your Ad- and Analytics Tools
- Which can improve your data quality dramatically
- You have full control over the data that gets sent out
- Therefore you can avoid and actively prevent privacy messes and breaches
- You can not only set up server side analytics tracking, but all the common conversion APIs, too via Server Side GTM
- Which will raise the pixel-quality score in your ad-tools
- And also give the algorithms more to work with, so you’ll probably get better results with your ad-campaigns
- You can actively avoid tracking bot-traffic, leading to higher data quality again.
- In return, you can also actively track bot traffic (separated from your real website traffic, of course), which might be a cool thing to do if your server admin is sick of providing server logs to your SEO team every other month
- It’s way harder for competitors to retrace what you’re doing, tracking-wise, and therefore what could be the intention of your marketing campaigns
The Cons: Why Server Side Tracking might not be the right solution for everyone
- While the Server Side GTM Container is free, the Tagging Server probably isn’t (unless you’re using Stape and your Website gets less than 10.000 event hits per month)
- The Setup is more technical and complex than the classic standard client side tracking
Does everyone need Server Side Tracking?
While the Pros outweigh the Cons, setting up server side tracking is super fun and you actually can skyrocket your data quality when using it correctly, the answer is still:
No, not everyone needs server side tracking.
Don’t get me wrong, I love setting it up and maintaining it and developing tracking and marketing strategies including all the new possibilities server side tracking gave us. Still, it’s quite a bit of effort and it’s only worth it, if you actually use the data you’re collecting.
At miralytics, ironically, I decided against it – in fact, I decided against tracking altogether.
For most businesses, I’d advise going for Server Side Tracking at some point, though. You really can do cool stuff with it.
Step by Step: Setting up Server Side Tracking with Server Side Google Tag Manager
You’ve read about 7 pages about Server Side Tracking already, so I’ll just assume you made the choice to work with Server Side Tracking from now on. Congrats, you’re in for a fun time when setting the Containers and the Server up!
In this next section, I’ll guide you through the full setup, give you some recommendations on which tools to use and how to debug and test the setup before Golive. If there are any questions left, don’t hesitate to shoot me a message at mira@miralytics.io!
Step 1: Set up your Client Side GTM Container
If you’re ready to take the leap to Server Side Tracking, you probably already have a Client Side GTM up and running. If you don’t, just go to tagmanager.google.com, create your account and container and implement it according to instructions.
For the Client Side Container, you should use the “Web Container”.
You can set up all tracking you want in your client side container.
For this step by step, we’ll be working with the GA4-Tag, so make sure you have that one in place.
Step 2: Set up your Server Side GTM Container
Next, we’ll set up our Server Side GTM Container. In order to do that, you create a new container (just as you did with the client side container), but instead of “Web”, you need to choose “Server”.
Immediately after having created the container, you’ll be getting asked to set up the tagging server and you’ll be given two options here: Providing it manually or going for automatic provision.
You want to choose to manually provide the tagging server here, as you want to have that control and the features that come with manual provision, for example choosing your own tagging server domain.
Copy the Container Configuration Code, you’ll need that in our next step.
Step 3: Set up your Tagging Server
As mentioned previously, I strongly recommend to go with the official recommendation to use a Google Cloud Server as your Tagging Server. The probably comfiest way to do so is using a third party provider. That way, you don’t really have to care about maintenance and server uptimes – and let me tell you, tagging server maintenance is so annoying, you really don’t want to deal with that.
I prefer using stape, so this is what we’re going with for this step by step guide. First, let’s set up our account there!
I used the “EU” location, you can choose whatever you want here, if you want your tagging servers to be located in the EU, I recommend going with EU, though. It doesn’t make a difference in pricing.
After setting your password, you want to log in and set up a new SGTM (short for Server Google Tag Manager) Container by clicking the button in the top right corner of the “recent sGTM Container” section:
Still got the container configuration you got earlier? You need that one now. Paste it right into the “Container Configuration” Field!
You also need a container name and need to set your server location. I’m using France here, for no business-relevant reason. I only just finished Emily in Paris and am still dreaming of France.
After clicking “Create Container” you need to choose your plan. I recommend just turning the “Auto Upgrade” Setting on, that way you don’t have to worry about choosing the right payment plan.
Step 4: Configure your Custom Domain
We’ve got our containers and our Tagging Server, which means we’re getting closer to the final setup!
Next step is choosing a custom domain name. This domain name is relevant, because it’s the domain that’s displayed on your tracking hits – if you want to get the most data quality of your setup, I recommend to use something related to your own website domain so that tracking blockers and browser tracking preventions don’t catch on and block the tracking requests immediately.
With Stape, you can configure a custom tracking subdomain, which is the easiest way to set up your tracking domain. It’s strongly advised to use something non-tracking-related so that the domain doesn’t get blocked by tracking blockers.
I personally like to use the worst puns or Taylor Swift references I can think of, but yours is totally up to you. Whatever subdomain name you’ll be going with, you can set it up by clicking “add custom domain” and just entering it in the “domain name” field.
There’s a lot of other options to choose from:
Add CDN: You can do this, if needed, but it tends to make the set up a bit more complex.
Use A records instead of CNAME records: This doesn’t really matter in terms of complexity, but you can only set so many A records on your domain, which is why CNAME is the standard.
Connect Automatically vs. Manually: Doesn’t really matter, either, for the automatic connection, you need to add the login details to your server provider and give Stape permission to connect the domain, though. This is something I personally try to avoid, but that’s on me, I just have general trust issues. So I go with manually and will continue this step by step with the manual configuration, just in case anyone else has the same trust issues (or simply dosen’t know the login details to their DNS provider).
Step 5: Set your DNS Records
Thankfully, the manual configuration is super easy. You just need to set a CNAME record with your chosen subdomain as shown in the interface:
Usually, your Server Admin will take care of that.
Click verify and wait up to 72 hours 🙂
Step 5: Adjust your Client Side GTM Setup
While we’re waiting, we can as well finish our set up, shall we?
Let’s start with the GTM Web Container. If you’re using GA4, with Client Side Tracking, you’ll be sending the traffic directly to Google Analytics. With Server Side Tracking, we don’t want to do that anymore, we want to send it to our Server Container.
This can be done by adding your Server Container URL into your Client Side GA4 Configuration Tag.
I’m using the gTag and a dummy Google ID here, looks like this:
If you’re setting this up, just leave your Google ID at your actual ID, no need to change to a dummy ID.
Do not publish yet!
Step 6: Adjust your Server Side GTM Config
Before finally setting up the Server Side GTM Tags, we need to add our tracking domain there. You can do so in the Container Settings by clicking “add domain” and inserting your tracking subdomain there.
Save your configuration by hitting the Save button in the upper right corner.
Step 7: Set up your Server Tags
Yay, we’re getting there!
Last step (before testing) is actually setting up your Server Side Tracking. We’ll be using GA4 as an example here.
When logging into your Server Side GTM, you might notice that it looks a tad different than your regular Webcontainer. That’s because the mechanisms are a bit different. Other than the Browsers (and your highly browser-dependent Webcontainer), Servers usually don’t speak Javascript – so your Server Container needs a bit of a translator.
In order to not overcomplicate this, we’ll be ignoring this for now, though, as the translations for GA4 are basically all built-in. So you can just go ahead and create a tag, just like you’re used to.
Looks very similar to the Web Tag because it is. Biggest difference: It inherits all the data from the Web Tag Hit – so, technically, you can leave everything empty, even the Event Name, as it auto-populates.
What you do need, is a trigger, though.
For this setup, I just want everything to work exactly as it does with the Web Container, only from the Server. Therefore, I set up a trigger that fires on all GA4 hits it can capture.
Done 🙂
Well, not exactly done. Rule number 1 (and trust me, I learned to obey that rule the hard way): Never, never, never publish without testing.
Testing and debugging your Server Side GTM Setup
So, before finally finishing this blog post, let’s just quickly touch base on what could possibly go wrong and how to test and debug your Server Side GTM Setup.
Just like the Client Side GTM, the Server Side GTM Container comes with its own preview mode, wich makes debugging a lot more managable.
The Debug View
Here’s a screenshot of what the Server Side Debug View looks like. We still got the Tags and Variables Tabs, these two do exactly what you’d expect: They are showing the fired (and not fired) Tags and the Variable Values going with the different events.
The Event Data kiiiind of compares to the “DataLayer” Tab in the Client Side GTM Preview.
You will see everything you pass from the Client Side Tag to the Server Side Tag here as well as some standard information here. I blurred some of the values in the attached screenshot, but you’ll get the drill.
The Request Tab is where it gets interesting: You can see all the incoming and outgoing http-requests there.
That means, if you want to test or debug your setup, the request tab is your friend!
By clicking on the requests, you can see them in more detail, so let’s take this standard analytics page view request and see what it means:
Checking the Outgoing HTTP Request
The Outgoing Request Tab is one of the things you might want to look at if something in your tracking fails. Just as the name suggests, you’ll see the outgoing request there along with some variable information, the status code and everything else that’s relevant to determine if your request got through accordingly.
You can find an example down below, again, changing and blurring all identifiable information here.
Depending on what you want to find out, you need to look at different things in the request. Because this last sentence wasn’t helpful at all for your debugging journey, I’ll take you through some examples 🙂
Tag that sent this request: This is an important one if your Server Side GTM Setup is more than just one Analytics Tag. You can see which Server Side Tag is responsible for that specific Request going out.
Request: That’s the request itself, in that case a relatively standard GA4 request. They are built very much alike, so getting to know some of the parameters might be helpful for debugging. The ones I’m looking at in most cases are:
- tid: This is your GA4 ID. If you find the wrong ID here, you might have an tracking issue.
- dl: This is your document location, aka the URL you’re on. Should be, in most cases, the URL you’re seeing in your browser tab, unless you did some modifications in your Setup.
- en: That’s your event name. This should be the Event Name you expect to see in your GA4 Interface.
- ep: These are event parameters. If something dosen’t go right, it’s oftentimes there. In our test request, you can see one event parameter named “sprache” with value “german”.
Status Code: Should be something 200-ish 🙂
There’s much more to say here, but we’re approaching 4k words, so I’ll just leave it at: Learning about how the requests look for each platform you want to use might go a long way, not only in debugging, but also in understanding what’s happening under the hood 🙂
What about the incoming http request?
Funnily, the incoming request looks almost exactly like the outgoing in our example, so I don’t put another screenshot here. You also check it basically the same way and in case of GA4 with the same variables.
Only difference: If the incoming request shows some errors, you should go check on your client-side GA4 Tag – as this is the one coming in here.
There are no requests coming in or out. What now?
If you can’t see any incoming or outgoing requests or events or.. well, if you can see basically nothing, please don’t worry. It’s not good and it indicates that something’s not working right, but it’s very common and surely fixable 🙂
So, if you don’t see anything, you might want to check:
- Your Client Side GTM Tags: Is the Server Side Container URL inserted correctly? How’s the request looking? Is it sending data to your Server Endpoint?
- The Tagging Server Configuration: Is the tagging server up and running? Is the Tracking Domain set correctly?
- The Server Side GTM Configuration: Is the Tracking Domain set correctly there, too? And, obviously, are your Tags and Triggers set up correctly?
If nothing checks the box, I tend to look at the Tagging Server Logs next and possible console errors afterwards. Could be anything or nothing, cases like these make you feel like Sherlock Holmes and even though it might be tricky to solve the riddle sometimes, it’s so rewarding when you finally cracked the code and fixed the issue.
As soon as everyting’s running nice and smooth, you can finally hit the publish button 🙂
That means, we could resume this blog post now – but let me just include one last section where I’ll be answering all the questions I didn’t get to answer yet.
Frequently asked questions
This sounds super technical and complex. How long does it take to set everything up?
You will hate that answer. Because it depends. A standard GA4 Setup might take only a couple of hours (including the communication with the Server Admin), more if you’re doing it the first time, less if you’re a bit tech-savvy. A full-on-Server-Side-Tracking-Setup with all CAPI Tags and lots of custom events and parameters might take longer than that.
How costly is it?
At that point I’m contemplating if doing a FAQ section was really a good idea, because, again, it depends. This time, on the traffic quantity of your website, as you mostly per per hit. I think the better question is “is it worth the money” and the answer for that is yes, as long as you actively work with the data you’re collecting, for example running ad campaigns (CAPI) or making data-based decisions based on GA4 (or any other analytics tool) as your source of truth.
Are you really doing this for fun?
Yep!
And honestly, I think this is a very good closing statement for this 4.000 word-ish long blog post. I really hope it helped a bit and I also hope it didn’t scare you away from server side tracking just because it’s a bit more on the tech side than my blog posts normally are.
If you try to set up a Server Side GTM and are running into trouble, feel free to ping me anytime, you can find my contact information basically everywhere on this website.
See you around 🙂