Every article touting the benefits of product / behavioral analytics should end with a giant asterisk. Tools like Amplitude, Mixpanel, and Heap can absolutely give you key insights into user actions. But getting the full value from these tools means looking at how your team tracks user actions, and how you plan to grow.
This raises one of the most important questions every data-centric company must wrestle with as they plan their analytics strategy: “Should we track user actions on the client side, or on the server side?” The short and bittersweet answer: it depends. In this article we’ll clarify the differences between client-side tracking and server-side tracking for product / behavioral analytics. We’ll share the pros and cons of each, and explain why you should set up both types of tracking for the most accurate picture of your customers’ journey.
Defining Client-Side Tracking and Server-Side Tracking
Anyone with expertise in product / behavioral analytics can skip this section.
Client: Whichever tool the user employs to access your product, whether that’s an app on their mobile device or a web browser
Server: The backend computer that sends new content to be rendered in the user’s mobile app or web browser anytime the user takes an action in your product
Client-Side Tracking: Data is sent directly from the user’s app on their mobile device / web browser to your product / behavioral analytics tool
Server-Side Tracking: Data is sent from the backend computer to your product / behavioral analytics tool
What Would Analytics Tracking Look Like In A Perfect World?
Before we discuss the differences between client-side tracking and server-side tracking, picture the ideal scenario in a perfect world (or at least, a perfect analytics tracking implementation). This implementation would be accurate, full, and timely.
- Accurate: Your analytics dataset is consistent and trustworthy. Every team has access to the same data from one single source of truth.
- Full: Your analytics data contains all the information you need to answer any question related to user actions in your product. This includes everything from UTM parameters to any meta data that could be valuable for segmenting your audience.
- Timely: Everyone can access the data in near real-time, depending on their specific needs.
A perfect implementation would let you track every detail from both the client and the server with every user action, including complicated triggers based on how they engage with your product.
But everything comes at a cost, which is where our perfect world departs from reality.
There are definite costs associated with capturing every UTM and byte of metadata for client-side tracking. And these costs balloon as your user base increases. On the backend, serving-side tracking is limited by data storage costs as well as ETL + rETL processes. Also, a lot of that data might be irrelevant to your needs. But even if you don’t use it in your product analytics, you still have to pay to store it.
Pros and Cons of Client-Side Tracking
What should you consider before implementing a client-side tracking SDK?
Pros
- Easy to implement: simply add the script to the header of your website (or SDK to your mobile apps) and trigger an event
- Fast turnaround: implementing client-side tracking can reduce your developers’ workload by relying on ready-made functions and abilities such as cross-domain tracking, identity management, and more
- Constant code updates by vendor, sometimes even automatically deployed, and support for new technologies, web browsers, and more: changes related to privacy standards like third-party cookie consent and GDPR are critical, and are added on each version update
- Easy to track anonymous (non-logged in) user data
Cons
- Unreliable, due to ad-blockers: you may lose events for 30-50% of your users
- Difficult to keep metrics consistent across web, iOS, and Android since each system requires its own tracking
- Difficult to fix integration mistakes quickly, particularly on mobile applications
- Tracking will diverge over time due to old mobile client versions
- Batching, network, and downtime can all impact the validity of your data
- Considered as third-party tracking
Implement client-side tracking, and you can potentially access a wealth of information about your users’ actions. That is, if everything goes smoothly with every integration and your users always update their mobile device to the latest OS. Tightening privacy standards are also making it more and more unrealistic to track every action from specific individuals at every touchpoint on their journey.
Pros and Cons of Server-Side Tracking
Server-side tracking carries its own set of opportunities and limitations.
Pros:
- Reliable and trustworthy: it’s your own server and you maintain it, so the number you see will always match the numbers queried by your BI analysts anyone else on your team
- Consistent: all the data is collected into a single source, and it won’t change based on old clients or operating systems
- Easy to fix: addressing any issues that might pop up and backfilling historical data is much simpler
- Privacy: server-side tracking is considered first-party tracking
Cons:
- Challenging to implement: usually takes more dev time to collect and manage all the relevant information pre- and post-login
- Slow implementation time: if you rely on server-side tracking, you’ll need to build custom models and functions to track UTMs, domain persistence, and more
- Tech debt and additional resources: you’ll need to provide in-house support for any changes to privacy standards or cookie consent
With server-side tracking, even though you won’t be able to track as many details about users’ actions, you can have a higher level of confidence in this data. Unfortunately, implementing server-side tracking is often much more difficult.
Practicality Over Perfection: Implementing the Right Type of Analytics Tracking for Your Product
There’s no point in wishing for a perfect analytics tracking implementation. Besides, everything meaningful happens in the real world. And to measure it, we recommend a blend of client-side and server-side tracking.
We’ve worked with hundreds of companies on analytics projects. And we’ve found the following hybrid approach will work in the vast majority of situations:
Client-side
- Implement client-side tracking to record user’s clickstream data that you can’t collect from the server.
- Use a proxy to reduce the loss of events due to ad blockers. Bonus: this is also considered first-party tracking, so it doesn’t run afoul of privacy restrictions.
- Make sure to create a clear tracking plan for each OS so your metrics are consistent.
Server-side
- Always track your “key metrics” via the server. This way, if you ask a business-critical question you know it’s from the same source and not blocked
- Have retries and logs in place so your analytics tracking won’t fail during downtime on the client side.
- Enrich your data with the ability to send historical details.
- Backfill data when new information is needed.
No one sets up client-side and server-side tracking on a whim. There are many factors to consider, some of which are at odds with one another. Ultimately, your analytics tracking implementation will be as unique as your company. And while we’ve shared an example of a hybrid implementation that has delivered good results for many different types of companies, details matter. If you need guidance setting up client-side and server-side tracking, or you think you might need a custom blend of the two, reach out to us and we’ll be happy to discuss your analytics needs.
