Background
The core technical idea of the server-side GTM is about changing the location from which event data is disseminated to various marketing and analytics tools. Specifically, with server-side GTM, you relocate this data distribution process from the user's device to a dedicated tagging server. Data collection about a user's interactions still originates on the user's device. This shift introduces a fundamental change in how existing tagging strategies must be approached.
The conventional client-side tagging setup typically has one tag per interaction and vendor:
.png)
The introduction of server-side GTM will split this up into:
Client-side GTM: Focuses on the collection of interaction data from users on your website or application. This typically results in one tag per type of user interaction in the client-side GTM.
Server-side GTM: Focuses on the distribution of interaction data to the relevant destinations (e.g., Facebook, Google Analytics, etc.). This typically results in one tag per destination tool in the server-side gTM.
.png)
This change implies that there is one central data stream that you feed into the server-side GTM. Based on this central data stream, you will feed all downstream vendors. Typically, this will be Google Analytics because it’s the most complete. Additionally, it’s the most native to the server-side GTM and therefore unlocks many GTM features that other data streams do not.
Migration Process to Server-Side GTM
General Rollout Plan
Before making the switch to server-side tagging, it's best practice to set up a dedicated testing environment. Start by creating a new test property in Google Analytics. Next, duplicate your existing measurement stream in your client-side GTM container. This allows you to safely work out any potential issues without impacting your production data. Furthermore, keeping the original stream running side-by-side will give you valuable insight into the uplift that server-side tagging provides, as you'll have a direct benchmark to compare against before the full migration.
Once your test setup is ready, you'll need to change the server_container_url for your events. If you haven't already set up your server-side GTM, make sure to follow the steps in our Get started with Server-Side Tracking guide first.
After deploying the test setup, the next step is to keep it running next to your production setup for a couple of weeks—2 at the very least. Then compare your production and test properties. While the specific tests will vary based on your setup and business requirements, there are some general high-level figures that make sense to check. Look at the user/session count. This number can help manage internal expectations regarding traffic uplift when integrating a new vendor into server-side GTM. Also, compare the count of events per event name and the distribution of acquisition channels.
If all your tests are looking good and the data aligns as expected, you can then delete the temporary test stream. The final step is to change your production stream to use the server GTM endpoint.
Expected Challenges
Pre-Launch: Inflated Expectations
One common motivation why organizations migrate to server-side GTM is to improve the quality of data collection. This often goes hand-in-hand with the expectation that after the migration, the observed traffic will increase by up to 20%. In practice, however, it is very difficult to produce a reliable prediction about the impact on (observed) traffic. The uplift depends on many organization-specific factors like the type of browsers that your users use, their tendency to use a specific ad-blocker or even the default security-settings that a corporate-provided computer comes with.
Therefore, it’s a good idea to run the parallel implementation test as described above to create a baseline for the expected uplift.
Post-Launch: Privacy vs Data Quality Target Conflict
On a general level, the migration to server-side tagging will create a new target conflict between data quality and data privacy. On the one side most marketing vendors will expect a server-side tagging setup in addition to the existing client-side tags. That is, they want additional signals about your users in order to enrich the existing ones. On the other side, the privacy benefits from migrating to a server-side tagging setup can only be leveraged if you remove the client-side tags and use the server’s ability to remove certain pieces of information from the measurement stream before they are shared with the marketing vendor. As a general rule of thumb, you should reflect on your priorities and about what you want to get out of your server-side GTM setup. Then you know which way you need to push.
Post-Launch: New Cost Center
For many organizations, transitioning to a server-side GTM setup represents a significant shift, both mentally and with regards to budgeting. In the past, implementing client-side tagging via tools like Google Tag Manager was often perceived as a 'free' component, relying only on internal development resources and Google’s ubiquitous content delivery network. Now, the “server” part in server-side tagging means that there is a real server running exclusively on your behalf which will have costs, depending on the amount of traffic that you intend to collect with it.
This means that the adoption of a dedicated tagging server, is a new cost center that needs to be justified against the benefits of data quality, compliance, security, and performance that server-side tracking provides. Going with Usercentrics to provide the resources for your server-side GTM will help you abstract away the complexity of estimating the cost involved for running the server, its maintenance, scaling, and operational overhead. Instead, pricing comes with a flat fee based on the number of requests only (see more here).
Next steps
With a functioning central data stream established, you can now begin feeding data to other tools based on this stream. The migration of other vendors to server-side tracking should proceed as detailed in the Use cases section. It is recommended to prioritize these migrations according to the relevance of the vendor as an acquisition channel. Start with your most important channel and then work down the list.