propertiescan make the implementation easier. However, we are still faced with the choice as to where to implement that tracking—on the client or on the server.
While it's easy to just do everything on the client or everything on the server, in reality, it isn't that simple. Depending on what you want to learn about your customers, there are types of events that are only available on the client. On the other hand, there are many common pitfalls on the client, such as ad blockers, that make implementing analytics on the server a better option.
In this lesson, we'll explore the differences between the client and the server. We'll also share a quick guide to help you determine where certain events should be implemented and explain the trade offs in more detail so you can make an intelligent final call.
To help you understand the nuances and trade-offs of tracking on client vs. server, here are the basics of their technical capabilities.
On the web, a client is a web browser or mobile device—whatever the user is using to navigate the Internet. The server is a computer that returns web pages to be rendered in your browser or mobile app.
A: Whenever any user goes to a website, a request is made to the web server to retrieve the necessary files (HTML, css, js) to render that page in the browser. This link, while not directly related to either client- or server-side tracking, shows that you can mimic a client-side call on the server by sending the necessary info from the client to the server then sending the call on the server.
B: This is tracking on the client: sending tracking data from the browser to the analytics service. Since the call is made from the browser, client-side tracking gives you easy access to a lot of contextual browser (and, therefore, user) information. These include:
C: This is tracking on the server: sending tracking data from your web server to the analytics service. The web server's main role is to handle "HTTP requests", which is the underlying protocol upon which the web is built. As such, the server only has access to information in the request, which include (but are not limited to):
Note that the information on the server side is limited to the request, which is more limited than what you can get from the client. In order to send a server-side call that contains UTM param information, you'd need some client-side logic that will parse the parameters, send it via C to the server, then send it from the server to the analytics service.
We've made a guide flowchart that'll recommend whether to implement the event in question on the client or on the server depending on your circumstances.
Before we dive in, there are three main dimensions you should consider: your analytics objective (i.e. what you want to learn), the available engineering resources, and the privacy concerns of your target users.
That being said, keep in mind that the below is just a guide! It's neither definitive nor black and white because there are situations where you'd make the opposing case given enough thought and engineering resources.
The big trade-off is context (or the amount of data you can easily access and gather) vs reliability (or how much control you have over the actual sending of the data).
To better understand why, let's dive into the technical details that separate client and server.
The client, being that it's the browser, has easy access to user-specific attributes, such as cookies, IP address, user agent, referrer, and UTM parameters. This means that if you track on the client, you can easily collect and track all of these contextual pieces of information. Some common business use cases for tracking these pieces include:
However, the downside about tracking in the client is that you have less control. The end user can enable an ad blocker, which can punch a hole in your analytics data. The browser also has its own unique behaviors such as page unloading (when you click a link on a site and the browser begins loading the next page) that can sometimes interrupt any "in-flight" outbound analytics requests (more on troubleshooting for this specific browser case). Therefore, we usually suggest tracking on the server. It tends to be more reliable.
These are the kinds of events that we recommend sending via the server:
However, there are some reasons why you'd want to stay on the client. Since the server can't easily access the information in the browser, you'd need additional engineering resources to mimic the same call on the server. For example, you would need client-side logic to capture the UTM params, send it to the server, and then have the server send it to your analytics service. Since analytics data is useful directionally and for trends, many times the convenience of tracking UTM params, ip address, etc. on the client outweighs the possibility of losing a small percentage of data here and there to an ad blocker or weird browser behavior.
Therefore, the rest of the decisions (aside from the first three steps) in the flow chart can be done on either client or server side (though we strongly encourage tracking revenue and sending mission critical events on the server side).
We hope that this provides some insight as to the trade-offs of tracking certain events on the client vs on the server.
Do you have a different approach to deciding what goes on the client or server? We'd love to hear it on Twitter!