Server-side data processing is becoming more and more of a hot topic in the customer data industry, in light of restrictions and performance issues plaguing users' browsers. It's a solution that is often referenced by multiple companies in the space: Google, Segment, Tealium, and others are all trying to get in the game and boost their capabilities here, with varying degrees of success.
But there is one key difference that sets MetaRouter apart from the rest.
First, let's discuss what server-side eventing really means.
What is Server-Side Data?
In Chrome, if you open up your Developer Tools and click on the Sources tab, you'll likely see a collection of files here. If you're running common tools such as Facebook Pixel, Google Analytics, or other tools that require a feed of data produced from your users, you should see the files they use to process data and send to their respective APIs here.
Conversely, when data is generated via the server, there is no indication that anything is loading on the page at all—because it isn't! The events are produced by back-end services that power your website (like MetaRouter).
Common examples of events that can be generated here are log-in events, product purchases, and form submissions. These events are typically recorded in a database somewhere for you to access at a later date, but instead of sending the events to a database, you can choose to forward them along to your vendors' APIs so long as they accept server-side events. Facebook's offline conversions API is a great example of this.
What's the benefit of server-side events?
In a nutshell, the primary benefits are improved data accuracy, increased security, and reduced data traffic within the browser session (leading to significantly lower latency).
Events produced on the client are subject to inconsistent browser settings, extensions, and general network risks, and create material network activity. Server-side events do not require any browser resources, so they make your website faster and more performant—to a degree directly correlated with the amount of data processed by each client-side tag you move to server-side.
There has historically been no way to move many client-side integrations to fully server-side. Until now.
Do all client-side integrations need to be moved server-side?
With most vendors, however, the answer is no. The reason why is that anonymous events cannot typically be attributed to any persisting user identifier, because identity still primarily relies on cookies (although that is rapidly changing, which we will discuss shortly). Cookies are pieces of information that live in the browser and signal to your vendors who the user is.
- First-party cookies are useful for the owner of the website that a user is choosing to visit. For example, Walmart's product team if you visit walmart.com.
- Second-party cookies are those set by common social media, advertising and search tools to claim credit for directing traffic to a website or encouraging a purchase. Users must visit these sites in order for them to set cookies.
- Third-party cookies are useful for vendors that provide widespread advertising and analytical services. Companies and advertisers use these services to generate relevant advertisements when a user visits a certain website. Typically, users never visit these sites.
Each type of cookie is essential to tracking ecosystems and personalization, and each lives exclusively within the user's browser.
Therefore, if you're producing events outside of the browser, there is no way to tie cookies to those users. Any measurement and attribution you'd like to perform that relies on a persisting identity of a user from the time they first visit your site as an anonymous user, to the time they provide their identity to you and purchase something, ceases to exist.
The only way to identify a user in a server-side setting is if the user actively provides their information to you, and depending on your industry and web traffic, that may represent a fraction of your total user base.
So, how do other companies handle integrating data server-side?
Other companies run server-side and client-side data in conjunction with each other. A significant limiting factor of running data server-side is that not all vendors support APIs that can process this type of data. Google is an example of a vendor that generally does not accept data produced server-side. They are developing a new solution for server-side eventing, but even that solution will require Google's client-side tag to run.
Another limiting factor is simply the data that can be collected on the server. As mentioned previously, identifying anonymous users is typically impossible for server-side events, which could be a serious detriment to vendor functionality.
How does MetaRouter solve server-side?
MetaRouter enables powerful server-side integrations in the market by addressing the core issues that impact server-side tracking. Instead of relying on server-side APIs, we collect all the data that an event generated client-side would contain, from the 1st-party context, and send that off to servers that our customers control.
In other words, all data is integrated server-side.
What if identifiers aren't based on cookies?
Cookies have been the predominant means for you, your partners, and your partners' partners to track users on your website. A quick search on Google will yield dozens of articles describing the "death of the third-party cookie", which is a serious cause for concern for many organizations. It seems all but certain- the online ecosystem will be evolving to some new solution in the next couple years.
MetaRouter will provide timely, ongoing support for the prominent post-cookie alternatives that arise. Keep in mind, third-party cookies (and to an extent, second-party cookies) will be increasingly subject to restrictions and regulation, but first-party cookies will largely be unaffected due to the critical role they play in allowing a website to function properly (such as bypassing login screens). MetaRouter operates in an entirely first-party context when deployed within your own private cloud environment.
The solutions that arise will still likely involve some sort of identifier, whether it's email addresses, phone numbers, Unified ID 2.0, or others. We'll provide you with the means to connect to your vendors' identity sync APIs, so when the next solution comes along, you'll be able to include any IDs that are required to maintain your vendors' functionality.
And with that, you'll be able to keep your data server-side.