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 users, 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

This week, we’ll explore the differences between the client and the server, a quick guide to determining where certain events should be implemented, and explain the trade offs in more detail so you can make an intelligent final call.

A Quick Note on Ad Blockers

We talk about ad blockers and suggest the alternative of collecting the analytics data (by making the same call on the server). Kindly note that we, by no means, condone gathering data from users who, through the act of using ad blockers, wish to prevent their data from being collected.

We should respect the privacy of our users and their choice of using ad blockers. If there is something that must be tracked on the client, one suggestion is to nicely ask your users to disable ad blocking so you can provide them a more personalized browsing experience.

What exactly is tracking on client and server?

To help understand the nuances and trade offs of tracking on client vs. server, here are basics of their technical capabilities.

On the web, a client is your browser (or mobile, though this post really details trade offs specific to browsers)—what you use to navigate the Internet. The server is a computer that returns web pages to be rendered in your browser. Learn more about web architecture here.

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, the user) information. These include:

• cookies: these are a mechanism 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, 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 post, but check out this great introduction to them here. Basically, they’re these semantic parameters included in the URL that helps 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 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 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 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 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.

When do I track on client and server?

We’ve made a guide flow chart, depending on your circumstances, that’ll recommend whether to implement the event in question on the client or on the server.

Before we dive in, there are three main dimensions you should consider: your analytics objective (what do you want to learn?), 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 able to replicate 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 make the opposing case given enough thought and engineering resources.

What are the trade-offs?

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 easily can 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, tablet
• determine marketing campaigns 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 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’ll 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 outweigh the possibility of losing data 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!