Server-side tagging enhances performance and privacy

For businesses to drive more conversions on their websites, they need the right insights. The easiest way to do this is to add third-party JavaScript or cookies to the site for data collection. When expectations and regulations around user privacy rise, meeting both performance and privacy requirements can be challenging. By using server-side tagging, you can address these challenges.

Server-side tagging for Google Analytics and beyond: What Is It?

In Google Tag Manager, server-side tagging is also known as server-side tracking.
Server-side tagging lets you track and send user data directly to your server without adding any third-party code to your website.
The server can run on your own Google cloud platform project or on a different environment of your choosing. You will be the only one with access to the data.
With the server, you can process and transform the data into a form that can be used by third parties such as Facebook Conversion API, Google Analytics, or Google Ads.
Server-side tracking for Google Analytics does not require embedding the Google Analytics tracking code in your website. Instead, you can run this through your web server. This is different from client-side tracking or client-side tagging.

Server-side tagging has what advantages?

This ensures that your site runs smoothly and clients remain protected thanks to server-side tagging. It’s a secure way to send data without affecting your site’s performance. Here are some of the key advantages of server-side tracking.

Content security that is better

Due to the fact that you are setting up your own server endpoint, server-side tagging reduces the number of HTTP endpoints you have to manage.

You must restrict HTTP traffic from the user’s browser when you have a lot of HTTP endpoints. In order to send more user data, you can petition developers to relax the CSP. However, the greater the relaxation, the less efficient the process becomes.

You bypass so much communication when you have your own server container endpoint, thereby making your CSP more robust.

Improved control over HTTP traffic

In addition, server-side tagging allows for more control over HTTP traffic.

The majority of browsers use a content distribution network (CDN) to load vendor JavaScript.

Sadly, this practice exposes browsers to third-party cookies and can easily expose sensitive information.

Because there is a proxy between the user’s browser and the endpoint, you can only leak information in your cloud environment with server-side tagging.

While the solution isn’t perfect, it does give you more control over the data streams collected by the server-side container.

Also, you can modify the HTTP response from the server container to the user’s device. You can convert JavaScript cookies into HTTP cookies, extending their life from 7 days to as long as you wish.

By searching for consent strings in the user’s cookies, you can also manage the privacy preferences of your users more easily.

Load time can be reduced

When adding Javascript snippets to your website for analytics and marketing, they can impact performance. Server-side tagging allows you to load a few scripts instead of loading countless ones. These scripts would then send data to your server-side web GTM container and modify the data for specific configurations before sending it wherever it needs to go.

Vendor data can be controlled

You can also use server-side tracking to control what information is sent to different vendors. For instance, you can use JavaScript to collect data on your site’s visitors. In order to send the data to the server-side container of Google Tag Manager, you need to use server-side tagging. From there, you can decide whether to send it to Google Analytics or another method.

Creating a custom subdomain for your data

You can create a custom Subdomain for your tagging server, which routes data to that domain. Once there, a server-side container is waiting for the data. It can then send it to Google Analytics for analysis.

Remove personally identifiable information from URL parameters

While clearing HTTP traffic of sensitive data streams is relatively straightforward, it does not address the issue of vendors requiring you to populate URL parameters with personally identifiable information.

The server container enables you to build clients that search through all headers and bodies for personally identifiable information (PII), not just those related to Universal Analytics.

As well as validating and fixing requests, server containers also perform other functions. For instance, you can send non-numerical data as event values of Universal Analytics requests. These will be collected and registered by Google Analytics, but will be discarded at the processing stage without warning.

Server-side tagging allows you to fix this problem by converting faulty event data into a number, which significantly improves the quality of your data streams.

A greater degree of flexibility

Server-side data processing gives you more control over data streams before packaging them up and sending them to vendors. As a result, the flexibility you gain is immense.

It is possible to reduce event data collection to a minimum using server-side tagging. For example, you could collect only user IDs, session IDs, and content IDs. This server-side setup allows you to bypass the need to store all the information in an exposed format by enriching it with these pieces of information as keys.

In server-side tagging, you can run code on your server without affecting the speed on the client side. Cryptographic hashing, a costly computational process, occurs in server-side processing containers.

Is server-side tagging problematic?

There are still a range of concerns you need to be aware of when moving devices behind the veil of the server.

Endpoints on the server are lacking

In order for a server container to replace conventional app- or browser-based tracking, vendors must be able to collect HTTP requests from it. If they cannot, the server-side setup will fail.

You can usually get around this problem fairly easily. Most vendors offer both:

The JavaScript library has an HTTP endpoint that can be accessed via the web
This is a simple image pixel that can be used to collect GET requests

It is important to keep in mind that the trick here is to reduce the burden of heavy vendor Javascript. Most vendors have detailed code running all the time in the background, which bloats libraries.

You will be able to create event streams from the user’s browser to the server container without having to load JavaScript elements on the server. For instance, Facebook offers an API for converting events from the browser to the server container.

High Cost

The cost of server-side tagging is also more significant than that of just running scripts in the browser. The former requires a monthly expense, whereas the latter is essentially free. The price of server-side tagging can range from $100 per month or more, depending on the load.

You will receive a lot of value in return. The server-side tagging method improves the security of sending measurement data to marketing partners as well as allowing firms to collect data streams in a secure manner. It is up to you to determine whether the cost-benefit is worth it for you. Only you will be able to decide whether it is for you.

Management of consent is determined by the admin

Most websites use client-side consent management tools to accept third-party cookies and to determine which event data can be collected by pages.

As a result of server-side tagging, this process becomes more challenging. The server only receives raw event data streams from the user’s browser. Client-side tracking consent data cannot be interpreted by servers using existing APIs, so you’ll have to create your own mechanisms to do so.

The GTM server-side tagging system will hopefully make this process easier in the future, but at the moment, you’ll need to manually do it. If a user submits consent information, you’ll need to build systems that report it to the server.

Data collection is challenging

The browser has some privacy issues, but it also offers some advantages. For example, browser-based vendor scripts are very useful for collecting audit data. There are many JavaScript hacks that can easily be rooted out, including cookie leaks, CSP workarounds, and cross-site scripting injections. As a result of moving to the server side, third-party JavaScript runs less on the site, but auditing data trails becomes more difficult. Experiencing event data will become more difficult because server-side tagging removes all traces of how bundled data was used.

In this way, you can comply with GDPR and CCPA while protecting the rights of internet users. Data collection and careful parsing let you avoid litigation and brand damage.

Technical Issues

Lastly, as the above discussion shows, moving to server-side tagging is also more technical. You already need a good understanding of web server architecture, HTTP, privacy issues, and analytics. In order to manage your tags server effectively, you need significant technical expertise. The more you get into it, the more technical it becomes. This is why organizations hire professionals with expertise in this area. This is the most appealing strategy due to the legal risks and complexity of the tasks.

What Is A Tag?

When it comes to server-side tagging, a tag refers to a piece of code provided by analytics, support, or marketing vendors. It helps website owners integrate their products into their websites.

Instead of adding these tags directly through Google Tag Manager, you can now publish and configure them through the Google Tag Manager user interface.

The following are some examples of common tags:

Remarketing code for Google Ads
Tracking code for Google Analytics Universal (GA4)
Scripts customized for HTML
Various GDPR data privacy scripts, including Cookiebot
Facebook Pixels

Tracking issues on the client side

In contrast to client-side tracking, server-side tracking involves the user’s web browser interacting directly with analytics services. When a page loads, the server container is already loaded, triggering all tracking codes. The interaction data will then be sent to analytics services as a result.

Server-side vs. client-side tagging

A “client” is simply the browser or application the user is using. In the case of website privacy, it is almost always the user’s web browser.

Every time an event occurs, such as when the user clicks a button or opens a new page, client-side events are sent to a tag manager (such as Google Tag Manager).

Server-side tagging, on the other hand, is different. The client performs a particular action and then event data is sent to the analytics platform.

Google Tag Manager Step-by-Step Setup

Setup: How to get started

First, you need a client side container that will make the call to the server side container. Next, you need the server-side container which will take the request. A server-side container needs to be hosted in the cloud. Google Cloud Platform is the preferred method of hosting the server side container. However, you are not required to use Google Cloud.

Creating GTM Server Side Container

In order to create a GTM server-side container, you have two options:

This option automatically creates a server on the Google Cloud server and deploys your Google Tag Manager server.
It is also possible to manually provision tagging servers. If you do this, you will have to manually configure your server and deploy Google tag manager.

Deploying GTM Server Side Container

Using Google Tag Manager, click Admin. Select Container Table and click the “+” icon. Add the container ID and choose Server as the target platform.

Choose either automatic or manual tagging when the pop-up appears.

Client-side GA4 Base Tag

Upon setting up your container, copy the URL for the tagging server. Then open the GTM server container. Go to Client >> Create GA4 Client and click Save. Then go to Tags to create your GA4 Tag. Use the drop-down menu to specify that the client name equals GA4 in Tag Configuration.

Client” and “Request” in the server-side GTM

The server container URL will allow clients within the Tag Manager server-side container to receive data. At this point, you can determine the order in which clients will run and the activation criteria in response to requests.

Click the client’s name in the left-hand menu of Tag Manager Server Container to edit the client’s details. In the Priority setting, you can tell the system which clients you want to run. Active clients are those that match the incoming request first.

As part of the Activation Criteria, you can also specify when the client will respond to requests. Depending on the type of requests clients make, you can use the default UA path (/collect, /r/collect) or the default gtag.js path. Click Add Measurement ID if you want to add more than one destination ID.

GA4 Base Tag in the Server

With Tag Manager, you can add the GA4 base tag to your website:

Open Tag Manager and choose Tags
Click New
Give your tag a name and then click the pencil icon in the top right.
Choose Google Analytics: GA4 Configuration from the drop-down list of menu options
Click the Triggering box
Check All Pages as the trigger
Click Tag Configuration and enter the measurement ID
Click Save and Submit
At this stage, if you want to add a name and description of this version to your Google Tag Manager account, you can.
Click Publish

Variables in GTM server side

The GTM server-side container includes a number of built-in variables. These include:

Event name (passing an event data object to the container returns the value of the event name field
Random Number (returns a random positive integer)
Container ID (tells you the identification of the server container)
Request path (tells you the path of the incoming HTTP request)
Query string (tells you the strings of all incoming HTTP requests)

Setting Up More GA4 Tags

This tag starts Google Analytics for your GA4 site on a particular page. It determines things like common settings, GA cookies, and sends various automatic and enhanced measurement events.

If you place the configuration tag at the top of the page, it will trigger first before event tags. In GA4, event tags will override configuration tags with the same name, but only for the event at hand. Configuration tab parameter values will be reflected in other tags.

Events with Parameters

For best results, Google recommends using recommended event names when adding events with parameters.

Once you have configured settings for a particular parameter, simply repeat the process for all the others by going to Event Parameters >> Add Row >> Enter parameter name >> Enter a value.

Tracking User Properties

In GA4, you can track user properties such as nationality, gender, height, and profession.

Go to Tag Manager and see which properties you are already tracking
Go to Create first user property. Add a description and click Create.
If you need to add more properties, click New User Property
Tell GA4 to accept the new parameters by going to GTM >> GA Configuration Event. Then click User Properties >> Add row.
Copy all the names you created in GTM
Paste them into the Property Name section
Copy your GTM data layer in the Value field
Go to GTM and enter Preview mode to check that you’re tracking the right activity. Go to Debugger to check everything is being tracked properly.

Go to Tag Manager and see which properties you are already tracking
Go to Create first user property. Add a description and click Create.
If you need to add more properties, click New User Property
Tell GA4 to accept the new parameters by going to GTM >> GA Configuration Event. Then click User Properties >> Add row.
Copy all the names you created in GTM
Paste them into the Property Name section
Copy your GTM data layer in the Value field
Go to GTM and enter Preview mode to check that you’re tracking the right activity. Go to Debugger to check everything is being tracked properly.

Modifying the Data on the Server Side

It is important to check which parameters the existing event uses, and decide how you want to change them before you begin modifying the event data on the server side.

On the server side, modify event data as follows:

Click Configure >> Events
Click Modify Event
Select the relevant data stream if the property has more than one
Click Create
A form will then present you with some fields. In the Modification name, enter a description of the change you want to make. In the Matching conditions “Value” field, enter the event you want to change.
Add extra conditions to trigger the modified event with Add condition
Use Modify parameters to choose what changes you want to make.
Click Save

Server-side handling of limited clients

Since these tools are so new, the number of clients on the server side is currently limited. However, the community is already building out the infrastructure, making more options available.

If you’re stuck, you can create your own clients. However, you’ll need reasonable knowledge of JavaScript and Client Template APIs.

Making the move to production

While staying in the testing environment for Google Cloud is fine, your website will eventually go live and you’ll need to apply the concepts learned here.

Production Requirements

Moving to production requires the following steps:

Publish GTM changes in both containers, the web and the server. The web container will start sending data to the server-side container, which, in turn, will begin forwarding it to GA.
Make sure you comply with GDPR/CCPA. However, you should also ensure compliance with various data protection laws. Current laws concentrate on consent, not technology, so always give users a choice.
Be prepared for serious debugging. You should always have access to the server-side container so you can see exactly what’s happening. Debugging operations may become more complicated when you go into production. Without proper container access, pitching to new clients may be difficult.

Google Cloud Platform: Creating Production Servers

You can use the GTM server-side container for free, but if you want to run a live website with heavy traffic, you’ll need somewhere to host your container. And that means using a service like Google Cloud Platform. Depending on how much you process, the service will cost more. Prices start around $40.

In Google Cloud Platform, you can either automatically get a new server for your container, or manually create one. The easiest option is to choose automatic creation and let Google handle it for you.

If you’re new to Google, you’ll need to create a billing account. Click Create a billing account and fill out the requested fields.

As soon as your Google account has been created, you will see a button to select your billing account and create a server. Once that has been done, you should see all the information about your new server, including its ID, default URL, and so forth. Click it and wait for Google to set it up.

Creating a custom domain

All the requests you send to the server side will be in first-party context if you create your own custom domain.

To do this:

Go to Google Cloud Console
Choose the project you want to work on by clicking the Project drop-down at the top of the screen.
Make sure that the ALL tab is enabled to see your GTM project
Click the relevant project.
Go to App Engine >> Settings >> Custom domains tab
Click Add Custom Domain
Choose the custom domain that you want to use from the drop-down menu. If you want to add a new one, you have the option to do so.
Click Verify (and add the codeverification to your domain Google gives you)
Once you’ve done that, click Continue after the success message
Check your subdomains and click Save
In Update your DNS records to enable security, add 8 DNS records. (You can access this from your web server provider)
Set the new default URL by going to Google Server-Side Container Tag Manager Admin>> Container settings >> Tagging server URL. Then enter the new URL. Make sure that it does not end in “/” and that it includes the “HTTPS” prefix.
To update the transport URL, go to Tag Manager>> Clients>>GA Settings Variable and then type the new URL in the box.