The dawn of server-side tracking

Client-side tracking is getting more difficult, with browsers like Safari, Firefox and Brave and with a rising use of ad-blockers. Server-side tracking is not difficult to add and gives you an additional layer of data when the client one is missing.

The dawn of server-side tracking

During the WWDC 2020 Keynote presentation at ~50m Apple moved to a topic they expressed a lot more in the last 1-2 years: Privacy. As a clear positioning compared to Google’s Android.

At 58:13 Katie Skinner showed a new feature.

youtube:https://www.youtube.com/embed/GEZhD3J89ZE?start=3480

WWDC 2020 Keynote – App privacy

It is a similar dialogue we know when apps are using your location. But this time iOS asked you:

App XY would like permission to track you across apps and websites owned by other companies.
Your data will be used to deliver personalized ads to you.

—> Allow Tracking
—> Ask App not to track

It says nothing about blocking app analytics. But this message could mean that attribution data can be blocked. We don’t know.

But the signs are on the wall – client side tracking is becoming more difficult on the website and as well in apps.

Let’s have a look at server-side tracking

It’s not something new. Analytics started with access logs which truly is server-side tracking. But for the last 15 years, the client with pixels and JS scripts ruled the analytics world.

I worked with server-side tracking in one project in the last two years. We wanted to implement a pretty complex tracking but the client had 4 platforms and a lack of frontend resources. But they had a well-defined REST API and backend resources.

So we decided to implement the tracking where everything happened as a layer on top of the REST API. Every important event needed to request some data from the backend and we simply logged it away to Analytics.

The cool stuff

  • We got more context data than in the frontend because not all data sent over the API to the frontend
  • We added the major tracking events into testing that was set up for the API already
  • We got API usage analytics data for free
  • Every adblocker was our friend
  • No page speed issues

The things we had to build

  • We still stored a unique identifier for the user in the browser. Some events were for anonymous users. When they have logged in we used the userid that was part of the API requests
  • The initial call from frontend to backend we provided the frontend context we cared about (referral, utms, OS, browser, version, language, shortened IP)

The server-side tracking, in that case, was no cookie-free tracking. So we still need the consent.

What about the tracking code?

Google Analytics

When you are using Google Analytics the Measurement protocol is the way you can send the data to Google Analytics:

Measurement Protocol

The MP is basically the same API call that the client JS is sending the data to. The parameters are designed for keeping requests from the client as small as possible, so they are not really intuitive, but they are well documented here:

Measurement Protocol Parameters

The most important tool you need is the hit builder. Here you can try your created URLs before deploying them for testing. Trust me, I did my first implementation without this tool and it takes ages because the Measurement Protocol endpoint doesn’t give you an error code when your URL is malformed. It takes everything and forgets about the wrong calls.

Measurement Protocol Hit Builder

There are some open-source wrappers. I have not used any in production yet, but they look solid enough to give them a test.

Python: google-measurement-protocol,google-analytics-measurement-protocol

Ruby: Staccato, MadeToMeasure

NodeJS: universal-analytics

Segment, Snowplow, Mixpanel, Amplitude

When you are using other tools like Segment, Snowplow, Mixpanel or Amplitude it’s a lot easier because they offer SDKs for multiple platforms:

Segment: Clojure, Go, Java, Node.js, PHP, Python, Ruby, .NET – Segment Server Sources

Snowplow: ActionScript (omg), Arduino, CPP, Go, Java, Node, Lua, .NET, PHP, Python, Ruby, Scala, Unity – Snowplow Tracker

Mixpanel: Python, Java, PHP, Ruby, NodeJS – Mixpanel Server-Side SDKs

Amplitude: Node, Java, Unity – Amplitude SDKs

When does server-side tracking make sense today

If you have a well-defined API (for single-page apps) or a well defined ORM layer (Rails or Django), you can simply add the first version of API based events.

I would start with a parallel implementation. Add some server-side events next to the client-side ones. And distinguish them with a proper namespace.

Deploy, test, and refine. Even aside from client-side tracking, it can give you some nice insights. For example how much less data is tracked on the client for similar events compared with the server (gives you a good idea about ad blockers).

Extend and learn. The best thing is, you are ready when client-based tracking becomes even more difficult.

Related Posts