We get asked a lot about server-side tracking here and we also read quite a few articles that either misrepresent how it works or gloss over some of the key facts. As such we wanted to provide some better information in the form of a Q&A article.
What exactly does server-side tracking mean?
It actually requires you to change your entire approach to tracking user behaviour and conversions for marketing purposes. By tracking users in the browser the typical process is to implement this tracking for each individual data end source, one for Facebook, one for Google, one for Adobe Analytics etc etc (many > many). As a result, a single website might have as many as 100 different tracking scripts running at any point in time all setting their own cookies either in 1st party or 3rd party contexts.
To move to server-side tracking would mean that you should really be creating a single stream of behavioural events that can then be forwarded on to the specific data collection end points by the server and not the browser (one > many). Done correctly, this massively reduces the load on the browser and pushes the responsibility to the server that really is much better designed to generate multiple sequential requests without affecting the user’s experience.
Does that negate the need for cookies then?
Yes and no. The potential need for cookies comes down to what the data is being used for at the other end – by the data collection end points. If we need to try and link behavioural events together across sessions or devices for example then we will need an identity matching system to do this. When servers collect information they typically string information together in their logs by using session level IDs – this is no good for understanding cross-browser, device or even behaviour that happens over a long period of time. As a result, when the user behaviour data is passed to the end point we will also need to send one or multiple IDs to allow this stitch to occur, these IDs could be in the form of:
- IP Address
- User Agent
- Cookie ID
- Profile ID
- Customer ID
- Email Address
- Phone Number
- Address
The more closely aligned the above data is to an actual individual then typically the richer the insight is about their behaviour and whether events across browsers and devices can be linked.
Cookie ID is therefore still an ID that might be used in the context of server-side tracking. However, when setting cookies in context of use for server-side tracking it should be done differently to how a cookie is set when not using server-side tracking. The way this would work is by the server creating an anonymised user id the first time that a visitor lands on the site. This is stored as a first-party cookie in the user’s browser, utilising the “Set-Cookie” header in the initial page response from the server. Because this first-party cookie (HTTP Cookie) is actually set by the site’s server and not by JavaScript executed in the browser (JS Cookie), it is not subject to the same expiry limits imposed under Apple’s ITP and other similar technologies*.
When the single site request is made to the server-side Tag Management System (TMS) or tracking server, it includes this anonymous user identifier. We can then pass it as the third party user id to any data collection tools that will accept it.
*Note that using CNAMEs (domain cloaking) to set the HTTP cookie IS subject to Apple’s ITP policy.
Hold up – we can use a TMS server-side now?
Yes you can. Google’s version of their TMS can now be deployed server-side. Other enterprise solutions such as Tealium have had server-side functionality for several years. Adobe has also recently updated their TMS proposition by creating two versions of Adobe Launch. Adobe Platform Launch – Tags is now the client-side version with Adobe Platform Launch – Event Forwarding picking up the server-side capability within their Adobe Experience Platform suite.
The tag management server-side systems work in a very similar way to their client-side alternatives but the benefit really comes when updating your user tracking logic to ensure a one to many relationship of all the events and data you’re collecting about the user.
Does this help resolve challenges around adhering to privacy policies such as GDPR and CCPA?
No. The only thing that is changing with server-side tracking is the mechanic for how user data is collected and then shared with data collection tools that might be classified as ‘essential’ or ‘marketing’. You will still need to ensure you have a robust way of splitting out all your data collection requirements to your customers and either notifying them or getting their express permission to use this data. There is a big misconception that privacy = cookies but this is completely false. Cookies are simply vehicles for sending data. The type of data being collected and for what purpose is really what these privacy regulations are focused on.
It should be noted as well that if you’re considering moving to a server-side tracking method you actually need to be more careful about how your data collection and privacy is being managed. The reality is that server-side tracking will NOT currently work for all data collection systems. Most of them will work one way or another with some small adjustments BUT to switch over today may mean utilising a hybrid approach whereby the bulk of data collection tools function from server-side managed data with some still running from data sent from the browser. In this situation, you need to ensure that permissions are handled correctly in the case that a user specifically opts in or out to different types of data collection. For example, let’s say that they opt-out of marketing tracking – you need to ensure this opt-out works for any tracking you have running from the browser and the server-side now… if they change their mind you will then need to switch the flag in two places.
Will server-side tracking make my data collection more accurate?
Possibly. The answer to this really comes down to which data collection tools you’re working with and whether the user has given you permission to use their data in a way that allows your tracking to be more accurate. Accuracy will increase based on being able to use data that is more closely aligned to the individual such as a Customer ID, phone number or email address etc. These IDs typically do not change between sessions, browsers and devices whereas cookies will. Your ability to use these data points however will rely on:
- Availability – What if your business model does not rely on the user having an account? You might be a news/broadcast site and as such have an advertising-based business model. In this instance, the vast majority of your data will not come with anything more detailed than a cookie ID. Conversely, maybe you do rely on customers logging into their account to create/buy products/services BUT you’ve played by the rules defined by GDPR and your customers have asked not to be tracking for marketing purposes. Availability of these richer data points will therefore rely on a combination of your business model and ability to convince your customers to share their data with you. Speaking from nearly 20 years of experience I can assure you that your customers will absolutely not care about your ROAS or CPA rates and be willing to let you share their email address so that you can build a better looking insights dashboard.
- Tools – There are two sides to this. Data collection tools and then their data processing abilities. You could either take the approach that during data collection you (the brand) should be responsible for defining the customer ID to its most unique point or by passing that responsibility on to each of the end points you’re sending the data to. By this I mean deploying your own ID stitching capabilities either done through a proprietary in-house tool or via a Customer Data Platform such as Tealium Audience Stream or Adobe’s Real-Time CDP. These tools have very rich capabilities for managing customer profiles in real-time unifying data across browsers, devices and even online and offline platforms. They can then integrate with other data collection tools to ensure the most reliable tracking methods possible are used while also adhering to data privacy policies defined in and controlled by these tools.
The other consideration is to pass on responsibility of Customer ID unification to the likes of Google, Facebook and others. There is of course no guarantee that these end data consumers have the capability to stitch this data the way you want/expect plus I personally think it would massively undermine any data collection privacy and security policies you might put in place. Sharing this type of data for the purpose of providing highly targeted advertising to an existing customer (with their permission) is one thing but to send this data by default for the purpose of conversion tracking seems very sloppy.
This is getting quite complex – should I wait until everything can be done server-side before making the switch?
Ultimately that is your decision to make on balance of effort vs reward but if it were me I would be planning it now and looking to deploy a hybrid solution now such that I was much better prepared for the future of digital data measurement.
We have been working with server-side tracking solutions here at DMPG since 2017. In the early days, there were very limited benefits but this has changed a lot in the last 4 years. While a hybrid solution is still required in the vast majority of cases there are some huge gains to be had by starting to switch to a server-side approach. However, one thing that is often absent from a server-side migration plan is exactly that… a detailed plan of what will move, why and how. This is where we can provide a lot of additional value beyond the actual deployment and delivery stage. We do not claim to be ‘server-side tracking experts’ – If anyone does claim to be this then you know for sure it’s about as reliable a claim as someone guaranteeing you ‘1st placing on google search paging result’ – but, we work with a lot of brands who have been looking to move more and more of their tracking server-side for several years and in the process built up a lot of knowledge and experience about how to do this in the most efficient and effective way based on the technology options available.
Reach out to us to discuss this topic further and we would be more than happy to provide an initial assessment of your options before we even think about discussing a potential paid for engagement.