Server-side tracking 101: Basics, tools, and a roadmap for data driven decision making

This article is part of our "How To: Growth" eBook, a comprehensive growth toolkit for founders and builders, which you can download here.

Introduction

Server-side tracking is no longer a nice-to-have in digital marketing. In the era of GDPR-compliance and aggressive Apple privacy updates, traditional client-side tracking is leaving huge reporting gaps, keeping marketers up at night with skewed attribution, and dropped conversions.

For less technical people, it can be hard to know where to start however, and some of the literature out there can get a little confusing (looking at you Google). 

Fear not, this guide will explain the basics of server-side tracking, exploring the messianic role it can play in today's privacy-focused environment. We’ll also examine the role that tools like Google’s Server-Side Tag Manager (sGTM) and Facebook's Conversions API Gateway (CAPI) can play in remedying your tracking nightmares, with some practical tips to get you started.

Understanding Server-Side Tracking

Server-Side vs Client-side

A useful way to understand server-side tracking on a conceptual level is by comparison to the more established approach; client-side tracking.

Server-side tracking and client-side tracking represent two different approaches to capturing data about user interactions on your website.

Client-side tracking relies on the user's browser to capture data. When a visitors loads your website, code is executed in the browser (a cookie), that records user interactions and sends this data to a 3rd party analytics server (ie. Google).

By contrast, server-side tracking skips the user's browser entirely, and sends data directly from your own server. When a user makes a request to the server, such as loading a webpage, the server logs that information. This can include data like IP address, time of request, and the specific page or resource requested. It can also include any processing that happens on the server, such as transactions or database changes, which form the triggers for server-side events.

Example

To illustrate, let’s compare how client and server-side tracking might handle a typical e-commerce user journey:

Client-side 

• When the user lands on the website, a cookie is executed in their browser. This sends a signal to the analytics server recording that a user has visited the site.
• As the user browses different products, each click or page view triggers the analytics code in their browser, and these interactions are also recorded and sent to the analytics server. 
• Same goes for when they add items to their cart - the data is sent directly from the user’s browser
• Finally, when the user completes the purchase, the confirmation or "Thank You" page signals a successful transaction, which is again recorded and sent to the analytics server.

Server-side 

• When the user lands on the website, the server notes the incoming request (including the user's IP, device information, etc.) and logs the visit.
• As the user browses different products, each new page request is tracked by the server. The server logs these interactions directly, without needing to execute any code in the user's browser. 
• When the user adds a product to their cart, the server again tracks this action as a change in the database (e.g., a new row in a 'cart items' table).
• Finally, when the user completes their purchase, the server handles the transaction process and sends a purchase event directly to the analytics server.

In both methods, the user's journey is tracked and a successful conversion is logged. However, they differ significantly in how the data is captured and where the tracking process takes place.

Why go Server-side?

So if client and server-side both produce the same outcome, why would you want to implement both? Well, client-side tracking requires 3rd party cookies to work (ie. Google analytics tags), and these are increasingly vulnerable to being blocke

Browser Privacy Settings: Browsers like Safari and Firefox have implemented stronger privacy protections that limit the use of third-party cookies by default. Safari's Intelligent Tracking Prevention (ITP) and Firefox's Enhanced Tracking Protection (ETP) can both block third-party cookies outright, and even limit the lifespan of first-party cookies. Google Chrome, the most widely used web browser, has also announced plans to phase out support for third-party cookies.

Server-side tracking offers an effective way to navigate the restrictions on third-party cookies, since it captures and processes data at the server level. 

Consider conversion tracking. With server-side tracking, instead of relying on third-party cookies to connect the ad click to the purchase, the user's actions are tracked directly from your server via their IP address, maintaining the link between ad click and conversion. This means more accurate reporting, and a better feedback loop for PPC campaigns to optimise against.

Similarly, for attribution modelling, server-side tracking can offer more accuracy and reliability. Suppose a user interacts with multiple marketing touchpoints – an email campaign, a social media ad, and finally an organic search – before making a purchase. Third-party cookies might lose some of this journey due to restrictions, but with server-side tracking can capture every request on your server, providing a more complete attribution model.

So there are no cookies in server-side tracking?

No, not exactly. Server-side tracking can and often does use cookies, but it doesn't rely on them in the same way that client-side tracking does.

In server-side tracking, cookies can be used to maintain a session state and to recognize repeat users. For instance, when a user logs into a website, a session cookie can be created and stored on the server. This cookie can be used to maintain the user's logged-in state as they navigate different pages on the site.

But the crucial part of server-side tracking, particularly from a privacy perspective, is that these are first-party cookies, sending data to your server, not 3rd party cookies, sending data to a Google server.

Server-side tracking can be implemented in ways that don't use cookies at all. For example, using methods like fingerprinting, IP address tracking, or user login data sent to your server. In some ways this is actually preferable. Tracking code can be quite heavy, and can increase loading times. Reducing the amount of JavaScript that needs to be loaded on a page can help improve page load times, and provide a better user experience.

What about GDPR? Does that apply?

Yes it does, but implementation is basically no different to client side tracking - briefly:

• Obtain informed consent from users before tracking their data; the consent should be explicit and freely given.
• Provide a clear and easily accessible privacy policy that outlines the data collection process, the purpose of collecting the data, how long the data is stored, and who it's being shared with.
• Users should have the option to opt-out of tracking at any point, and they should have the right to access their data and request its deletion.

The upshot is that if a user rejects analytics cookies, it may still be hard to track them across different devices and domains using server-side tracking, but it isn’t completely disabled in the same way as client-side tracking. 

Server-side tracking can still log session data in the absence of cookies such as pages visited, items added to cart, purchases made, etc without persisting any personally identifiable information (PII). This data will be tied to a session ID generated on the server, not a cookie, ensuring privacy while maintaining functionality.

In fact in some ways server-side tracking is preferable to client-side as it minimises the exposure of user data at the browser level. Since data is processed and stored on the server, it's less vulnerable to browser-based attacks, security vulnerabilities, or unauthorised access. Note that you must still ensure that the data you obtain and store on your server is compliant - marketing checkboxes, etc.

So long as you’re ticking all those boxes, and not installing cookies without permission, server-side tracking is very much a friend to privacy.

So what’s the catch?

Yup, there’s always a catch…

Despite the significant benefits server-side tracking offers, it's important to consider some of its limitations.

Loss of Detailed Client-side Data: One of the main downsides of server-side tracking is the loss of granular client-side data. Browser-based tracking can capture a rich set of behavioural data, such as mouse movements, scrolling behaviour, time spent on page (etc), alongside the device being used, and contextual information, like the page that referred them. Your server won’t know any of this, and while it's possible to send some of this data to the server, it’s far from efficient to do so.

Increased Server Costs: This is a big one. Server-side tracking requires more server resources than client-side tracking, and that costs money. Exactly how much will depend on a bunch of factors, but suffice to say this can be a particular concern for high-traffic websites, or businesses with tight budget constraints.

Implementation Complexity: Implementing server-side tracking can be more complex and time-consuming compared to client-side tracking. It often requires more technical expertise and extensive testing to ensure accurate data collection and reporting. Debugging and troubleshooting can also be more challenging than client-side, typically requiring access to server logs, and more sophisticated debugging tools than those offered by Google and co. out-the-box.

None of these are enough to outweigh the overwhelming usefulness of server-side tracking, just remember:

• It’s not a silver bullet. Some kind of client and server-side mix is generally preferable, to ensure accuracy, but also depth.
• You probably want to be selective about what you track server side. You’re essentially paying for more accurate data around some things, so make sure those things are actually useful to know (sometimes an estimate is fine).
• Bring your developers in early. The concept is relatively easy, but implementation can be complex, especially given every server has its nuances. Make sure they understand what you’re trying to achieve.

In Summary

Pros

• More Accurate & Reliable Data
• Enhanced Data Privacy & Control Over Data
• Improved Site Performance (on the assumption that client-side tracking needs are diminished)

Cons

• Loss of browser-specific data
• Increased server costs 
• Increased developer overhead

Essentially, it is very unlikely that you’ll want to kill client-side tracking entirely. You will probably want to implement server-side tracking selectively; where exactly will boil down to how useful more accurate data is vs the resources required to implement it (time x money).

Bearing that in mind, here are some of the most common applications that you may want to consider.

Server-Side Platforms

Server-Side Google Tag Manager (sGTM)

Google Tag Manager (GTM) will be familiar to most marketers. sGTM is a parallel service that moves GTM tags from the user’s browser to Google Cloud servers. When people talk about server-side tagging, this is usually what they mean. The triggers are generally referred to as server-side events, ie. a transaction or database change.

It’s a one-stop shop for server side tracking, providing an endpoint to send event data to. Standard use-case are:

• Web Analytics
• Analytics events
• Advertising pixels

Implementation:

• Set up a Google Cloud account and project. It is possible to use other servers, but much tricker.
• Within the Google Cloud project, you'll need to configure a Cloud Run service. This service will run the server-side GTM container.
• Create a new server-side container in GTM
• In the GTM server-side container, you'll need to configure the Tag Manager server by providing the Cloud Run service URL.
• Next, create data streams in the server-side container. Each data stream represents a source of incoming data.
• Just like in standard GTM, you’ll need to add tags, triggers, and variables. You can transfer some tags from your existing client-side container or create new ones.
• Once everything is set up and tested, publish your server-side GTM container.
• Update Client-side Setup: Finally, update your website or app to send data to your server-side container. This could involve updating the configuration of your client-side GTM container, or modifying the tracking code on your website.

If you’re new to server-side tracking or Google Cloud, we strongly recommend getting dev support in place for setup.

Meta Server-side Tracking

Meta’s ad optimisation needs conversion data to function properly. In response to the various privacy updates we’ve mentioned, Facebook released the Conversions API (CAPI). Its a server-side conversion tracking solution that dramatically improved results (it’s become a must-have for the Meta ads we run).

There are a couple of different options:

Facebook's Conversions API (CAPI)

The Conversions API is an interface that allows marketers to send web events from their servers directly to Facebook. It works alongside the Facebook Pixel (client-side) to improve the performance of advertising campaigns.

Setting up CAPI involves sending HTTP POST requests to Facebook's graph API endpoint, with events data structured according to Facebook's specified event format. Again, developer assistance is advised.

Various e-commerce platforms now offer built-in integrations with CAPI (ie. Shopify). If you’re not using one of them, the service can be implemented directly from your server, or via sGTM (above) using the Conversion API Tag. Additionally, apps can also use the Facebook SDK.

All of these require some technical expertise, but fear not. If you’re struggling, there is a lightweight version.

Facebook's Conversions API Gateway (CAPI Gateway)

Facebook's CAPI Gateway is a solution for integrating CAPI without the need for engineering support. As above, it allows businesses to send events using the Meta Pixel and Conversions API, and is particularly beneficial for businesses that only want to implement server-side tracking for Facebook.

Setup involves configuring the CAPI Gateway settings in Business Manager, and then setting up your client-side tag manager to send events to the gateway. This involves less backend work than implementing CAPI directly, however you are stuck with preset events. If you want more flexibility and control (around say, detailed custom events) full CAPI is a better solution.

Other Solutions: Matomo, Heap, and Amplitude

Tech giants aside, many smaller platforms have started to integrate server-side tracking into their products, generally via APIs that let you send events directly from your server to theirs. Here are a few examples:

Matomo

Matomo, formerly known as Piwik, is an open-source web analytics platform that provides both client and server-side tracking capabilities. 

To set up server-side tracking with Matomo, you need to install Matomo on your server and integrate it into your website. You can do this using various methods, including direct server-to-server HTTP API requests, importing server logs, and using SDKs for apps.

You can set up Matomo via sGTM by using its tracking API; requests are sent from sGTM to your Matomo server for each event you want to track. Bear in mind that this method will require some custom setup and configuration in both sGTM and Matomo.

Heap

Heap is a product analytics platform that automatically captures every web, mobile, and cloud interaction. They traditionally focus on client-side tracking. For server-side, they offer APIs that allow you to send data from your server to Heap, although you need to write custom code to collect and send the data. Again this can be done directly, or via sGTM.

Amplitude

Amplitude is a product analytics tool that also provides both client-side and server-side tracking. Server-side tracking can be implemented using Amplitude's HTTP API. Again, this requires writing custom code to collect and send event data from your servers.

Amplitude provides a straightforward HTTP API for server-side tracking that you can use with sGTM. Each event you want to track would be a separate API call from sGTM to Amplitude.

Conclusion

Hopefully you now understand the pros and cons of server-side tracking, and some of the tools that you can use to implement it. As above, most decisions will boil down to utility vs cost - so a pretty standard problem for product managers and business analysts.

As a starting point, we would recommend mapping out areas where accuracy is really important to your business’s success. These will typically be conversion tracking for any PPC you run (lost conversions are expensive), accurately recording transactions and/ or any other key aspects of user behaviour. These are likely to be a good starting point.

‍