Google tag manager server-side: How to set up server Tag Manager, Universal Analytics, GA4, and Facebook conversion API

Server-side tagging has been one of the main trends in web analytics for the last couple of years. Ad blockers, Intelligent Tracking Protection, 3rd party cookie restrictions, regulations like GDPR made analytics and advertising companies start worrying about how and what information they collect about site visitors. Server-side tagging allows moving third-party tags off your site and into a cloud server. In this case, third-party pixels are loaded directly from the could server rather than your site. 

In this article, I will explain and demonstrate the basics of setting up Google Tag Manager server container, server Universal Analytics, GA4, and Facebook Conversion API.

Why use server-side tagging?Copy link to this section

One of the first companies that started to talk about server-side tagging was Facebook. They announce a new method of tracking users in 2018. And in 2021, they renamed it to Facebook Conversion API and said that all FB advertisers should implement FB CAPI, making it almost mandatory.

The logic behind the Facebook conversion API is very similar to offline events: you push information about a user (email, name, phone number, etc.) and event data (such as click ID, event name, event id, etc.) to Facebook and they are trying to match a user from your site to a user in their database and assign the event to this particular user. The more information about the user and event you send to Facebook, the more likely they’ll match a user who converted on your site to a user in their database. Inside the FB events manager, you can see your event match quality. Event Match Quality has the highest rate of 10 and shows the effectiveness of the user information sent from your server in matching events to a Facebook account. High event match quality might have a positive impact on your ad performance and attribution.  

Though Facebook Conversion API is highly recommended (because of iOS 14 restrictions, ITPs, and ad blockers), you can still use browser tagging. There are several methods of setting up Facebook tracking:

1) Browser. If you are using only browser methods, most likely, Facebook will underreport events. Some researches show that around 80% of people are using Facebook only on mobile devices. iOS market share is approximately 30%. According to FB internal estimations, fewer than 20% of Facebook iOS users will allow tracking. In the end, your Facebook pixel will miss events data for around 16% of your site users. But of course, this number will vary based on your country, target audience, and product. 

2) Combined Browser + Server. This method has two sub-methods. 

     2.1) track all events both in the browser and on the server. This way, you can secure yourself from losing data about your clients. But for this method, you’ll need to set up deduplication. Otherwise, events will be tracked twice. Data won’t be accurate, and you’ll see an error inside the events manager on Facebook.

     2.2) Track some events in the browser and other events on the server. If you were using Shopify native Facebook app for conversion tracking and switched to the maximum data sharing, Facebook will track the Purchase event from the server and other events in the browser.

3)  Server. In this case, all events will be tracked from the server. It will help to collect data about all users and increase the page speed. With server tracking, it’s essential to send as many user data and event parameters as possible. All private information about your user that you send to Facebook should be hashed.

In 2020, Google released a new version of Google Tag Manager – server container. The logic behind server containers utterly different from what we used to have inside the web container. Besides that, Google added a new object to the server container – it’s called Client. 

Another big difference between web and server containers is that the server container is not free. If you use Google Cloud Platform, most likely, you’ll pay a minimum of $120/month. There is an option to set up a test container for free using one server. But Google recommends using a minimum of 3 servers to reduce the risk of data loss (each server costs around $40), but of course, you may choose to run fewer (or more) servers. 

Bear in mind that you cannot move all tracking pixels to a server-side. For example, LinkedIn and Twitter do not support server-side tagging yet. At the same time, you can move Facebook, Universal analytics, GA4, Snapchat, Bing, Reddit, Pinterest, Yandex, Klaviyo (and some other email platforms) to a server-side tagging. 

All these changes in Google’s and Facebook tracking infrastructure prove that the world of tracking will change in a couple of years, and server-side tagging might become a new standard of tracking user behavior. 

But what about the advantages of server-side tagging? Why should you move from web to server tagging?Copy link to this section

Before we start talking about server-side, also known as SS, tagging advantages, I want to say that server-side tagging is a new technology, so I do not recommend moving to SS tagging straight away. Try combining web and server tagging first. Once you’ve compared web and server tagging data and verified that server-side tagging works correctly, you can stop web tags and continue using only the server. The reason behind that is that server tagging is more complicated than web tagging, and it will take you the same time to get used to the new logic. In the bigging you set up might not work correctly. Another reason is that Google’s server-side tagging is too young, and there might be some bugs that we have not yet discovered.  

Main benefits of server-side tagging:Copy link to this section

1. First, the most important reason for implementing SS tagging is more accurate user tracking. With SS Facebook and Google Analytics, you will have more accurate data since tracking pixels won’t be blocked by ITPs’ Adblockers and other tracking restrictions. 

2. Cookie lifetime extension in Safari (and other browsers that use Intelligent Tracking Prevention). We all used that Google Analytics cookie lifetime is two years. But starting from 2020, Safari decreased cookie lifetime to 7 days (and in some cases, only 24 hours). It means that if a user is not revisiting your site every seven days, they will be considered new. Decreased cookie lifetime might have a significant impact on your analytics data. Let’s say a user on Safari saw your ad in Google AdWords, clicked on it, and then returned to the site after seven days and made a purchase. In this case, Analytics will attribute a conversion to the direct/none traffic source. It means that you won’t be able to correctly calculate ROAS for your PPC campaigns and make propper decisions while optimizing your AdWords account. 

3. Better page speed. Site speed will be improved because tracking scripts won’t be loaded in a user browser. From my experience, one of the heaviest scripts is Facebook. If a site works with an advertising agency, they might have several Facebook scripts on their site. The good thing that you can fully move Facebook tacking to a server-side.

4. Enrich data about your users. With the help of server-side tagging, you can push data from your CRM (like phone orders, upsells, etc.) to Google Analytics or any other analytic tool that supports SS tagging.

How to set up server-side tagging on your site?Copy link to this section

I will divide this guide into four parts:

• Creating Google Tag Manager server container 

• Adding a custom domain

• Setting up Universal Analytics or Google Analytics 4 server-side

• Setting up Facebook Conversion API.

1. Set up Google Tag Manager Server container.Copy link to this section

1.1 Login to your Google Tag Manager account and create a server container. To do that, go to the Admin setting -> Click + under containers –> add container name -> choose server -> click create -> select “Manually provision tagging server” -> copy container config that you will see in the pop-up. 

1.2 Create or log in to your account in our service -> click “create container” -> paste container config that you’ve copied from the Google Tag Manager -> click create the container. It will take up to 10 minutes to set up your container. Please refresh the page in a couple of minutes. If the setup were successful, the status of the container would be “Running”. 

2. Create and Add custom tagging URL.Copy link to this section

2.1 Select a subdomain that you want to use as a tagging server URL. I recommend that you use something that doesn’t have to deal with tracking, analytics, gtm, etc. The reason behind that is that some AdBlockers started to block all requests that come from the URL that includes any keyword that relates to user tracking. For example, if you’ll use gtm.yoursite.com, requests might be blocked because they will see gtm inside your URL. So, you can do something like tgurl.yoursite.com or ss.yoursite.com or anything that comes to your mind. 

2.2 To set up a custom URL for the Google Tag Manager server container, you need to update A record for your subdomain. In this guide, I will cover how to do it inside Cloudflare.Login inside your Cloudflare account -> choose the domain -> click DNS -> Add record.Settings should look like this:

Type: A

Name: ss (or any other subdomain you prefer)

IPv4 address: IP address depends on the location of the servers. You can find the custom domain IP address in your stape.io account.

TTL: AutoProxy status: disable

Once done, click Save.

2.3 Update tagging URL inside our service. Click setting and add a custom domain that you’ve created. Note that it might take up to 72 hours for some registrators to set up a subdomain. Once the domain is set up and running, the status of the container in our service will be running. 

2.4 Go to the admin setting of your Google Tag Manage server container and update tagging server URL. Update Google Tag Manager code on your site. Change the highlighted domain name to the subdomain of your tagging URL for both the gtm.js script and ns.html file:

2.5 Add transport URL to the Universal Analytics or Google Analytics 4 tag inside the Google Tag Manager WEB container. You can do that either by adding the transport URL to the Universal Analytics variable that you are using inside the WEB container or by adding it to the UA tag under advanced configuration.

2.6 To update tagging URL inside Google Analytics 4, you need to add these records to the fields to set. 

field name: transport_url

value: your tagging URL

3. Setting up Universal Analytics or GA4 server-side.Copy link to this section

3.1 Go to your Google Tag Manager Server container. Click Clients and add Universal Analytics or Google Analytics 4 client.

3.2 Create Universal Analytics or GA4 tags inside the server container. Go to tags -> click add New -> choose UA or GA4.

3.3 Create triggers for the tags that you’ve created in the previous step. For the UA tag, the trigger should be client name equals Universal Analytics. And for GA4 trigger should be client name equals GA4.

3.4 Open debug mode of the Google Tag Manager server container and verify that UA or GA4 works from the server. Note that the server debugger takes longer than the web to update. To doublecheck the setup, open consol and check Google analytics requests. Once everything is set up, don’t forget to publish changes.

4. Setting up Facebook conversion APICopy link to this section

4.1 Add Facebook tag template from the Template Gallery.

4.2 Create Facebook tag inside Google Tag Manager server container -> Add your Facebook pixel ID and Facebook API access token. (you can find your FB API access token this way).

4.3 Our custom tag has two options for setting up Facebook CAPI: inherit from GA client and override. Inherit from GA client will match UA events to Facebook events (to standard events if possible, if not, then record as custom events). For inheriting the setting, the trigger should be client name equals Universal Analytics. The second option is to override FB events. In this case, you will need to select event names and create a trigger for each FB event you want to track. In this case, the FB pageview event should trigger the event name equals pageview.

We have a blog post that will help you to check if server-side tagging works correctly. Once everything is set up correctly, do not forget to publish all changes.

Conclusions:Copy link to this section

Server-Side tagging comes as a sustainable replacement of client-side tagging since it covers all the present and future limitations of Client-Side Tracking. But since the technology is in the early stages, you cannot entirely replace client-side tracking with server-side. However, server-side tagging seems to become a new standard for web analytics. That is why I suggest starting phasing out client-side and move to a server-side.