Server-side Tracking For Business Dummies

Last Friday I had a deep and fascinating discussion with 2 Product Managers regarding data collection and analytics in a world of privacy. The issue arises is that privacy concerns, pixel blockers are choking user data analytics, without which, great products cannot be built. People are talking about a solution; some are building alternatives. What shall product people do exactly?

In a world of agility, it’s safer to say “we are just trying” than “do this you’ll succeed”. In that sense, let me break the big issue down and start from here: Pixel based tracking is a goner, what are the alternatives?

Here’s one, server-side tracking. I first heard about SST was 2016 while evaluating Header Bidding opportunities for our Ad Server, and SST actually dated back long before that. But it seems that this topic has gradually regained trend, so it might be the time to brush up a bit.

//This post isn’t about tech setup, so if you don’t need the fundamentals, just skip to the last part where I have a little case study for you 😃

Server-side tracking means transmitting data firstly to a server, then letting the server pass that data on to its destinations. Here the data entails how your website or app is being used by users (view, login, time, referrer, etc). And the destinations represent what this data is for (personalisation, marketing, etc). Does this mean there’s a “non-server-side tracking”? Yes, client-side tracking, when data goes from client straight to the destinations. On of the most common ways to do it is through tags, like how GTM (Google Tag Manager) does it. GTM actually also support server-side tagging now.

If allow me to draw it:

//Note to prevent server overload.

//Also note the differences — Javascript tags: mostly used by websites. SDKs: mostly used by mobile apps. 3rd party cookies: are created locally to delivery cross sites, can be deleted and blocked by users.

On the business side, apart from asking what problem do I solve, it’s also necessary to ask — what value does this bring and how much does it cost? Is there a better way to do it?

The devs resource and the additional infrastructure obviously cost money. In the industry, many also adopt a hybrid approach. What is the best for You? Perhaps there’s no need to discuss the well-said pros and cons of client-side, server-side or hybrid. Instead, I’d like to focus on the reasoning approach. As a rule of thumb, product managers need to have good decision making skills. A process that could involve estimations, metrics, tradeoffs, many more you name it. Maybe that’s why I’m a fan of models. They remove the complexity. At Uni, I could spend hours just on the Business Model Canvas. Back to this case, I find the diagram made by Segment extremely helpful. It walks you through the decision making between server- and client-side tracking in a business relevant way. Since speaking about decision-making, there’s also a nice model that guide you to question the desirability, feasibility, and viability of what you’re building.

On the strategy side, very often I focus too much on seeking a solution, I forgot my initial goals. So perhaps it’s worth it to ask — what brought you here?

If your initial concern was actually less technical but more along the line of: my users just don’t want me to track, what shall I do?

The first thing and what guarantees for success is to put yourself off the pressure — You’re not evil by tracking users. Focus on your goal of developing a product that solves user’s problems. You want to create value to them so do it right, understand how they use your product. This brings you back to the product vision and USPs that users rely on. Then ask yourself, do they absolutely reject my tracking request?

Case study

I want to use an extreme case to prove this point. If you are a female, which I hope is the case :) would you give your period and usage data to an app? The data include how do you use the app, when is your period, how many days, accompanying symptoms, and your mood, enough for the app to study you. It sounds terrifying, right? At least to me, who is an actual user of this app. Why do I use it then? Because the product solves a huge cycle management problem. Thus for me, it was to my benefit to offer my data to the product. In addition, they communicate excellently their value proposition. And messages like “female-led team”, “refusal to sell your data”, “driven by ethics” are extremely visible. They demonstrate compassion and responsibilities, which is a proven approach to resonate with users and build trust.

Another lil example — apps that help book doctor appointments, such as Doctolib. Is it more daunting to give appointment data or to call the doctor’s office? It’s a tradeoff for the users.

So, 2 points on the strategy level, can you understand the users? Can you do something differently to guide their perspectives?