Server-Side GTM vs a Conversions API Platform: Which to Use?

Both approaches solve the same underlying problem: browser pixels miss conversions because of iOS privacy controls, ad blockers, and flaky page loads, and the fix is sending those conversions from a server you control. If you need the fundamentals first, start with our server-side conversion tracking guide. This article assumes you already know you want server-side tracking and are deciding how to get it.

What is server-side Google Tag Manager?

Server-side GTM (sGTM) is a second Tag Manager container that runs on a server instead of in the visitor's browser. Your web container or a tiny script sends events to that server, and the server container decides what to forward to each ad platform.

Google describes the setup as three moving parts. Clients are adapters that receive incoming requests (a GA4 client and a Measurement Protocol client are included by default) and turn them into events. Tags are what send those events onward, using templates such as Meta's official Conversions API tag or Google's own Google Ads conversion tag. Triggers and variables work the same way they do in the web container. Everything runs on infrastructure you pick: Google's Cloud Run or App Engine, a Docker image on your own servers, or a managed host like Stape, TAGGRS, or Addingwell.

The server container is genuinely powerful. Because you can inspect and rewrite every event before it leaves, you can enrich purchases with CRM data, strip fields for consent reasons, or fan one event out to a dozen destinations. That flexibility is also the source of most of its cost.

What is a Conversions API platform?

A Conversions API platform is a hosted service that owns the whole path from the visitor's browser to the ad platform. You install one first-party snippet; the vendor's servers receive events, attach hashed identifiers and event IDs, and forward conversions to each destination you switch on in a dashboard. There is no container to build, host, or upgrade.

The category has two flavors. Single-purpose gateways, such as Meta's Conversions API Gateway, forward events to one ecosystem with almost no configuration. Multi-destination platforms, including EndFrame, Tracklution, SignalBridge, and DataCops, handle several ad platforms from one event stream and usually add attribution reporting on top. The trade-off is that you configure within the vendor's model rather than writing arbitrary logic.

Server-side GTM vs Conversions API platform: side-by-side comparison

The table below compares the two on the factors that actually decide total cost of ownership. Pricing figures are as of September 2026 and link to the vendor pages listed in the sources.

How much does server-side GTM cost per month?

Expect a floor of about $20 to $120 per month for hosting, plus the far larger cost of the people who set it up and keep it running. The hosting line is the easy part to estimate.

Google's own Cloud Run guide prices a server-side tagging instance at approximately $45 per month with 1 vCPU and 0.5 GB of memory, and recommends running at least two instances to reduce data loss during an outage. That puts a minimal Google-hosted production setup near $90 per month before egress and logging. Managed hosts undercut that at low volume: as of September 2026, Stape lists a free plan under 10,000 requests per month, a $20 plan below 500,000 requests, and $100 above that; TAGGRS offers 10,000 free requests, then €22 for 750,000 and €57 for 3 million; Addingwell includes 100,000 requests free, then €90 for 1 million, with extra containers at €30 and extra domains at €10 per month.

Note the unit. Managed sGTM hosts bill by server requests, and one pageview can generate several requests once you count page_view, scroll, consent, and each outbound tag. Estimate volume from your analytics before choosing a tier.

The hidden cost is labor. A working sGTM deployment needs someone to configure the custom subdomain, install and update tag templates, keep event IDs consistent between web and server containers, gate tags on consent, and re-test after every site release. Agencies typically quote this as a project fee, and in-house it is a recurring slice of an analyst's or developer's week. If you are comparing against a platform subscription, compare against that total, not the hosting bill.

Do I need server-side GTM to do server-side tracking?

No. Server-side GTM is one way to send server events, not the definition of server-side tracking. Any system that receives events on a server you trust and forwards them to a conversion API is doing server-side tracking. That includes Meta's Conversions API Gateway, direct API integrations written by developers, and hosted platforms with a first-party snippet.

The confusion comes from GTM being the tool most marketers already know. If your team lives in GTM and you want to keep tag logic in one place, sGTM is the natural extension. If you never liked managing tags, there is no rule that says you must adopt a second container to fix your conversion data.

Server-side GTM pros and cons

sGTM wins on control and loses on time. The advantages and drawbacks are two sides of the same design.

Advantages

• Any destination with a template, and custom templates for anything else
• Full control over every field before it leaves your server, including enrichment and PII stripping
• Google Ads conversion tags and enhanced conversions can be sent from the server using Google's documented setup, with the conversion linker and GA4 client
• Data stays in infrastructure you own
• Same mental model as the web container your team already uses

Drawbacks

• Multi-day setup that requires DNS, hosting, and GTM expertise
• Deduplication, consent gating, and parameter hashing are your responsibility on every tag
• Debugging spans three places: browser, server preview, and each platform's event diagnostics
• Templates and the tagging server itself need updates over time
• Per-request billing scales with every event, not just conversions
• No campaign or attribution reporting; sGTM forwards data, it does not analyze it

When server-side GTM is the right choice

Pick sGTM when customization, breadth of destinations, or data governance requirements outweigh setup effort. Four situations make it the clear winner.

• Heavy customization: you need to enrich events with server-side lookups, rewrite values, or apply routing rules per event type.
• Many destinations: you are sending to Pinterest, LinkedIn, Snapchat, a data warehouse, and an email platform alongside Meta and Google. One container fanning out beats five vendor integrations.
• Enterprise data governance: legal requires that raw event data never leaves your cloud account, and you have the engineering capacity to run it.
• Google Ads conversions via server: you want Google Ads conversion tags and enhanced conversions to fire from the server container using Google's first-party setup.

If you are on Google Tag Manager today and want to see what your browser-side setup is currently leaking, our tracking audit for Google Tag Manager sites is a useful baseline before you invest in a server container.

When a Conversions API platform is the right choice

Pick a platform when you need reliable Meta, GA4, and TikTok conversions quickly, and when the attribution context around those conversions matters as much as the conversions themselves. Three situations make it the better option.

• Lean teams: one marketer owns tracking, and a second GTM container is a liability they will not have time to maintain.
• Agencies with many client domains: onboarding a client means verifying a domain and toggling destinations, not provisioning a new server container, custom subdomain, and template set per site.
• Attribution context: you want to know which campaign, source, and UTM produced the conversion, not just that a purchase event reached Meta. Platforms that own the first-party event stream can report visit-to-conversion chains; sGTM cannot.

That last point is the one most comparisons skip. A server container is a forwarder. It has no concept of a campaign, no inbox of leads with referrer metadata, and no report that answers which UTM source drove last week's conversions. If clean campaign reporting is part of the goal, the platform route saves you a second tool. Getting UTM hygiene right first helps either way; see how UTM parameters quietly break reports.

Conversions API Gateway vs server-side GTM

Meta's Conversions API Gateway is the fastest way to get Meta-only server events; sGTM is the way to get server events for everything. Meta describes the Gateway as middleware provisioned inside a cloud account the business owns (AWS or GCP), which receives browser events and relays them to the Conversions API with the event_id deduplication key generated and propagated automatically. Meta states the only cost is the cloud resources or partner fees; Stape and other partners also host it for a monthly fee.

The Gateway is limited by design. It serves Meta only, offers little customization, and does nothing for GA4, TikTok, or your own reporting. Stape's comparison frames the choice the same way: Gateway for a fast Meta-only setup without developers, sGTM for advanced multi-platform integration.

Can I run the Gateway and server-side GTM in parallel?

You can, but you should not send the same events through both. Meta deduplicates browser and server events only when the event_name and event_id match within a 48-hour window. The Gateway generates its own event IDs; a Meta CAPI tag in sGTM uses whatever ID you pass it. Two server-side senders producing different IDs for the same purchase are not deduplicated, so Meta counts the purchase twice, inflating results and distorting optimization. Platform vendors that send their own server events routinely instruct customers to disable the Gateway for the same reason. Pick one server-side sender per pixel.

Hybrid setups that actually work

The sensible hybrid is one server-side sender per destination, not two senders per destination. Combinations that work well in practice include:

• A Conversions API platform for Meta, GA4, and TikTok, plus a browser-side Google Ads tag in web GTM until you are ready to move Google Ads server-side.
• A platform for conversions and campaign attribution, plus sGTM used only for a destination the platform does not support, with separate events so nothing overlaps.
• Meta's Gateway for a single-brand Meta-only account, upgraded to a platform or sGTM when a second ad platform enters the mix.

Whatever you combine, keep the browser pixel. Meta recommends a redundant setup where the same events are sent from both the Pixel and the Conversions API, deduplicated by event ID. Server-side tracking supplements the pixel; it does not replace it.

What EndFrame does and does not do

EndFrame is a Conversions API platform with attribution built in, and it is honest about its edges. Here is the exact scope so you can decide whether it fits.

What it does: a lightweight first-party snippet collects visits, actions, scroll depth, engagement time, screen resolution, viewport, browser language, and connection type. Conversion goals are defined by event match or URL match, with per-campaign and per-source breakdowns. Each server-side destination is a dashboard toggle: Meta Conversions API, GA4 Measurement Protocol, TikTok Events API, and custom webhooks, with hashed identifiers and browser-to-server event-ID deduplication handled for you. No server container is required. Real-time reporting slices live visitors and conversions by geo, device, path, referrer, and UTM, and the raw visit-to-action-to-conversion chain is stored for auditing. Multi-domain management, a lead inbox with source metadata, custom roles, API keys, a REST API, an MCP server for AI agents, and CSV export round it out.

What it does not do: EndFrame does not send Google Ads Enhanced Conversions or offline conversion imports, and does not forward to LinkedIn, Pinterest, or Snapchat. It has no multi-touch attribution models, no bot filtering, no consent management platform, and no cross-device identity resolution. If any of those are hard requirements, sGTM or a different platform is the right answer, and we would rather say so here than after you sign up.

Pricing is flat: Starter at $49 per month covers 3 domains, 15 campaigns, and 50,000 tracked visits with server-side conversions to all four destinations; Growth at $149 per month covers 10 domains, 30 campaigns, and 250,000 tracked visits with engagement analytics, MCP access, and full governance; Enterprise is custom. Every plan starts with a 14-day free trial and no credit card. To size the problem before you decide, run the free website tracking audit or the conversion recovery calculator.

Migration checklist: sGTM to a platform

Migrating off sGTM is mostly an inventory exercise. Follow these steps in order to avoid a gap or a duplicate window.

1. 1Export a list of every server tag, its destination, and the trigger it fires on. Anything not on the platform's destination list must stay in sGTM or be dropped deliberately.
2. 2Map each conversion tag to a platform conversion goal (event match or URL match) and confirm the platform sends the same event names the ad platform expects.
3. 3Install the platform snippet on every domain and verify events arrive in the platform's real-time view.
4. 4Enable one destination at a time in the platform, starting with the lowest-stakes one, and confirm events appear in that platform's diagnostics with a healthy match quality.
5. 5Pause the corresponding sGTM tag the same day you enable the platform destination. Never leave both active for the same pixel.
6. 6Confirm the browser pixel and the platform's server events are deduplicating (Meta shows this in Events Manager) before touching the next destination.
7. 7Once every supported destination has moved, downgrade or cancel the sGTM hosting plan, and leave the server container in place only for destinations the platform cannot serve.

Migration checklist: platform to sGTM

Moving to sGTM is the reverse process with more setup up front. Budget several days for infrastructure before you switch anything.

1. 1Provision hosting (Cloud Run, App Engine, a managed host, or your own Docker deployment) and map a custom first-party subdomain to it.
2. 2Configure the GA4 client in the server container and update the web container or snippet to send to your tagging server URL.
3. 3Install official tag templates for each destination (Meta Conversions API, Google Ads conversion tracking, TikTok, and so on) and enter pixel IDs and access tokens.
4. 4Generate an event ID in the browser for every conversion event and pass it to both the browser pixel and the matching server tag.
5. 5Read consent state in the server container and gate each tag accordingly.
6. 6Run preview mode end to end, then compare event counts and match quality against the platform for at least a week in parallel on non-overlapping test events.
7. 7Disable the platform destination and enable the server tag for one destination at a time, and keep the platform's attribution reports if you still need campaign context.

The bottom line

Server-side GTM is the right tool when you need arbitrary transformations, a long list of destinations, or full data ownership, and you have someone who will maintain it. A Conversions API platform is the right tool when you want Meta, GA4, and TikTok conversions working this week, with campaign attribution alongside them, and no container to babysit. Either way, run exactly one server-side sender per destination, keep the browser pixel, and verify deduplication before you trust the numbers.