Server-side tagging vs server-side tracking: sGTM container or managed connector
Server-side tagging almost always means one specific thing: a server-side Google Tag Manager container, hosted somewhere and configured by someone. Server-side tracking is the wider goal, and a container is only one way to get there. This page explains the difference properly, then compares the two routes: run an sGTM container on Stape, Taggrs, Addingwell or your own Google Cloud account, or use a managed connector that sends your events straight to each platform's conversion API with no container at all.
If you came here looking for sGTM hosting, read the honest comparison below before you decide. Sometimes a container really is the right answer.
Server-side tagging, server-side tracking, sGTM: what each word means
These three terms get used as if they were the same thing. They are not, and the difference decides how much work lands on your side.
Server-side tagging is a container
A tag manager, running on a server rather than in the browser. The tags did not disappear: they moved. Someone still has to build them, and the container still has to be hosted and paid for.
Server-side tracking is the outcome
Getting the conversion to Meta, GA4 or Google Ads from a server instead of a browser that blocks, expires or never loads the tag. That outcome can be reached with a container, or without one.
sGTM is one implementation
Server-side Google Tag Manager is Google's product for doing server-side tagging. It is the best known route, which is why it gets mistaken for the definition of server-side tracking itself.
What an sGTM container actually is
An sGTM container is a Google Tag Manager container of the Server type. Unlike a web container, it is not a snippet you paste into a page: it is an application that has to run somewhere. Originally that meant Google Cloud App Engine on your own billing account. Today it more often means a specialist host such as Stape, Taggrs or Addingwell, who provision and operate the infrastructure for you.
Inside the container you configure clients, which turn incoming requests into events, then tags, triggers and variables, which decide what is sent onwards to each platform. The hosting provider gives you the machine. The mapping between your store's purchase and what Meta or Google Ads expects to receive is still yours to build, and yours to fix when it breaks.
Where the two terms get mixed up
Because sGTM arrived first and dominated the conversation, "server-side tagging" became the default name for the whole category. So a merchant who simply wants their purchases to reach Meta reliably goes looking for container hosting, compares hosts on price per container, and ends up owning a tag manager they never wanted. The question worth asking first is not which host is cheapest. It is whether you need a container at all.
What Google's Tag Gateway is, and what it is not
Tag Gateway for advertisers is a third thing, and it is often mistaken for the first two. It serves Google's tagging scripts from your own domain, through your CDN or hosting provider, instead of from a Google domain. That helps with script blocking and with cookie lifetime, and it is genuinely useful. But the measurement still happens in the visitor's browser: only the delivery of the script has moved. It is a first-party serving layer, not server-side tracking, and it covers Google's tags only.
Want the wider picture rather than the sGTM question specifically? Read what server-side tracking is and how it works.
Host a container, or skip the container entirely
Both routes end at the same conversion APIs. They differ in what you have to run, what you have to know, and who fixes it at 11pm when the purchases stop arriving.
Route A: your own sGTM container
Provision a server container with Stape, Taggrs, Addingwell or directly on Google Cloud, point a subdomain at it, then build the tracking inside: clients, tags, triggers, variables, consent settings and a shared event ID for deduplication. You get complete control over every tag, and you own the configuration, the debugging and the monthly bill. One container is normally one site, so a second shop means a second container and a second plan.
Route B: a managed connector, no container
Install the connector for your platform, paste one connection key, and your funnel is mirrored to the conversion APIs of six destinations. The mapping is already written and maintained by us, deduplication and consent gating are built in, and every shop on your account sits under one subscription. You give up tag-level control in exchange for not having a tracking system to operate.
| sGTM container (server-side tagging) | DataFirefly (direct to conversion APIs) | |
|---|---|---|
| What runs | A Google Tag Manager server container, hosted on Stape, Taggrs, Addingwell or your own cloud account | Nothing on your side: an EU-hosted dispatcher receives your events |
| What you configure | Clients, tags, triggers, variables, consent settings, event parameters per platform | One connection key in the connector, and your destination credentials once |
| Event mapping | Yours to build: each platform expects different purchase parameters | Written and maintained by us, per platform and per destination |
| Deduplication | You wire the shared event ID between the browser tag and the server tag | The connector emits the same event ID on both sides automatically |
| Skills required | Real server-side GTM knowledge: clients, templates, debugging | None beyond installing a module and copying a key |
| Custom transformations | Anything you can express in a tag template: the strongest argument for a container | Limited to what the connectors and the dispatcher already support |
| Destinations | Very broad, through the GTM template gallery, configured tag by tag | Six ready out of the box: Meta CAPI, GA4, TikTok, Pinterest, Google Ads, Microsoft Advertising |
| Several shops | One container per site, so one plan per site | Every shop on the account under one subscription |
| Cost model | Per container, per month, plus whoever configures and maintains it | Per account: free up to 10,000 events a month, then from EUR 39 |
| Diagnostics | The sGTM preview and debug mode, plus your host's request logs | Event-by-event Inspector with per-destination status, personal data redacted |
All trademarks belong to their respective owners. This comparison describes the two architectures, not a single supplier, and is provided for information as of August 2026.
What the connector does instead of a container
Everything you would otherwise configure inside an sGTM container is already built, and stays maintained on our side as the platforms change.
No container, no cloud account
Nothing to provision, no subdomain to delegate, no App Engine bill. The dispatcher is ours to run and ours to keep up.
Mapping already written
Each destination wants different purchase parameters. That work is done once, by us, and updated when a platform moves the goalposts.
Deduplication built in
The browser layer and the server event share one
event_id, so running both never inflates your reported
conversions.
Consent enforced twice
Nothing fires client-side without marketing consent, and the dispatcher checks again before any event leaves for a destination.
Retry queue
Retryable delivery failures are replayed automatically, so a brief outage on either side does not cost you a conversion.
Inspector instead of debug mode
Every event and its per-destination status is visible, with personal data redacted. You confirm delivery rather than assume it.
Credentials never in the store
Access tokens and dataset IDs are encrypted on our side. A compromised front-end cannot leak them.
One event, six destinations
Meta CAPI, GA4, TikTok, Pinterest, Google Ads and Microsoft Advertising from the same event, with no second integration to build.
When sGTM is the better choice
We would rather lose the sale than have you buy the wrong thing. In these situations a server-side GTM container is genuinely the better answer, and we will say so.
You already have GTM expertise
If you or your agency know server-side GTM well, a container is cheap infrastructure and you lose nothing by running it. The learning curve is the expensive part of sGTM, and you have already paid it. Hosts like Stape and Addingwell are very good at the rest.
You need destinations we do not cover
We ship six destinations. The GTM template gallery covers hundreds. If your stack includes a CRM, a data warehouse, an affiliate network or a niche ad platform that we do not support, a container will reach it and we will not.
You need arbitrary transformations
Custom enrichment, lookups against your own systems, conditional routing, bespoke payload rewriting: a container is programmable and we are configurable. When the requirement is genuinely custom logic, that difference matters and the container wins.
And when we are the better fit. If you run one or several e-commerce stores, want the conversions that ad-blockers and ITP are eating, and have no wish to become a tracking infrastructure team, the connector route gets you there in an afternoon instead of a project. If you are comparing specific suppliers, we keep an honest side-by-side on our Stape alternative and Addingwell alternative pages.
Server-side tracking without building a container
Add your destinations once
In your DataFirefly account, add the credentials for the platforms you want to reach. They are stored encrypted and never sent to your store, which is one fewer secret sitting in a container configuration.
Install the connector for your platform
PrestaShop,
WooCommerce or
Shopware, then paste your
single dfss_ connection key. On any other stack, post events
to our API. No subdomain to delegate, no container to publish.
Place a test order and check the Inspector
The Inspector replaces the sGTM preview mode: every event, every destination, with its delivery status. Confirm the purchase landed in each platform, and you are done.
Container-free server-side tracking, per platform
PrestaShop
A native module that sends the full funnel server-side, with deduplication and consent handling built in.
WooCommerce
A WordPress plugin with a retry queue, an Activity panel and HPOS support, delivering purchases server-side.
Shopware 6
A Shopware plugin covering the same funnel, connected with the same single key.
Shopify
Shopify's order webhooks, subscribed in minutes with the same single key. Nothing to add to the theme.
A headless front-end or a custom stack? Post your events to our API and the dispatcher handles every destination the same way, still with no container in the middle. Tell us about your setup.
Priced per account, not per container
sGTM hosting is normally billed per container, which means per site. One DataFirefly subscription covers every shop on your account and every destination. Start on the free plan and see your events land before you pay anything.
Free
Free while you stay under the monthly allowance: nothing breaks if you go over.
Starter
For a single store that wants server-side tracking without a container.
Billed €390 per year: 12 months commitment, no pro-rata refund.
Growth
For merchants and small agencies running up to five stores.
Billed €1 190 per year: 12 months commitment, no pro-rata refund.
Scale
For agencies and portfolios managing up to twenty stores at higher volume.
Billed €3 490 per year: 12 months commitment, no pro-rata refund.
Not ready to compare invoices yet? The free plan gives you one site and 10,000 events a month, with no credit card, which is enough to see whether the container was ever the point.
Removing the container does not remove the rules
Neither route exempts you from consent. Moving a tag to a server changes where the request comes from, not whether you were allowed to send it.
Events are processed in Falkenstein before they reach any destination.
Nothing fires client-side without marketing consent, and the server re-checks.
Destination tokens are encrypted at rest and never sent to the browser or the store.
Email and phone are hashed as each platform requires: raw identifiers are not sent.
A data processing agreement covering this flow is on our DPA page.
Tracked in real time on our public status page, in line with our SLA.
Frequently asked questions: server-side tagging and sGTM
What is server-side tagging?
Server-side tagging is the practice of running your marketing tags inside a tag manager that lives on a server instead of in the visitor's browser. In practice the phrase almost always means server-side Google Tag Manager: a GTM container hosted somewhere you control, which receives events from the page and then decides which tags to fire. The word tagging is the giveaway. There is still a container, there are still tags, and someone still has to configure them. What has moved is where they run.
What is the difference between server-side tagging and server-side tracking?
Server-side tracking is the goal: getting your conversions to the advertising and analytics platforms from a server rather than from a browser that ad-blockers and cookie policies keep interfering with. Server-side tagging is one way to reach that goal, using a tag manager on a server as the middle layer. Sending your events straight to each platform's conversion API is another way to reach the same goal, with no tag manager in the middle. Both are server-side tracking. Only one of them is server-side tagging.
What is sGTM, and what is an sGTM container?
sGTM is the usual shorthand for server-side Google Tag Manager. An sGTM container is a Google Tag Manager container of the Server type, running as an application on infrastructure you pay for: originally Google Cloud App Engine, and today more often a hosting provider such as Stape, Taggrs or Addingwell. Inside it you configure clients, which turn incoming requests into events, then tags, triggers and variables, which decide what gets sent onwards to Meta, GA4, Google Ads and the rest. The container is a piece of software you operate, not a setting you switch on.
Do I need a GTM container to do server-side tracking?
No. A GTM container is a means, not a requirement. Meta, Google, TikTok, Pinterest and Microsoft all publish server-to-server conversion APIs that accept events directly, and a container is simply one thing that can call them. DataFirefly calls them for you: your store sends signed events to our EU-hosted dispatcher, which delivers them to each destination with deduplication, consent checks and retries already handled. There is no container to create, no clients or tags to configure, and no cloud account to open.
What is Google's Tag Gateway, and does it replace sGTM?
Tag Gateway for advertisers lets you serve Google's tagging scripts from your own domain, through your CDN or hosting provider, instead of from a Google domain. It changes where the script is served from, which helps with script blocking and cookie lifetime. It does not change where the conversion is sent from: the measurement still happens in the visitor's browser. It is a useful first-party serving layer, not a replacement for either an sGTM container or a server-to-server connector, and it only covers Google's own tags.
What does running an sGTM container actually involve?
Four things, and they are ongoing rather than one-off. You pay for hosting, per container, which usually means per site. You configure the container: clients, tags, triggers, variables and consent settings. You map every event you care about, including the purchase parameters each platform expects and the shared event ID that stops conversions being counted twice. And you maintain it, because tag templates and platform requirements keep changing. None of this is unreasonable. It is simply work, and it needs someone who knows GTM well enough to debug it when a conversion stops arriving.
Is DataFirefly an alternative to Stape, Taggrs or Addingwell?
It solves the same problem by a different route. Stape, Taggrs and Addingwell host sGTM containers well, and if you want a container, one of them is very likely the right supplier. DataFirefly removes the container from the picture instead: you install a connector for your platform, paste one key, and the mapping to each conversion API is already done. Compare us honestly on our Stape alternative and Addingwell alternative pages, including the cases where their approach wins.
Can I keep my sGTM container and use DataFirefly as well?
Yes, though you should decide which system owns which destination before you do. Running both against the same platform without a shared event ID will double-count your conversions. The usual sensible split is to let the container keep the destinations it already handles well, and give DataFirefly the ones that were never wired up properly, or the shops that do not justify a container of their own. Tell us what your container does today and we will tell you whether moving is worth it.
Google Tag Manager, Google Ads and Google Analytics are trademarks of Google LLC. Stape, Taggrs and Addingwell are trademarks of their respective owners. DataFirefly is not affiliated with any of them. Product names are used to describe interoperability and to compare approaches.
Server-side tracking, without inheriting a container
Install a connector, paste one key, and see your conversions reach Meta, GA4, TikTok, Pinterest, Google Ads and Microsoft Advertising. Free up to 10,000 events a month, no credit card.