When to track client vs server

What is tracking on client and server 

So you can understand the trade-offs and nuances of tracking on client vs server we’ve outlined some of their technical capabilities. 

For the web, a client is a mobile device or web browser or anything that is used to browse the internet. The server on the other hand is the computer that brings back web pages to be rendered in your browser or mobile app. 

A : when a user visits a website, there is a request to the web server to retrieve the files for rendering that page in a browser. The link may not be related to the client or server side tracking but it shows that you can replicate a client side call on a server when you send necessary information from the client to the server and after, sending a call on the server. 

B : this sends tracking data from a client’s browser to the monetization service. As the call is made from their browser, it gives you access to a lot of user information such as cookies, User agent, UTM parameters and IP addresses.

C : for tracking on a server, tracking data from your web server is sent to the monetization service. The main role of a web server is to handle HTTP requests; these are the protocols the web is built on so the server will only be able to access the information upon request such as request bodies or headers. Information on a server is often limited to a request, a more limited option than what you get from a client. So to use a server side call with a UTM parameter info, you need to have client side logic to parse the parameters, send it to the server via C and then send it to the monetization service. 

When do I track client and server? 

There are 3 key dimensions to consider when tracking client and server. They are:

• Monetization objectives: because of their nature, some tools and events have to be implemented in a client. Things like heat mapping tools or session recording tools and ad pixels have too much leverage on the browser so they can’t be replicated on the server.
• Engineering resources: a lot of the things on a client that can be tracked are usually also available for tracking on the server. But, information like UTM parameters and IP address are already accessible, it would expend more engineering resources tracking such things.
• Privacy concerns: some users may have Ad blocks installed as a chrome extension in their browsers because of concerns for their privacy. If they have an Ad block, it will prevent data that can be used for monetization from leaving their browsers so you may have incomplete data on your users.

What are the trade-offs?

The major trade off is the context vs reality that is volume of data you will collect vs the level of control you have over sending the data. Each client’s browser has access to attributes that are user specific like IP addresses so it means that tracking the client will give you access to this contextual information for easy collection and tracking. The other downside of tracking clients is the little amount of control you have, the user may use an ad blocker which will create a gaping hole in your monetization data. Other factors include the character of the browser such as page unloading which can interrupt the journey of outbound monetization requests. For these reasons we recommend using the servers for tracking as they are more reliable. You can send offsite events, mission critical events, tracking revenue and other sensitive events through the server. 

This does not mean client tracking is bad, there are some advantages to it like; the server isn’t able to access information in the browser so it needs more engineering resources to replicate such a call on the server. The inconvenience of tracking IP addresses, UTM parameters and so on make it  preferable to lose a little percentage of data where an ad blocker is enabled or when a browser behaves oddly.