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.
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.
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 server-side tracking, in that case, was no cookie-free tracking. So we still need the consent.
When you are using Google Analytics the Measurement protocol is the way you can send the data to Google Analytics:
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:
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.
There are some open-source wrappers. I have not used any in production yet, but they look solid enough to give them a test.
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
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.
Every week I sent out posts, products, tweets and projects I came across. Give it a try and just unsubscribe if they are boring. Sign up to get my links