What Is Server Side Tagging
In this guide you will learn exactly what Server Side Tagging is and how you can leverage it to power tagging and event tracking for your business.
First, let’s get squared away on technicalities and nomenclature:
- A “channel” is equivalent to Facebook or AdWords and is also known as a “third party vendor”.
- And that cookie is typically responsible for sending data back to the channel platform to help in identifying the user, mapping back to an advertising campaign, and building a profile for audience management, etc.
- But browsers – like Safari – ultimately control the behavior of these cookies.
- …like setting a max expiration date of 7 days instead of whatever the third party vendor wants to set it to.
- …for example: view content, add to cart, and purchases are all considered “conversions”.
- And they require a unique event tracking setup on your website.
- The conversions typically require user parameters so the channel can map the conversion back to a campaign.
- Your legal compliance guides what user data you are able to send with your conversions based on consent status of the user on your website…
- …so if a user opts-out of being tracked (think CCPA, GDPR), then this limits the data you are legally allowed to collect and send to your third party channels. Here’s an overview on this concept with Google’s Marketing Platform.
A few quick definitions:
- “Client” is sometimes referred to as browser (e.g. “client side” vs “server side”). But there is a new feature in GTM SS container called “Clients”. These are *not* the same.
- Apple ITP generally refers to the browser-led constraints being put on 3rd party tracking.
- “1st Party” vs “3rd Party”: 1st party data is generated by your own server/domain. 3rd party data is generated by external sources. Facebook script generating cookies and setting on your domain is still 3rd party and has 7 day cookie expiration (on Safari or other browsers using Webkit)
What Are The Benefits to Server Side (“SS”) Tagging
Server side tagging allows you to do the following:
- Reduce the gap in conversion and user behavior data missing in your marketing & analytics platforms like Facebook and Google Analytics by:
- Implementing API based conversion tracking instead of sending conversions through the browser
- Proxying third party channel scripts from your server instead of the browser so all of your tracking is done in 1st party context (e.g. yourdomain.com).
- Improve personalization of user experiences on your website and marketing campaigns by:
- Maintaining a longer cookie expiration period (i.e. instead of 7 days, 90+ days) so users are more likely to see a marketing campaign you want them to vs being reset to new users more frequently
- Maintaining a/b test control vs variant user buckets by maintaining a longer cookie expiration period for tools like Google Optimize
- Improve attribution by:
- Maintaining a longer cookie expiration period (i.e. instead of 7 days, 90+ days) so campaign data from user’s browser is retained for a longer period of time
- Improve site speed by:
- Reducing the # of third party scripts (aka tags) from loading in the browser. Instead these tags are executed from your server container. In theory one data stream from your website could map to multiple tags in your server side container.
- Reducing the size of your web based GTM container by moving the complex logic of tag/trigger/variables from your web based GTM container to SS container.
What Are The Risks to Server Side Tagging
- Conversion hits lack data that vendors require
- For many third party vendors, we don’t really know what type of browser data they rely on to connect back to a user. Some – like Facebook – provide fairly detailed guidelines on parameter data they require when sending data via their API (read here for FB example). But other channels may not have these details fleshed out yet.
- The amount of browser data marketing channels are collecting from their pixels to use for remarketing is unknown to all of us. If you were to move all tracking from browser pixels to server side tags, then you will need to watch performance closely.
- Duplicate conversion data
- If you decide to run a pixel in parallel with server side conversions then it’s critical to ensure data is not duplicated. Some channels – like Facebook – provide very clear instructions on how to use both in parallel so they can deduplicate themselves. Others – like Google Analytics – do not provide this deduplication.
- Privacy/Consent legal obligations not followed
- Moving tagging to a server to server process does not remove the requirement for you to manage user consent and privacy regulations that you have to adhere to. Many of the solutions that you see today (the cookie popup modals) don’t automatically connect with your SS container.
- You “Set it and forget it”
- This type of integration via Google Tag Manager is very new. Plus the speed at which browsers and privacy regulations are changing, it’s very likely that you will need to be making adjustments to your tagging process after it’s been set up for the first time.
- Generally speaking we believe that server side tagging is more reliable/less prone to issues when compared to browsers. However if you don’t have a way to automate the monitoring of SS tagging: 1) checking for errors coming from your website OR 2) responses back from the APIs you are integrating with, you could risk errors going unnoticed.
- Too technical to troubleshoot yourself
- The benefits are clear for server side tagging. And this is the future for all of your marketing tags – there is no doubt about this. However this is much more technical than your standard tagging in Google Tag Manager. If you are on your own then be sure you have a solid understanding of how to test, troubleshoot, and fix your tag setup inside of the server side container.
How Server Side Tagging Works
Here is a quick overview on how server side tagging works with the GTM SS container.
First the server part:
- When you create your server side container inside of Google Tag Manager you are creating a real server inside your Google account. Yes, a real server. It’s a server instance (also known as App Engine) in Google Cloud.
- Google automatically creates this server for you on the setup and installs the Google Tag Manager server side container for you.
- Google will give you a default URL like https://gtm-iv27m2d-nzfgim.uc.r.appspot.com, but part of the setup process is to use your own URL. Like “collect.getelevar.com”. We recommend making your subdomain unique and not something generic like “collect.getelevar.com”.
- You get data to your server by sending requests to your server URL.
Now the data part:
- You send data from your website to your server. This is where your SS GTM container exists.
- Inside the SS container you process this data and transform so it can be used in tags that you trigger in a similar format as your existing GTM website container
- When your tags are triggered inside the SS container then they send the hit (like a purchase) to your tag destination (like Facebook) by connecting to your destination API (like Facebook Conversion API)
- The destination then sends a response back to your server (the conversion hit was successful!).
- (optionally) Your server sends a response back to the user browser
Here it is visually:
Here is the fine print:
- You can send any data you want to your GTM SS container, like:
- Data from users browsing your website
- Data directly from your Shopify admin
- Data from your brick & mortar stores
- Data from your CRM
- There are multiple ways you can send data from your website to your SS container:
- Using your existing GTM web container
- Using hard coded scripts or pixels that follow Google’s measurement protocol syntax
- One of the primary differences between your web based GTM container and your SS container is that you need to translate the data sent into your SS container before it can be used by a new feature called “Clients”.
- Google has 2 pre-defined Clients – Universal Analytics and App+Web – that will automatically translate the data sent for you if it’s in Google’s format.
- Google’s format is known as the “Measurement Protocol”.
- There is v1 which is Universal Analytics and v2 which is App+Web. App+Web is their new Google Analytics property type they released in July 2019.
How Server Side Tagging Works For Marketing Channels
Each channel is going to be unique in how they collect and process data coming server side (aka “API”).
Lets focus on Facebook first.
Facebook has a “pixel” that you install on your website that collects various data about the user and their interaction on your website.
Facebook relies on:
- Data from their pixel to track the user and their activity, etc
- Data from conversions to track ad performance, etc
These are not necessarily the same.
Facebook allows you to run your FB pixel in parallel with their Conversion API. So both sources of data are sent back to your FB business manager:
And when it comes to server side tagging for Facebook, there are two big ideas to consider:
- Controlling the cookie set by the pixel. So instead of allowing the browser (like Safari) to enforce 7 day cookie expiration, your server resets this to whatever length you want.
- Managing the conversions that happen on your website. It’s not uncommon for most FB accounts to miss ~ 10-20% of conversions due to issues that happen within the browser, AdBlockers, etc. Utilizing the Facebook Conversion API can remove this friction point in your tracking process (again – not by working around user consent, but along with it).
So when you learn more about Facebook “Server Side Tagging” be sure you’re considering these two points.
Continue to part 2 of this guide: How to Create Your Server Side Container in Google Tag Manager.