Analytics

Why All Javascript Client-Side Tracking Can’t Move to Server-Side

Learn why channels still prefer their client side javascript to run on your website which limits your ability to remove and improve site speed.

Why All Javascript Client-Side Tracking Can’t Move to Server-Side

Brad Redding

Brad Redding is the Founder & CEO of Elevar. Specializing in analytics, tracking, GTM, and conversion optimization.

In 2020, Google released their server-side Google Tag Manager solution. This naturally led to the hope that brands could now move all javascript tracking from the browser (which slows down your website) to a server-side container to help improve site speed.

Unfortunately, this wasn’t the case and, in fact, hasn’t fully happened to date.

Since the release in 2020, here at Elevar we’ve been getting this exact question time and time again:

“Why can’t all tracking move from hardcoded scripts in our theme or a GTM web container, to a server-side container?”

This article will share the reasons why which boils down to:

  1. Channels aren’t ready to “let go” of client-side tracking due to the fingerprinting benefits for attribution
  2. Channels simply aren’t ready to receive all of this data server-side

You can also listen to our VP of Engineering and Founder discuss this exact topic on our podcast:

Client-Side Tracking Overview

Client-side tracking involves the direct sending of data to a server from the user’s browser.

To clearly define client-side tracking, we go back in time to the 90’s on the internet aka web 1.0.

Back in the 90’s, when the server received an image request by a user (simply by a browser loading a website with images), the server received a ton of personal information sent “over the line”.

The information sent includes the browser type requesting the image, the IP address of the user, the query parameters that were included in the request-such as UTMs, and a plethora of cookie information.

This caused a lot of exposure for the user loading the webpage. The act of simply loading an  image gave so many people access to the user’s information or identity.

Most client-side tracking is handled similarly.

There is online JavaScript (pixel hits), loaded through your theme or GTM, that code for specific functions.

These pixels aka tags (JavaScript code) built into your site enable data transfer. During the data transfer, you do not see an image or anything similar. The code executes on your site, sends data to the endpoint (think Facebook or Google) and the endpoint returns a small invisible image.

Thus, with client-side tracking comes a lot of JavaScript on the site to generate these pixels that transfer data, but are invisible and unreadable to the user.

Fundamentally, it’s like sending data to Facebook (or other channels) and having the request headers, the browser, the IP address, and cookies automatically added to this request to Facebook. This total package is the unique fingerprint that the marketing channel  uses to attribute activity back to a particular user.

“So, can we trick our IP address with an image to protect our data from being shared?”

In short, no, we can’t spoof our IP address with an image request. You can’t trick it.

Server-Side Tracking Overview

Server-side tracking, just as it sounds, involves a server-to-server pixel hit as opposed to a browser-to-server hit.

Basically, in server-side tracking, also known as cloud delivery, a tag sends data to a server (think user adds an item to cart), and that server then passes the data to the destination server (think Facebook Conversion API).

server-side-tracking-overview

A major difference between client-side tracking and server-side tracking, aside from the use of JavaScript, is that with server-side tracking you get to define what data is being sent.

Client-side tracking simply grabs all browser information of the user.

Server-side tracking allows you to define what information you want to send to the marketing channel, including the header and other data used to fingerprint users (ex. IP address, user-agent, browser, cookies, etc)..

Client side tracking Server side tracking
JavaScript runs on the site JavaScript not needed
Implicit data Explicit data

Server-Side Tracking Limitations

So, why can’t all tracking move from client-side to server-side to help improve site speed, manage privacy, etc?

As mentioned in the opening, there are two reasons:

  1. The lack of adoption of proper server-side APIs to handle the amount of data
  2. Channels aren’t ready to “let go” of client-side tracking due to the fingerprinting benefits for attribution

Channels have been using the client-side image request in their JavaScript libraries for years.

But, the industry shift to proper server–to–server API calls is extremely complex.

Adapting to the server-side API tracking mechanism distorts their entire API ecosystem because they not only have to manage their client-side pixels, but also have to manage an extremely high volume of data for event hits that get sent via API.

Many channels simply can’t handle the type of integration needed to manage this.

So, they retain the already familiar system of implementation – the client-side pixel via onsite Javascript.

But why aren’t all marketing channels sprinting to release their own server-side “Conversion APIs” and roll out to all customers?

1. Affordability

Embracing API integration necessitates the development of additional systems. Needless to say, this is harder and costs money and resources.

It is more cost effective for many channels to keep the onsite script integration. Data transmission for client-side tracking usually costs less than server-side tracking, which requires third-party resources in the cloud rather than the target user’s device only.

2. Better data transmission

Many of the original client-side integrations (pixel bits) send a lot of data that even the API won’t document.

Hence, you’ll typically see a lot more data going across the line with pixels and JavaScript sending than you would with server-to-server integrations.

3. Browser Request Headers

A header is simply a piece of information that comes with a request.

A request is a simple page load event, a page view, or an image request. So, anytime the browser requests an asset, there are headers sent and the server can pick apart those headers.

Headers tell the server what the IP address of the request is and what browser is used. They carry the implicit data that comes with pixels and are absent in a typical conversion API integration except when explicitly sent.

Thus , client-side tracking allows direct access to user-specific data like URL parameters, IP addresses, browser & device data, and cookies.

These pieces of information can then be easily collected and used to trigger other actions:

  • Cookies are often used for ad targeting
  • Location data can be used to give personalized content, while URL parameters may be used to gauge customer engagement.

4. Implementation Friction for the Brand

Using server-to-server tracking is typically not worth it for many smaller merchants considering the cost and management complexities that go into building and managing a server-side integration.

So this can create lengthy onboarding times for getting the merchant up and running on the channel.

Client-side tracking, on the other hand, is  quite easy to install and manage, whereas server-to-server tracking is not. Many vendors supply cods that can be simply copied and pasted into Google Tag Manager web container (or the theme) to complete the implementation.

5. Ease of processing.

Different channels (TikTok, Facebook, etc.) already have data pipelines processing these pixel hits.

This processing is not done in real-time. Rather, everything is being post-processed.

So, with a trillion hits coming through, there is no cause for alarm if some are not processed immediately. They can be processed a while later, and everything still functions effectively.

Moving to server-to-server tracking means that the channel’s conversion API now has to give a response to the server that sent the request (e.g. add to cart, purchase) that they’ve received the event.

This has to be done in real-time and a tremendous amount of infrastructure is required to do so. This real-time processing and validation are typically never done for any of the onsite JavaScript that would send pixel hits.

What Are Site Speed Benefits of Server-Side Tracking?

Many pixel implementations have a lot of the same boilerplate Javascript code.

So when you have multiple channels with Javascript tracking implemented, this results in redundancy on your webpage which in turn can slow your website down.

Someone viewing your page might see five different versions of the same boilerplate code running, which is not good for site speed, since it’s the same code running repeatedly.

So when you’re able to move tracking server-side then you can reduce this code bloat from running on your website.

The Current Landscape: What’s Plan for Channels Going Forward?

Ultimately, every channel will need to have its own conversion API to accept event data, conversions, etc.

Most of the common apps (Facebook, Snapchat, and TikTok) have always had an ad management API. This is an API where apps can talk to various channels and tell them to create, optimize, or delete their campaigns.

However, these ad management APIs typically come with rigorous authorization flows and rate limits.

Compare this to the Pixel API’s which are more like a “free for all” – you can send tons of data without worry.

Some channels rolled out their conversion API directly tied to their ad management API. However, the throughput for most brands of event and conversion data is likely to hit the rate limit which is not what the channel likely wants.

Because when the rate limit is hit then the channel stops accepting the data requests. For example this means that add to carts, purchase events, etc may be missed.

TikTok had a similar setup when they initially launched their Events API, but they’ve since changed by separating out into a separate API. Similar to Facebook’s separate pixel and conversion API.

This is the path we are seeing from the larger marketing channels – they’re adopting a hybrid approach to transition to a fully functioning Conversion API.

The other common adaptation we see is deduplication. This means the channel accepts the same data from the client-side pixel and the server-side API.

Because the pixel is impacted by various browser issues and constraints, deduplication helps to get the brand from 80% tracking to 100% tracking through a combination of their pixel and server side events.

Summary

Server-side tracking is critical and, though not necessarily new, has grown in importance over the last couple of years.

This is because channels are experiencing a degradation in the amount of data they are getting from their client-side pixel integrations.

i.e. they only receive 80% of events from their “pixel” running on the website.

This is as a result of privacy tracking restrictions, growth in ad blockers, browsers blocking by default, etc.

But many channels aren’t quite ready to move tracking completely server-side.

So to answer our ultimate question:

Why can’t you move all client-side tracking into server-side tracking today to potentially improve your site speed and ensure 100% of conversions are tracked?

The simple answer is that:

  1. All channels are not ready to accept the volume of data yet because they don’t have the infrastructure to manage it
  2. There is still some magical fingerprinting that channels are doing through their client-side tracker, which they can’t do through server-side tracking. So they prefer client and server-side tracking to run in parallel.

Have any questions? Let us know in the comments below!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may also like