Client-Side vs Server-Side Tracking

When it comes to streaming user actions to your Mixpanel project, there are a few different approaches to consider. Each has pros and cons depending on the type of data you need to collect, your tolerance for data reliability, and the ease of implementation.

Client-Side Tracking

Under this method, the tracking payload (e.g. a Mixpanel event) is generated on the client device and sent directly to you the Mixpanel API. If you are using any of our client-side SDKs with the default configurations, this is how you're sending data.

Pros

  • Easy to track client-side actions and state
  • Easiest to setup
  • Requires no additional infrastructure
  • Our client-side SDKs make it easy to:
    • track anonymous (non-logged in) users across requests
    • persist property values across requests (what we call Super Properties)

Cons

  • API requests are often blocked by Ad Blockers
  • Difficult to keep metrics consistent across platforms
  • Difficult to fix integration mistakes quickly (particularly on mobile applications)

Client-Side Tracking with a Proxy

Under this method, the tracking payload (e.g. a Mixpanel event) is generated on the client device and sent to your own server first which relays it to you the Mixpanel API. You can configure all of our client-side SDKs to send data to your proxy server. See Self-Hosted Tracking for more details.

Pros

  • Easy to track client-side actions and state
  • Less susceptible to being blocked by Ad Blockers
  • Grants you more control of the data you're sending to your Mixpanel project (filtering, cleaning, etc)
  • Our client-side SDKs make it easy to:
    • track anonymous (non-logged in) users across requests
    • persist property values across requests (what we call Super Properties)

Cons

  • Requires some additional infrastructure
  • Difficult to keep metrics consistent across platforms
  • Difficult to fix integration mistakes quickly (particularly on mobile applications)

Server-Side Tracking

Under this method, the tracking payload (e.g. a Mixpanel event) is generated by your server and sent to the Mixpanel API as a part of your natural application flow. For example, when a user loads a web page a request is made to your web application server. In the code that handles the request you can create a "Page loaded" event and send it to your Mixpanel project from your server.

Pros

  • Not susceptible to Ad Blockers
  • Data is consistent across platforms
  • Easier to fix integration mistakes quickly
  • Requires no additional infrastructure

Cons

  • Harder to track client-side actions and state
  • Requires some custom code to:
    • track anonymous (non-logged in) users across requests
    • persist property values across requests (what we call Super Properties)

Visual Representation

Which Should I Use?

TL;DR: For the best data quality, Server-Side > Client-Side with Proxy > Client-Side

The best implementations we see employ a hybrid approach to maximize data quality while maintaining the flexibility to easily collect the metrics they need. When evaluating how to track a particular metric, we suggest starting with "Server-Side Tracking" and only move to either of the "Client-Side" approaches if it's not possible to collect purely server-side. This can be the case if you need to track interactions with your product that don't result in any natural server requests (such as a button click that opens a modal). For this type of data, we recommend the "Client-Side Tracking With Proxy" approach as it gives you more control over your data pipeline and helps prevent data loss due to Ad Blockers.

Updated 2 months ago



Client-Side vs Server-Side Tracking


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.