🥳 You have completed all topics in the Handbook. Click here to claim your certificate!

3. Client-side vs. server-side

In the context of data and analytics, the terms "client-side" and "server-side" are often thrown around. They represent different but frequently overlapping aspects of data collection and processing.

Within the sphere of technical marketing, the terms client-side and server-side could be described as follows:

A client is a machine that communicates with the server. The job of the client is to send requests to and then anticipate and process the response from the server. Clients are typically devices and software operated directly by the user, but sometimes a client can also be software running on a server itself.

Thus, client-side is used to describe the actions, mechanisms, and capabilities of client hardware and software, the requests compiled and sent by the client, and the handling of the responses received from the server.

A server is a machine that is designed to intercept and parse the request from the client. There are many different types of servers, such as web servers, email servers, and file servers. 

Thus, server-side denotes the activities that happen purely within a server environment. These include intercepting requests, parsing them, initiating new server-side processes (such as data pipeline ingestion), and compiling the response back to the request source.

As a technical marketer, you will frequently encounter these terms especially regarding data-related processes. You will need to understand the differences, the benefits, and the drawbacks of both approaches. There is no one-size-fits-all approach to data collection, and ultimately you will likely end up with a hybrid model facilitated by technologies like server-side tagging.

Client-side analytics

Client-side analytics typically represents the work of a tracker.

This tracker runs in the web browser or the mobile app, and its job is to collect data about how the user is operating the client-side software.

The tracker can access anything that is made available to its code. In a web browser this would be strictly JavaScript and browser APIs, but in mobile devices the language and the available APIs depend on the operating system and which SDKs have been deployed.

These are typical things available only in a client-side context:

  • The content that is visible to the user on the page or screen.
  • Information stored behind client-side APIs, such as those of the web browser or of the device.
  • The user’s interactions with the browser or device, such as clicks and taps, mouse movement, scroll actions, time spent with the screen in the foreground, etc.

When an analytics platform is solely concerned with what happens client-side, it is a client-side analytics tool. 

In client-side analytics, the user is the centerpiece, and their actions in the client-side environment form the basis of the analytical approach.

Strictly client-side tools include:

  • Screen recording software, which observes the user’s visible viewport and tracks their mouse movements and other interactions on the page.
  • Heatmapping and eyetracking software, which present overlays of the page with heat signatures that represent the areas users mostly interacted with or watched.
  • Page performance monitors, which measure the time it took to load the page and the elements on the page.

Tools like these are concerned explicitly with the information stored and presented in the user’s device. They would be impossible to replace with a pure server-side solution.

Don’t miss this fact!

There are many things that a client-side tracker does that cannot be reliably replaced with a purely server-side solution. Without any tracking code running in the user’s device, it’s impossible to know, for example, the user’s interactions with a piece of content.

Server-side analytics

Server-side analytics is a confusing term.

The most straightforward interpretation of the concept is trackerless analytics. That is, there is no software running to detect the user’s activities in a client-side environment.

Instead, server-side analytics consumes data and information produced purely in a server environment.

Typically, this boils down to log analysis, server-to-server pipelines, and product telemetry.

In “pure” server-side analytics, the focus of data aggregation isn’t necessarily the end user but rather logs stored in a file server or telemetry from other servers and products.

This is still a popular approach when measuring service uptime and performance, or when analyzing aggregates such as the increase of subscriber counts in the CRM.

There are flavors of pure server-side analytics where the user is the focal point, however. In these cases, user data is collected from the CRM and from logs, and their behavior is extrapolated from the server-side metadata rather than from directly observing their actions in the client-side context.

However, server-side analytics is these days used to describe a more hybrid approach. The term “server-side” doesn’t necessarily mean that the entire pipeline needs to be located within server contexts.

Instead, “server-side” is used to describe a data process where the request to the analytics server is dispatched from another server but doesn’t necessarily originate there.

Ready for a quick break?

Now’s a good time to do some client-side maintenance. Take a walk and a cup of water to make sure that your data flows are healthy!

Hybrid approaches (server-side tagging, for example)

With the increased availability of server-side tagging and proxies, the lines between client-side and server-side analytics have become blurred.

A server-side proxy means that there is a server-side endpoint that consumes the requests from the client (or some server-side process) before the request is forwarded to the vendor server. This proxy can be a very simple, transparent forwarding mechanism solely to prevent the client from directly communicating with a vendor server.

A common but ethically questionable use case for proxies is to change the URL of the analytics server from a vendor-owned domain to one that the company controls. Many ad and content blockers target these vendor-owned domains when determining if the request should be blocked or obstructed. By moving the endpoint to a custom domain, blockers will no longer block the traffic. This is ethically questionable because it erodes the user’s agency to choose what data is blocked and what isn’t.

The proxy can also be a more complicated piece of machinery, with full validation and enrichment capabilities. Server-side tagging is an example of this type of proxy.

Server-side tagging moves the logic of tag management to the server. The incoming request from the client-side environment represents the “trigger event”, and the payload of this request is what is used to initiate a variety of processes in the server-side tagging context, such as:

  • Distributing the data in the incoming request to multiple vendors (“tags”) – even those unrelated to the client software that sent the incoming request.
  • Validating and enriching the incoming request data before it is made available to vendors.
  • Initiating data processes, such as by writing the data directly to a data warehouse or a real-time pipeline.
  • Removing sensitive information from the incoming request, and sanitizing and normalizing the parsed data before it is forwarded to vendors.

Even without server-side tagging, the concepts of client-side analytics and server-side analytics overlap greatly in modern analytics stacks.

Data collected from client-side software is often enriched in the vendor servers by integrating it with information from other sources. This is what Google does when joining analytics data with ads data, for example.

Data collected directly from server-side processes is rarely analyzed in isolation – instead, it can be used to enrich existing client-side flows. For example, a common use case is to collect business critical data with server-to-vendor flows, so that it is impervious to client-side mechanisms designed to restrict data collection (ad and content blockers, consent mechanisms, network failures).

Deep Dive

Different types of data flows

These days, analytics data can be collected through a wide variety of different combinations of client-side and server-side measurement.

In fact, just a plain old client-to-vendor stream, where data is collected directly from the user’s device and processed directly into the vendor servers, is becoming quite a rarity.

Although tools like Google Analytics 4 certainly allow you to collect data directly to Google servers, there’s a lot of enriching happening at processing time, which can expand the data that you collected from the client device.

Here are some of the most popular types of data flows utilized these days. But these are greatly simplified – in reality, many complex data pipelines incorporate multiple “stops” between different client and server machines.

  • Client-to-vendor: the traditional “client-side analytics” approach, where data is collected by a client-side tracker and sent directly to the vendor servers.
  • Client-to-server-to-vendor: here, the bulk of data originates in the client, but it is first forwarded to a server (typically owned by the same company that runs the client environment), where it is enriched and validated before forwarded to the vendor servers. This is an example of server-side tagging.
  • Server-to-vendor: traditional “server-side analytics” approach, where the data originates in a server context, from where it is sent directly to vendor servers.
  • Server-to-client-to-vendor: in some rare cases, the server-side environment needs the client to do some work. Typically, this is to enrich the data payload with information from third-party cookies, which are only available in a client-side context.

Key takeaway #1: Client-side represents the data that is collected

A “client” is a machine that sends requests or dispatches to a server. As such, it can mean many different things from devices to smart appliances to server machines, too. In digital marketing, “client-side” is usually restricted to mean what happens in the user’s device and specifically the web browser. Client-side represents the user who visits a site or uses an app. If technology runs client-side, it runs in the user’s device.

Key takeaway #2: Server-side represents machines talking to each other

The term “server-side” is usually used to describe anything and everything that happens in a server environment without involving a client-side component. For example, dispatching requests directly from a CRM to an analytics system would represent a server-side flow. Similarly, parsing application logs and collecting them to a database would also be an example of a server-side process.

Key takeaway #3: Server-side tagging muddies the waters

Hybrid approaches like reverse proxies and server-side tagging add ambiguity to the terms “client-side” and “server-side”. These setups typically involve a client-side component as the dispatch system, but the data is then funneled through a server-side network, where it’s enriched, consolidated, normalized, transformed, and validated before it’s forwarded to vendor servers. So it’s a combination of client-side and server-side data processing.

Quiz: Client-side Vs. Server-side

Ready to test what you've learned? Dive into the quiz below!

1. Why is "server-side analytics" an ambiguous term?

2. What are some of the use cases for server-side tagging?

3. What sort of things would it be practically impossible to measure with a purely server-side approach?

Your score is


What did you think about this topic?

Thanks for your feedback!
Next up

Unlock Premium Content

Simmer specializes in self-paced online courses for technical marketers. Take a look at our offering and enroll in one or more of our courses!

0/27 Topics completed

Continuing strong!

Complete all topics to claim your certificate.

Next Chapter

Online course

Server-side Tagging In Google Tag Manager

Learn everything you need to know about server-side GTM in our flagship course!