Menu
Server-Side Tagging with Google Tag Manager: What Marketers and Developers Need to Know
Discover how server-side tagging in Google Tag Manager can enhance privacy, data control, and performance—while keeping costs in check. A practical guide with key considerations for implementation.
Ricardo Cristofolini
Senior Implementation Specialist, Data Solutions
I’m passionate about what I do. If you meet my manager or co-workers, they would say I’m a team player, engaged and always excited to learn something new. Like everyone else I have some flaws. However I’m not afraid to work around those to bring the best in myself and for the company
Why Server-Side Tagging Matters in 2025
As privacy regulations tighten and marketers demand more accurate, secure data collection, server-side tagging has become a critical solution. While many teams still rely on traditional client-side tracking, forward-thinking organizations are shifting to server-side tagging with Google Tag Manager (GTM) to improve site performance, strengthen privacy controls, and regain control over their analytics stack.
In this guide, we break down the essentials of server-side GTM: what it is, how it works, why it matters, and what to consider before implementing it.
What does Server-side tagging (sgtm) mean?
Server-side tagging for GTM is not something new and while a lot of companies are already driving their implementation towards server-side, some are still dealing with a better understanding of what that is, how it works, benefits it can bring, costs, and much more.
In a nutshell, server-side tagging, just like the client-side, is a way to measure a user’s activity wherever it happens but with a server that is controlled by the client’s developer’s team.
Source: https://developers.google.com/tag-platform/tag-manager/server-side
This approach provides new tools that will allow you to:
Improve page performance
Unlock more detailed user privacy controls
Improve data quality
Improve data control
Server-side Tagging
How Server-Side Tagging Works
There are two primary ways to use server-side GTM:
Proxy Setup: Send data from your client-side GTM container to the server-side GTM container, which then routes it to GA4, ad platforms, and other tools.
Direct Setup: Trigger tracking events directly from your website to the server container, bypassing the client-side container entirely.
While this guide doesn’t walk through implementation step-by-step, it focuses on practical tips and strategic considerations to help you make informed decisions.
First Steps - Setting Up Server-Side GTM
To create a server-side GTM container, you can follow the same process as a client-side container:
Once you have that container created, you will also have to create an account in Google Cloud to connect both. You have - among others - the following three options to do this:
Set up a project in Google Cloud Platform
Choose your hosting option (Cloud Run, App Engine, or Manual Setup)
Connect your GTM container to your cloud project
Once you have properly configured Google Cloud, the main difference you will notice in the container is the following two menu options:
Clients
The Clients menu is your main source of information. Anything that comes from your site and/or client-side GTM has to be claimed by a client. That can be a:
Google Analytics: GA4 (App)
Google Analytics: GA4 (Web)
Google Analytics: Universal Analytics (deprecated)
Google Tag Manager: Web Container
Measurement Protocol
Measurement Protocol (GA4)
The type of client you create will depend on your objective when tracking data.
You can also build custom Client templates if you are experienced with JavaScript coding using Google Tag Manager’s sandboxed JS, and APIs, but you don’t need to enable tracking in your server-side container, you can reuse the GA4 client for other vendor tags.
Transformations
The Transformations menu allows you to modify the event data accessed by tags before execution and map that parameter/dimension to whatever destination you want or to all of them (e.g. in case you want to hide the IP address from ALL destinations, you can configure it a single time).
Key Implementation Considerations
Unlike client-side tagging, the server-side gives you a whole new opportunity to have control over your data. That means you can modify each parameter that comes through the hit BEFORE it gets sent anywhere. This also implies more work for whoever is working with server-side GTM because now you have to consider each parameter that will be passed in exchange for data security and control.
Furthermore, the client-side triggers were based on Data Layer events or custom data clicks (IDs and/or Class in HTML attribution). On the server side, triggers will be based on the event that is being passed from a specific tag.
👉 Example:
Let’s say you have a Data Layer push where the event name is ga4Event_view_item. That same event will be used in the client-side GTM to trigger a view_item tag. However, in the tag, the event configured is view_item (for ecommerce purposes and to work in GA4). Now, if you have server-side GTM implemented, and you want a tag to fire on the server side that sends data to a third-party vendor, which event name should you use?
ga4Event_view_itemorview_item
Kudos if you replied view_item. Since the triggers on the server side are based on the event that the hit is passing, ga4Event_view_item would never reach the server side if not properly configured.
Privacy Considerations
Aside from the requests being sent to the server side, claim clients, transformations and where the data is going, server-side GTM provides a more robust environment privacy-wise since you are the owner of the data being tracked and control 100% of where the data is going. It’s important to highlight that this control does not happen automatically. By default, everything is being passed everywhere when a client claims an incoming hit, so it’s up to you (or your dev team) to properly configure what is going where. In other words, if you don’t control the data and take into account privacy (as well), it defeats the purpose of using server-side GTM and can put you at risk of being non-compliant under privacy regulations that apply to your business.
To comply with regulations like GDPR, CPRA, and Law 25 in Québec:
Implement clear rules for what data is shared with which vendors
Leverage transformations to anonymize or filter sensitive information
Work closely with legal/privacy teams to define appropriate data flows
Costs to Consider
When it comes to costs, the main thing you have to keep in mind is that, when dealing with server-side GTM, all the computation needs to happen somewhere and, in this case, it’s in Google Servers. Yes, you still have control over your data, but that data needs to be processed somewhere.
When you configure your server-side tagging endpoint with the automatic provisioning option, Tag Manager:
Creates a Google Cloud project for you
Set up a server running on Cloud Run infrastructure
NOTE: These Cloud Run deployment settings are intended for testing and setting up your server container. That means while proofing the setup, you will most likely stay within the free usage limits.
Now, the cost structure of a Cloud Run setup with server-side tagging depends on how much computation power and storage you need, and how much network traffic gets generated.
You can use the Google Cloud pricing calculator to estimate your monthly billing charges, but this can be difficult to use, especially because a typical website will have traffic fluctuation which might impact all three of the cost types listed above.
To roughly estimate your costs with a Cloud Run deployment, you need to look at these factors:
Cost type | Impact on billing | Notes |
Computation (instances) | High – fixed | Your minimum cost is the minimum number of instances you configured multiplied with the cost per server. To account for scaling your servers and getting a more realistic price range: Multiply the maximum instances you've configured with the cost per server. The price is approximately USD 50 per instance per month. |
Network (egress) | Moderate – fluctuates | Egress is calculated for all outgoing network data from the server container. This includes requests dispatched by your clients and tags and HTTP responses from the server container back to the user's browser. Network egress can become a cost factor if your server-side tagging endpoint serves larger resources or JavaScript libraries. |
Storage (logs) | Varies | Once you collect enough requests to surpass the free tier of Cloud Logging, the cost of storing logs can become substantial. To lower logging cost, filter out the incoming requests or to include only a sample of log entries. |
Alternatively, you can follow your Google Cloud Platform Billing reports closely, set appropriate budgets, and cooperate with your organization's DevOps team to figure out the best approach to scaling up your server-side tagging environment.
Best Practice: Consolidate Event Requests
To get the full benefit out of server-side tagging, you'll likely want to make sure that you are able to keep costs as low as possible and keep resources on the client side as light as possible, while not losing any data along the way.
By moving as many of your client-side resources as Google Analytics, Meta, and Pinterest into the client container, you can improve page performance in that you're minimizing the number of client-side requests and libraries that need to be loaded and triggered on the page. In doing this, if we were to send an individual request off to our server container for each tag migrated to the server side we'd incur significant costs on egress traffic, scaling, and logging.
Instead, by consolidating the various data points needed for all tagging that needs to trigger on a given event into a single request payload to your server container, you can minimize egress traffic back to the browser, reduce scaling needs, and limit logging.
To keep both your costs and server footprint lean - without sacrificing data fidelity:
Bundle data needed by all tags into a single event request
Trigger all relevant server-side tags from that one hit
Reduce log size, bandwidth, and compute time
Is Server-Side Tagging Worth It?
For businesses prioritizing privacy, control, and performance, server-side tagging is more than a technical upgrade—it’s a strategic advantage. While setup and maintenance require more upfront investment, the long-term benefits include faster pages, improved compliance, and better data integrity.
Ready to explore server-side tagging but unsure where to start? At Napkyn, we help organizations assess readiness, build scalable GTM infrastructures, and navigate privacy requirements with confidence. Talk to our Implementation Experts today.
More Insights
Server-Side Tagging with Google Tag Manager: What Marketers and Developers Need to Know
Ricardo Cristofolini
Senior Implementation Specialist, Data Solutions
May 28, 2025
Read More
Declutter Your GTM: A Practical Guide to Cleaning Up Tags, Triggers, and Variables
Ricardo Cristofolini
Senior Implementation Specialist, Data Solutions
May 21, 2025
Read More
Is Your Website Violating California Invasion of Privacy Act (CIPA) ?
Rob English
Lead Implementation Specialist
May 14, 2025
Read More
More Insights
Sign Up For Our Newsletter
Napkyn Inc.
204-78 George Street, Ottawa, Ontario, K1N 5W1, Canada
Napkyn US
6 East 32nd Street, 9th Floor, New York, NY 10016, USA
212-247-0800 | info@napkyn.com
Server-Side Tagging with Google Tag Manager: What Marketers and Developers Need to Know
Discover how server-side tagging in Google Tag Manager can enhance privacy, data control, and performance—while keeping costs in check. A practical guide with key considerations for implementation.
Ricardo Cristofolini
Senior Implementation Specialist, Data Solutions
I’m passionate about what I do. If you meet my manager or co-workers, they would say I’m a team player, engaged and always excited to learn something new. Like everyone else I have some flaws. However I’m not afraid to work around those to bring the best in myself and for the company
Why Server-Side Tagging Matters in 2025
As privacy regulations tighten and marketers demand more accurate, secure data collection, server-side tagging has become a critical solution. While many teams still rely on traditional client-side tracking, forward-thinking organizations are shifting to server-side tagging with Google Tag Manager (GTM) to improve site performance, strengthen privacy controls, and regain control over their analytics stack.
In this guide, we break down the essentials of server-side GTM: what it is, how it works, why it matters, and what to consider before implementing it.
What does Server-side tagging (sgtm) mean?
Server-side tagging for GTM is not something new and while a lot of companies are already driving their implementation towards server-side, some are still dealing with a better understanding of what that is, how it works, benefits it can bring, costs, and much more.
In a nutshell, server-side tagging, just like the client-side, is a way to measure a user’s activity wherever it happens but with a server that is controlled by the client’s developer’s team.
Source: https://developers.google.com/tag-platform/tag-manager/server-side
This approach provides new tools that will allow you to:
Improve page performance
Unlock more detailed user privacy controls
Improve data quality
Improve data control
Server-side Tagging
How Server-Side Tagging Works
There are two primary ways to use server-side GTM:
Proxy Setup: Send data from your client-side GTM container to the server-side GTM container, which then routes it to GA4, ad platforms, and other tools.
Direct Setup: Trigger tracking events directly from your website to the server container, bypassing the client-side container entirely.
While this guide doesn’t walk through implementation step-by-step, it focuses on practical tips and strategic considerations to help you make informed decisions.
First Steps - Setting Up Server-Side GTM
To create a server-side GTM container, you can follow the same process as a client-side container:
Once you have that container created, you will also have to create an account in Google Cloud to connect both. You have - among others - the following three options to do this:
Set up a project in Google Cloud Platform
Choose your hosting option (Cloud Run, App Engine, or Manual Setup)
Connect your GTM container to your cloud project
Once you have properly configured Google Cloud, the main difference you will notice in the container is the following two menu options:
Clients
The Clients menu is your main source of information. Anything that comes from your site and/or client-side GTM has to be claimed by a client. That can be a:
Google Analytics: GA4 (App)
Google Analytics: GA4 (Web)
Google Analytics: Universal Analytics (deprecated)
Google Tag Manager: Web Container
Measurement Protocol
Measurement Protocol (GA4)
The type of client you create will depend on your objective when tracking data.
You can also build custom Client templates if you are experienced with JavaScript coding using Google Tag Manager’s sandboxed JS, and APIs, but you don’t need to enable tracking in your server-side container, you can reuse the GA4 client for other vendor tags.
Transformations
The Transformations menu allows you to modify the event data accessed by tags before execution and map that parameter/dimension to whatever destination you want or to all of them (e.g. in case you want to hide the IP address from ALL destinations, you can configure it a single time).
Key Implementation Considerations
Unlike client-side tagging, the server-side gives you a whole new opportunity to have control over your data. That means you can modify each parameter that comes through the hit BEFORE it gets sent anywhere. This also implies more work for whoever is working with server-side GTM because now you have to consider each parameter that will be passed in exchange for data security and control.
Furthermore, the client-side triggers were based on Data Layer events or custom data clicks (IDs and/or Class in HTML attribution). On the server side, triggers will be based on the event that is being passed from a specific tag.
👉 Example:
Let’s say you have a Data Layer push where the event name is ga4Event_view_item. That same event will be used in the client-side GTM to trigger a view_item tag. However, in the tag, the event configured is view_item (for ecommerce purposes and to work in GA4). Now, if you have server-side GTM implemented, and you want a tag to fire on the server side that sends data to a third-party vendor, which event name should you use?
ga4Event_view_itemorview_item
Kudos if you replied view_item. Since the triggers on the server side are based on the event that the hit is passing, ga4Event_view_item would never reach the server side if not properly configured.
Privacy Considerations
Aside from the requests being sent to the server side, claim clients, transformations and where the data is going, server-side GTM provides a more robust environment privacy-wise since you are the owner of the data being tracked and control 100% of where the data is going. It’s important to highlight that this control does not happen automatically. By default, everything is being passed everywhere when a client claims an incoming hit, so it’s up to you (or your dev team) to properly configure what is going where. In other words, if you don’t control the data and take into account privacy (as well), it defeats the purpose of using server-side GTM and can put you at risk of being non-compliant under privacy regulations that apply to your business.
To comply with regulations like GDPR, CPRA, and Law 25 in Québec:
Implement clear rules for what data is shared with which vendors
Leverage transformations to anonymize or filter sensitive information
Work closely with legal/privacy teams to define appropriate data flows
Costs to Consider
When it comes to costs, the main thing you have to keep in mind is that, when dealing with server-side GTM, all the computation needs to happen somewhere and, in this case, it’s in Google Servers. Yes, you still have control over your data, but that data needs to be processed somewhere.
When you configure your server-side tagging endpoint with the automatic provisioning option, Tag Manager:
Creates a Google Cloud project for you
Set up a server running on Cloud Run infrastructure
NOTE: These Cloud Run deployment settings are intended for testing and setting up your server container. That means while proofing the setup, you will most likely stay within the free usage limits.
Now, the cost structure of a Cloud Run setup with server-side tagging depends on how much computation power and storage you need, and how much network traffic gets generated.
You can use the Google Cloud pricing calculator to estimate your monthly billing charges, but this can be difficult to use, especially because a typical website will have traffic fluctuation which might impact all three of the cost types listed above.
To roughly estimate your costs with a Cloud Run deployment, you need to look at these factors:
Cost type | Impact on billing | Notes |
Computation (instances) | High – fixed | Your minimum cost is the minimum number of instances you configured multiplied with the cost per server. To account for scaling your servers and getting a more realistic price range: Multiply the maximum instances you've configured with the cost per server. The price is approximately USD 50 per instance per month. |
Network (egress) | Moderate – fluctuates | Egress is calculated for all outgoing network data from the server container. This includes requests dispatched by your clients and tags and HTTP responses from the server container back to the user's browser. Network egress can become a cost factor if your server-side tagging endpoint serves larger resources or JavaScript libraries. |
Storage (logs) | Varies | Once you collect enough requests to surpass the free tier of Cloud Logging, the cost of storing logs can become substantial. To lower logging cost, filter out the incoming requests or to include only a sample of log entries. |
Alternatively, you can follow your Google Cloud Platform Billing reports closely, set appropriate budgets, and cooperate with your organization's DevOps team to figure out the best approach to scaling up your server-side tagging environment.
Best Practice: Consolidate Event Requests
To get the full benefit out of server-side tagging, you'll likely want to make sure that you are able to keep costs as low as possible and keep resources on the client side as light as possible, while not losing any data along the way.
By moving as many of your client-side resources as Google Analytics, Meta, and Pinterest into the client container, you can improve page performance in that you're minimizing the number of client-side requests and libraries that need to be loaded and triggered on the page. In doing this, if we were to send an individual request off to our server container for each tag migrated to the server side we'd incur significant costs on egress traffic, scaling, and logging.
Instead, by consolidating the various data points needed for all tagging that needs to trigger on a given event into a single request payload to your server container, you can minimize egress traffic back to the browser, reduce scaling needs, and limit logging.
To keep both your costs and server footprint lean - without sacrificing data fidelity:
Bundle data needed by all tags into a single event request
Trigger all relevant server-side tags from that one hit
Reduce log size, bandwidth, and compute time
Is Server-Side Tagging Worth It?
For businesses prioritizing privacy, control, and performance, server-side tagging is more than a technical upgrade—it’s a strategic advantage. While setup and maintenance require more upfront investment, the long-term benefits include faster pages, improved compliance, and better data integrity.
Ready to explore server-side tagging but unsure where to start? At Napkyn, we help organizations assess readiness, build scalable GTM infrastructures, and navigate privacy requirements with confidence. Talk to our Implementation Experts today.
More Insights
Server-Side Tagging with Google Tag Manager: What Marketers and Developers Need to Know
Ricardo Cristofolini
Senior Implementation Specialist, Data Solutions
May 28, 2025
Read More
Strengthen Your First-Party Data Strategy with Google Ads Data Manager
Monika Boldak
Associate Director, Marketing
May 27, 2025
Read More
What You Need to Know About GA4’s New Cross-Channel Budgeting Tools
Monika Boldak
Associate Director, Marketing
May 22, 2025
Read More
More Insights
Sign Up For Our Newsletter