Server-Side vs. Client-Side Tracking

Overview

Welcome to the MetaRouter documentation ecosystem! MetaRouter offers a first-party customer data infrastructure that relies entirely on server-side data tracking. Before diving into the specifics of the MetaRouter platform, this article will cover the basics of why we have built a platform that is entirely server-side. If you feel that you already have a grasp on this topic, feel free to move on to the next article, What is MetaRouter, or explore our collection of event ingestion methods and UI documentation.

Let's get started! There are three forms of tracking that we'll discuss here:

  • Client-Side Tracking
  • Hybrid Tracking
  • Server-Side Tracking with MetaRouter

Client-Side Tracking

Client-side tracking is the traditional form of customer data tracking. When using common analytics and advertising tools, they almost always require a javascript snippet to be placed on your website in order to function. These snippets provide two primary functions:

  • Determine who the user is, according to cookies or some other identifier.
  • Record and pass information about what is happening on the website, including the pages and content viewed by a user, and the actions a user takes on those pages (e.g. product purchases, form fills, etc.).

The culmination of these is an event or combination of customer data the describes who the user is and how they're interacting with your website. In aggregate, this data can help create robust analytics and data science capabilities, serve ads to specific audiences and attribute success to specific marketing channels, and more. You can find a description of a common event here.

This diagram summarizes how this information is generally passed from the browser (client) to a vendor:

Step 1:

A user opens your website and interacts with the webpage. When the page is opened, various vendor tags are also loaded.

Step 2:

Vendor tags load their respective javascript libraries upon page load. As a user navigates your page and clicks on content, watches videos, purchases products, and performs other tasks, the vendor libraries provide the ability to track these actions as they occur. The library also provides the ability to send key information about the cookies or other identifiers that might be present within the user's browser. If an identifier does not exist, typically the tag will attach an identifier to the browser.

Step 3:

Event and identity information is sent from the browser to the vendor's server, which is typically designed specifically to accept events being generated by the vendor's tag.


Client-side tracking has been the backbone of the customer data industry for the last two decades. Even when tag managers are used, they are essentially facilitating this exact process by loading vendor tags on the page. However, there are a few key drawbacks to client-side tracking with third-party vendor tags:

  • Websites often load dozens of tags upon load. Each tag introduces page speed latency- we have seen individual tags cause up to 200ms of latency. Given the link between page speed and business outcomes, loading lots of tags is not ideal.
  • Inconsistent browser experiences, including ad and tracking blockers, mean that the efficacy of third-party tags has degraded over recent years. This means less effective measurement and, ultimately, decision-making when evaluating performance within your vendors.
  • Third-party tags contain code that you have no control over. This introduces major security concerns and general IT anxiety, and limits how your data is tracked and transformed prior to reaching your vendors.

Hybrid Server-Side Tracking

In contrast to client-side tracking , server-side tracking involves the processing of data on a server, rather than on the client. Organizations often want to supplement their client-side tracking with server-side events (hybrid tracking) for the following reasons:

  • Data processing requires no client resources, so browsers load quicker.
  • When data is tracked via an organization's servers, that means the data is first-party and not restricted by third-party blockers.

Hybrid tracking is necessary when client-side tags are still required to pull key information from the page- namely, identifiers that are not available on the server like cookies. This enables core functions like audience building, advertising conversion tracking, measurement & attribution, and linking a user's anonymous sessions with known sessions (such as after a user creates an account), while also introducing some benefits of server-side tracking.

However, this strategy still requires client-side, third-party tags to load, which continue to slow websites down and introduce security and control concerns. Additionally, events tracked on the server require engineering implementation, as these need to be instrumented within your website's code. With some tools, it is possible to bypass this by passing data generated on the client to your server, but that does not resolve the key issue of resolving identity, nor does it resolve data quality issues caused by ad and tracking blockers.

Server-to-Server Tracking with MetaRouter

The MetaRouter platform is designed to replace third-party, client-side tags with an entirely first-party, server-to-server ecosystem. You can think of MetaRouter tracking as Client-to-server-to-server, as you can see in the below diagram:

Step 1:

A user opens your website and interacts with the webpage. When the page is opened, a single client-side MetaRouter tag is loaded, instead of multiple vendor tags.

Step 2:

MetaRouter's Analytics.js library loads on the page. This library provides a standardized specification for tracking various events- you can find more information on event methods here. Analytics.js generally provides the means to track any data that vendor-specific tags would in the advertising, marketing and analytics industries. Additionally, it assigns first-party cookies that contain AnonymousId values.

A key component of that library is that it contains MetaRouter's Sync Injector which can retrieve identifier values based on cookies or other tracking IDs by making requests to vendor servers that can provide the necessary IDs. Once the sync injector has retrieved the necessary IDs, it attaches those to the first-party cookies that has already been set and is uniquely identifiable via the AnonymousId value. You can find more information on the Sync Injector here.

Step 3:

The client sends an event stream to a MetaRouter cluster, which represents an event processing infrastructure hosted within a private cloud environment. The cluster contains an Ingestion API, which ensures that each event has the necessary information included in order to be properly transformed and forwarded to vendors.

Step 4:

Via the MetaRouter UI, you can designate the integrations you would like to send your data to, as well as customize the transformations you would like to apply to events before they reach the vendor. Any parameter you send with an event is available for transformation within the UI.

At this step, the transformations you have designated are applied to each event.

Step 5:

Events are sent to the event forwarder, or multiple forwarders if you have more than one MetaRouter vendor integration enabled.

Step 6:

Events are forwarded to your integrations. That's it!

Server-to-Server-to-Server Tracking with MetaRouter

In the above section, we mentioned that the primary means for customer tracking is via client-to-server-to-server tracking, where an event is produced on the client, is sent to a server with MetaRouter installed, and ultimately sent to a vendor's server. MetaRouter also enables the tracking of events directly from the server where your website or application is hosted, which can then be sent to MetaRouter just like a client-side event. You can head over to our Server-Side Tracking SDKs Overview for more information on tracking events from your server.