The pros and cons of GTM server-side tagging for nonprofits
In August 2020, Google announced the introduction of Server-Side Tagging to Google Tag Manager. Analytics and measurement communities went into overdrive, and there was a great deal of speculation about what this meant given heightened awareness of privacy and cookie compliance.
In this article, we’ll explore what server-side tagging is, the positives and potential negatives for nonprofits, and what it means within the context of GDPR and cookie compliance.
What is ‘Server Side Google Tag Manager’?
Before answering this question, it’s probably good to refresh on how the ‘normal’ version of Google Tag Manager (GTM) works.
Normally the tracking that you add to your site using Google Tag Manager is injected by the Google Tag Manager web container script into your browser, and any 3rd party tracking scripts (like the Facebook pixel, or Hotjar tracking) are also added at the same time. This means that the browser is loading all of the scripts and the load is carried by your browser as a visitor when you are loading pages on the site.
GTM in its traditional form has been great for charities as it has cut out dependency on IT departments and developers to add scripts for each ad platform or analytics vendor. If you want to track, say, conversions from Facebook traffic on your website, you can set that up with (almost) no input from your IT team.
But as with all conveniences there are some trade offs, including:
- Bloat from 3rd party vendor scripts—the more tags you fire, the slower the load time of your website.
- Sprawling containers with too many tags.
- Personally identifiable information (PII) is easily (inadvertently) captured on the client side and sent in tags to Google Analytics.
How is server side tracking different?
Server side tracking with Google Tag Manager removes the need for that client side (browser) bloat, by handling tracking requests on a server instead of within the browser.
When server side tracking is enabled, and a supporter comes to your site, a hit is sent to the designated server which then starts a chain reaction between the ‘client’ on the server and the Google Analytics server (or other 3rd party vendor server.)
This means that the server acts as an intermediary between the visitor’s data and its final destination on the analytics or marketing vendor’s server.
This means that when a tag would normally be fired in the browser as part of the page load or interaction, a hit is sent by the server instead; so the browser is free to focus on loading the page rather than loading tracking code.
What are the positives for charities?
This is a positive for all third sector websites (indeed, all websites) but it might be particularly beneficial for global charities who are targeting users in developing countries where mobile internet is the main way of accessing the internet, and mobile browsing may be expensive or more limited by usage.
With the advent of GDPR and the ICO cookie guidelines, consent management has increased in significance with many organisations fearing fines and a backlash from site visitors if they are not compliant.
Consent management often requires consistent trigger conditions and often complex configurations to be effective, but Server-Side Google Tag Manager removes some of this intricacy, and brings some benefits.
Third-party services (e.g. Facebook) have no connection with the user’s browser by default. You have full ownership and control over the server-side container.
This could make consent management more straightforward, and could allow charities to be more confident about the data that is being shared with 3rd party vendors, and how it is being shared.
Server Side Tagging offers increased privacy and security because you have full ownership and control over the data sent to the server-side container.
PII leaks (e.g. via URL parameters) are in theory eradicated by the existence of a proxy server processing all of the HTTP requests.
This means that you don’t have to worry about personal information being shipped to Google Analytics automatically via query parameters, because the hits aren’t sent straight to Google Analytics from each URL, instead they are sent by the server and so query parameters can be decoupled from the URL that is sent to Google Analytics is clean.
An example of PII that can sometimes be sent to Google Analytics would be URL data that includes an email address on a confirmation page such as: www.website.com/donation/[email protected]
This is an important factor for all organisations as PII should never be sent to Google Analytics as this is against Google’s Terms of Service.
Safari ITP mitigation
What are the main drawbacks for charities?
Reliance on technical expertise
If you already thought that Google Tag Manager was a black box, then you might be forgiven for feeling more so since the release of the server side version.
It’s likely that digital teams within charities will need additional support to configure server side tracking for their needs. This might be internally from IT departments or externally from agencies or consultants.
It’s also an entirely new tracking setup process, which while it has some commonality with the traditional GTM web container, it’s akin to the transition from web to accelerated mobile pages (AMP). There are lots of limitations, and a significantly different approach from web tracking setup.
Appspot or custom domain
To configure server side GTM you need either a Google Appspot domain to point the container to, or to configure your own domain to send hits to the Google Analytics servers.
Google Appspot domains are configured via the Google Cloud Platform App Engine, and this is the most direct route to create a server-side container. These are domains that are hosted by Google and are paid for based on the number of requests made to your server.
You can also set up your server using your own custom domain, in a similar way to how you would configure a regular website domain, and point GTM to your custom domain, this is likely to require more expertise to set up but will allow you greater control over the server settings.
There are pros and cons to each approach, and organisations who are willing to take the plunge will need to weigh up each based on budget, technical expertise and any need for customisations that are not available via the Appspot domains.
Unlike regular Google Tag Manager implementations, server side tracking is not free. Dependent on whether you opt to implement using an Appspot domain or via your own domain, there will be an overhead of time and cost (if using the Google option) - some estimates predict costs of a minimum of £90/€100/$120 month, if you use the basic, three-instance Google Cloud Platform setup. This cost would be higher the more traffic your site gets (or the more event tracking you use.) So this is a serious consideration if you want to use server side tracking and don’t have support to configure this on your own custom domain.
Server-Side Google Tag Manager is an exciting prospect; it presents new opportunities to improve the way we manage and deliver tracking, and will help us to overcome some of the common issues that we face on a regular basis.
Improvements in page load speed could have a tangible impact on user experience, and help to reduce some of the lag that users experience when loading tag heavy websites on mobile devices. Some data protection issues that would have become apparent in Google Analytics will disappear from view - this is good in terms of complying with Google Analytics terms of service, but not so great for spotting the leaky parts of a website.
Cost and technical expertise may well be a barrier to entry for many organisations, but Server-Side Google Tag Manager could be a great fit for organisations who have in-house tech marketing experts, and a greater focus on cookie and data management.
Get in touch to talk about your project
We like to meet. Early on. It’s the best way to work out whether we are a fit.
De-risk your project
We can remove the barriers to getting your project going. Ask us how we do this.
If you’ve got a brief, we’d love to see it. If you haven’t, talk to us before you write it, we can help.