Serverside tracking (EN)
- Miranda Blom
Â
Serverside tagging is used to improve website performance and have more control over the data sent to external connections. If various tools connect to the website and not every tool needs to receive personal data, this tagging can be a good way to keep control of your data. When we talk about serverside tagging in this article, we mean sending events via the server to the Squeezely platform.
Although it all has to do with optimizations of data from the front-end, this is not to be confused with first-party cookies and it also has nothing to do with blocking the Squeezely script by Ad-blockers, although there are nice optimizations for that too. We will briefly explain this later in this article.
Â
How does server-side tagging differ from client-side tagging?
Client side tagging is still most commonly used. You send events from the website to various platforms, including Squeezely, but also third parties such as Meta, Criteo and Google. The front-end fires these events and these are requests that you can find, for example, in the Network tab of your browser's developer tools.
If many parties are linked to the website for all your follow-up, this can cause delays to your website. The events can be set-up everywhere and nowhere, which means you can lose track of which party receives which data. The latter can be limited somewhat by setting-up the tagging in Google Tag Manager.
If you want to tag serverside, the data first goes to a central point (your server), which then sends it out to all these parties. This all happens in the background (back-end) and you will therefore no longer see it on the website (front-end).
Client-side tagging vs. server-side tagging - Tag Manager Help
What if I want to configure the tagging of Squeezely server-side?
Server-side tagging is possible with Squeezely, here are a few things to keep in mind
Script Squeezely
The Squeezely script will still need to be loaded on the website. This script not only ensures that you can easily send events to us, but also that we can place the first-party cookie, match profiles through a link from the email and show personalizations. This script will automatically send one front-end event; the SessionStart. This is an event without data, which means it has minimal impact on both sensitive data and speed. However, this front-end SessionStart is also essential for Squeezely and server-side tagging. This also ensures that a profile is created for your visitor's cookie. This is important for the next step.
Events from the server
Below is an explanation of the API. Always check the API documentation for the most recent base URL and authentication. When we change the API, the API docs will always be updated first: https://app.squeezely.tech/documentation#backend-api
When sending events from the server to Squeezely, you will use our API for backend tracking https://app.squeezely.tech/documentation#backend-tracking
The call is a POST to https://api.squeezely.tech/v1/track
For the authentication of your call, you need two headers: X-AUTH-ACCOUNT & X-AUTH-APIKEY . The values for these two headers are available in the Settings of your Squeezely Merchant. Every merchant has its own credentials, please keep this in mind when implementing this for multiple Merchants.
Next you can send the required events to Squeezely. Check out this page for the most common events and their data: Events (EN)
When using only server-side events you will require an identifier. In Squeezely you can have multiple identifiers (in order of priority): userID, email and cookie. When a visitor lands on your website, you will most of the time have no userID or email, so the visitor will be tracked by a cookie. In the API you can send sqzly_cookie to track and update the correct profile. Unlike a userID or email address, a profile cannot be created with just a cookie in the API. That's why the Squeezely script with the SessionStart on the front-end is so important, this will create the profile first. The cookie that is required can be found as sqzllocal in the cookies, als see Cookies (EN) & User consent / cookie management (EN)
A payload for a ViewContent event could look like this:
{
"events": [
{
"event": "ViewContent",
"sqzly_cookie": "sqzl6548db2900000340e093",
"products": [
{
"id": "833",
"name": "Product 1"
}
],
"custom_field": "your custom value"
}
]
}Ratelimit
Via the API you can make 250 calls per minute, but you can send 250 events simultaneously if necessary. The rate limit is reset to 00 seconds of the minute. If you have many events, see which ones are really necessary to send via the server, because they have the most impact or personal data. A hybrid version of server-side tagging together with 'normal' front-end tracking is certainly possible.
But what about server-side cookies?
The cookies that are set on your website, are set by the Squeezely Javascript. Even though this cookie is a first-party cookie, the rules are becoming increasingly strict and cookies set by JavaScript are deleted more quickly (by Safari even after 7 days). When the cookie is then set/overwritten by the server, the browsers will accept (for the time being) the end date you give it yourself. You can find how to overwrite the Squeezely cookie here in our manual: ITP / First Party Cookies (EN) | Solution rewriting the cookie on the server level
Although it is also done at the server level, this is not related to or necessary for server side tracking. If you have a lot of visitors on Safari, this is definitely recommended.
Will I bypass ad-blockers with server-side tagging?
Although a lot is sent via the backend and that makes a difference, you still need the Squeezely script and the Squeezely cookie to create the profile. You can load our script via a subdomain of your site via so-called CNAME cloaking. This does not allow you to bypass all, but certainly many, ad-blockers. You can find out exactly what this means and how to set it up in Squeezely here: Custom tracker domain (EN)