Is server-side tracking the solution to privacy and cookie woes

Is server-side tracking the solution to privacy and cookie woes?

There are a lot of articles that misrepresent the process of server-side tracking or ignore key facts. In this article, we cover the most important aspects of server-side tracking and explain how you can use it for your business.

What does server-side tracking actually mean?

Server-side tracking requires that you change the way you track user behaviour for marketing purposes. The typical procedure for tracking users is to set up tracking for each data source. One for Facebook, Google, one for Adobe Analytics and so on. A website could have up to 100 tracking scripts running at once, all of which might set their own cookies in either 1st-party or third-party contexts.

Server-side tracking means that you should create a single stream for behavioural events. These can then be sent to the appropriate data collection endpoints by the server, not the browser (one-to-many). This will reduce the browser's load and shift the responsibility to the server. It is far more efficient to create multiple sequential requests, without affecting the user’s experience.

Cookies are not necessary?

Yes and no. It all comes down to the purpose of the data that is collected. If you want to track the behavior of users across devices and sessions you need an identity matching system. Otherwise you won't be able understanding behaviours that occur over long periods of time, or cross-browser and device. Thus, you need to transmit one or more IDs when user behaviour data is sent to the endpoint.

These IDs could include:

IP Address
User Agent
Cookie ID
Profile ID
Customer ID
Email Address
Phone Number
Address

Obviously, the closer the data is to an individual, the more insight there is about their behavior and whether they can be linked across devices and browsers.

Cookie ID can still be used for server-side tracking. It is important to set cookies for server-side track purposes in a different way than when a cookie is used when there is no server-side tracking. This would be done by creating an anonymous user id on the server every time a visitor visits the site. This cookie is saved in the browser's first-party cookie, using the "Set-Cookie” header in the initial page response. This first-party cookie (HTTP Cookie), is set by the site's servers and not JavaScript executed in browser (JS Cookie). It is therefore not subject to the expiry limitations imposed by Apple's ITP or other similar technologies. Note: Apple's ITP policy applies to the use of CNAMEs (domain cloaking), to set the HTTP cookie.

This anonymous user identifier is included in the request to the server-side Tag Management System (TMS) or tracking server. It can be used as the third party user ID to any data collection tool that accepts it.

We can now use TMS server-side?

Yes you can. Google's TMS version can now be deployed server side. Tealium and other enterprise solutions have been offering server-side functionality for many years. Adobe launched two versions of Adobe Launch and provide server-side solutions.

Server-side tag management systems function in a similar manner to their client-side counterparts. However, the real benefit comes when you update your user tracking logic to create a one-to-many relationship of all events and data about the user.

Will this help to resolve privacy issues such as GDPR or CCPA?

No, it won't. It is important to have a solid way to notify your customers and get their permission to use their data. Privacy is often mistakenly equated with cookies. Cookies are just a way to send data: privacy regulations focus on the type and purpose of the data collected.

You should also be aware that server-side tracking is not the best option for all data collection methods. Server-side tracking is not currently available for all data collection systems. With some minor adjustments, most of them will work. However, it is possible to change over today by using a hybrid approach in which the majority of data collection tools run from server-side managed data while others are still running from data sent via the browser. This situation requires that you ensure permissions are properly handled in case a user opts in to or out of different types data collection. Let's take, for example, the opt-out to marketing tracking. You need to make sure this opt-out applies to all tracking that you have currently running on the browser and server-side. If they change their mind, you will need to change the flag in both places.

Is server-side tracking going to make data collection more precise?

This really depends on which data collection tools are used and whether permission has been granted by the user to track their actions in a more precise manner. The ability to use data that is closer to the individual, such as Customer IDs, phone numbers or email addresses, will improve accuracy. These IDs are not likely to change between sessions, browsers, and devices. Cookies will. These data points will however affect your ability to use them.

What happens if the business model you have doesn't require that the user has an account? It could be that you are a news/broadcast website and have an advertising-based model. This means that the majority of your data won't include any more detail than a cookie ID. You might rely on customers signing in to their accounts to create/buy services/products. However, you have followed the GDPR rules and customers have requested not to be tracked for marketing purposes. These richer data points will only be available if your business model is well-developed and your ability to persuade customers to share their data.

Tools - there are two sides to this. Data collection tools, and then their data processing capabilities. Either you could decide that customers need to set an ID, or you could pass that responsibility to the end points to which you are sending the data. This means that you can deploy your own ID stitching capabilities using either a proprietary tool in-house or through a Customer Data Platform like Tealium Audience Stream and Adobe's Real Time CDP. These tools offer a rich set of capabilities to manage customer profiles across all devices, browsers, and online as well as offline platforms. These tools can be integrated with other data collection tools in order to provide the most reliable tracking methods. However, they also adhere to the data privacy policies set forth by these tools.

Another option is to transfer responsibility for Customer ID unification from Google, Facebook, and other companies. But it is not possible to guarantee that end data consumers will be able to combine this data in the way you expect.

Should you wait until everything is done server-side before making this switch?

It is ultimately your decision on the balance of effort and reward. Although a hybrid solution may still be required in most cases, there are considerable benefits to switching to a server side approach. A server-side migration plan often does not include a detailed plan that explains what, why, and how. We can add a lot more to your server-side migration plan beyond the actual delivery and deployment stage.

Reach out to us to discuss this topic further. We are more than happy to provide a preliminary assessment of your options, before we consider a paid engagement.

The essential guide to server-side tracking

What is server-side tracking?

Source: dpmg

Photo by panumas nikhomkhai from Pexels

ANALYTICS

GDPR Compliant Data Collection

Use GDPR compliant tools to collect user data. Stop worrying about legal implications of Google analytics and other similar tools.

Scroll to top