Client vs Server-Side Tracking: What Is It & When to Track Each

Knowing how to consolidate events and effectively use properties  can 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. But, before we dive into what client vs. server tracking entails, let’s cover what these terms mean.

Client vs. server tracking: what’s the difference?

The main difference between client and server is that the client-side makes requests to retrieve files or web pages, while the server-side fulfills these requests. So, the client is the web application, browser, or device with a user interface that’s used to browse (think of using Google Chrome on your mobile device or personal computer), and the server is where information requested by the user is retrieved from.

What exactly is tracking on client and server?

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 by the operating system 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:

• Cookies: these are mechanisms for websites to remember stateful information or to record the user's historic browsing activity. You've probably heard of cookies being used to manage shopping carts, or whether or not you've logged in, etc.
• UTM parameters: these parameters are in every digital marketer's toolkit. Their utility is outside the scope of this lesson, but check out this great introduction to them here. Basically, they're these semantic parameters included in the URL that help analytics tools know what ad campaign or channel a user went through to land on the destination site.
• IP address: IP address is a numerical label assigned to each device connected to the Internet. From marketers' perspectives, it's useful to learn the geographic location of the user. There are many analytics tools or data enrichment services that'll show you the user's location based on their IP address.
• User agent: Within the context of the Internet, the user agent represents the device and browser specifications of the user. This is great to learn about what devices your users use while on your site.

C: This is tracking user interactions 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):

• Headers: This is mostly information for machines to direct traffic and it doesn't provide that much use to humans.
• Request Body: This is the main part of the request. In the majority of cases, this is where you would put data if you want to send it via HTTP. 

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 parameter 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.

When do I track on client and server?

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.

• Analytics Objective: Some events or tools, due to their nature, must be implemented on the client. For example, session recording/heat mapping tools and ad pixels leverage too much of the browser to be replicated on the server.
• Engineering Resources: Most things that can be tracked on the client (with the exception of client-only events) can also be tracked on the server. However, since some information on the client is more readily accessible (e.g. IP address, user agent, utm parameters), tracking the same thing on the server may take additional engineering resources.
• Privacy Concerns: the privacy concerns of your users indicate the likelihood they would have Ad Block enabled for their browsers (often in the form of a Chrome extension). Ad Block prevents any analytics data to leave the browsers, meaning that you could be missing data from parts of your user base.

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.

What are the trade-offs?

The big trade-off in functionality 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 on a computer network.

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:

• send targeted marketing messages based on users' locations
• learn the breakdown of your users based on mobile, desktop, and tablet
• determine marketing campaigns, and drive traffic and conversion via UTM parameters

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:

• "Offsite" events: This just means events that aren't tied to a user behavior that occurs on your website, or an event that is the result of a calculation based on your production database. An example of this would be our nightly cron job that calculates API usage across our customer base, then sends server side .track()  calls.
• Tracking revenue (or other sensitive events): Revenue figures (though they should be captured by your billing system) should be sent on the server, since they're sensitive and discrepancies from ad blockers or browser mishaps would be frustrating to debug.
• Mission critical events: If you're using email or marketing automation tools that rely on events to trigger high-value emails, it's best to keep these events on the server side. It would be a bummer to have a customer miss out on a coupon or re-engagement email due to ad block.

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 parameters, 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 parameters, 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 in client-server architecture.

Do you have a different approach to deciding what goes on the client or server? We'd love to hear it on Twitter!