What Are Limitations to Server-Side Tracking

10 minutes

If server-side tracking is so great why doesn’t every brand use it for all tracking? Learn more about the limitations […]

Brad Redding

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

If server-side tracking is so great why doesn’t every brand use it for all tracking? Learn more about the limitations to server-side tracking in this lesson.

Server-Side Tracking Lessons:

General Availability

The main reason that a brand does not move all tracking server-side is because:

  1. Marketing channels aren’t ready to let go of client-side tracking due to the fingerprinting benefits on client-side tracking. This fingerprinting is typically used for attribution.
  2. Marketing channels simply aren’t technically ready to receive all of this data server-side yet. Many don’t have a fully functioning Conversion API like Facebook, Snapchat, TikTok, etc.

Yet is the key word here.

Eventually every marketing channel will have a server-side API to accept data — like Facebook’s Conversion API.

You can listen to an interview with Elevar’s VP of Engineering in this related blogpost for full details on this client-side vs server-side tracking competition.

Here are a few of the special callouts from this.

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.

The primary reasons channels are not moving quickly to adapt are:

  1. Affordability. Embracing API integration necessitates the development of additional systems. Needless to say, this is harder and costs money and resources.
  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
  3. Browser request headers. A header is simply a piece of information that comes with a request. 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.
  4. Ease of Processing Data. 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 is a big technical feat.

Data Availability

If you’ve read each lesson in this server-side course you’ve likely picked up on this fact:

Client-side tracking via onsite Javascript/pixels can pick up data from the user’s browser without the user — or you, the brand — knowing exactly what data is being fetched and sent back to the marketing channel.

You may have even received emails from affiliate vendors or other marketing channels that you need to update your tracking integration to be “ITP Compliant” or so you are collecting it in “1st party context to get around blockers”.

They don’t really outline what exactly they are collecting other than providing instructions like:

  • Copy/paste this new script here
  • Ensure this new cookie is server-set

And this data is used to help the channel attribute activity to conversions ultimately so you can view reporting inside their platform.

So taking a cue from the previous section on why everything doesn’t so server-side, it’s the reality that channels may have to rebuild how they attribute performance with a more limited dataset.

There are industry movements forcing change though:

  • Apple’s iOS privacy rollouts like the “hide my email” or IP address obfuscation. So even if the channel wanted to grab the IP address from client-side tracking, it’s no longer accurate.
  • Browsers restricting data accessibility in cookies and localstorage

Here’s a hypothetical example:

Commission Junction uses:

  • IP address (which can help in geo-targeting)
  • Browser type
  • Browser version
  • Operating system
  • Operating system version
  • Screen resolution
  • Cookie information
  • Click ID query parameters

All to help CJ match an affiliate click to a conversion. They may do something like:

  1. If Click ID exists in conversion hit then match back to click
  2. Elseif Click ID doesn’t exist then fallback to combination IP address + browser/device/cookie information to try and recreate the conversion matchback to the ad click

But if in a server-side integration CJ is only receiving:

  • IP address
  • Click ID query parameters

Then their fallback will be limited.

Now — depending on how you are integrating server-side tracking will dictate what data you have access to.

For example if you are utilizing Elevar, we capture the data outlined above and can map to destinations if their server-side API can accept this.


Consent and cookie compliance has skyrocketed the past several years as brands scramble to be GDPR and/or CCPA compliant (among others).

When sending data server-side to a destination like Google Ads, and you are legally required to remain compliant (ex. Google Ads EU consent compliance requirement), then ensuring your server-side integrations are compliant is mandatory as well.

So if you are utilizing Elevar’s server-side tracking, you will need to ensure you configure your consent rules inside each destination:

consent compliance with shopify