Server-side GTM architecture guide
A server container is a small web application on your own subdomain that receives requests, maps them to events through a client, and dispatches them to destinations through tags. The architecture decisions that matter are made before any of that is built: which subdomain, hosted where, what the source of truth is, and who owns it afterwards. Get those four right and the implementation is routine. Get the last one wrong and the whole thing decays quietly within a year.
Free30 minutesNo obligation
sGTM architecture · what breaks
Where teams get this wrong — sGTM architecture
- 01
Building before deciding the source of truth
Then there's nothing to verify the result against.
- 02
Treating hosting as an afterthought
Cost, residency and who holds the keys are far easier settled before the tags exist.
- 03
No named owner after handover
The most common reason a good build stops working.
sGTM architecture · the fix
What a correct implementation looks like — sGTM architecture
A tagging subdomain on your own certificate
So cookies are genuinely first-party.
Hosting in an account you control
Yours, not your agency's.
Money events from your own records
Not proxied browser events.
A named owner and monitoring
So a break surfaces in days.
sGTM architecture · architecture
The components and what each does — sGTM architecture
The pieces of a server container and the decision attached to each.
- 1
The tagging subdomain
Where requests arrive. Must be on your own domain with your own certificate for cookies to be first-party.
- 2
Clients
Receive incoming requests and translate them into events the container understands.
- 3
Tags
Dispatch events to destinations. One event can fan out to many, which is the main efficiency of the architecture.
- 4
Cookie handling
Set in HTTP responses rather than JavaScript, which is what escapes Safari's seven-day cap.
- 5
Consent enforcement
At the container, before dispatch. A denied destination receives nothing.
- 6
Backend event ingestion
Order webhooks and CRM events arriving directly, with no browser involved.
sGTM architecture · diagnose
Common mistakes and how to validate each — sGTM architecture
Ordered by how often we find them. Each one has a specific check rather than a general instruction to be careful.
- 01
Legacy paths left running
The container going live switches nothing off. Both send, and the account double-counts on the day it was meant to improve.
- 02
Subdomain not on your own certificate
Check what certificate it presents. If it isn't yours, first-party cookie behaviour may not apply.
- 03
Hosting in the agency's account
Ask whose name the account is in. This is a control question, not a technical one.
- 04
No monitoring
Ask how you'd learn the container had stopped. If the answer is a quarterly review, that's the gap.
- 05
Consent assumed rather than tested
Deny consent and capture what leaves.
sGTM architecture · prove
How to prove your implementation is right — sGTM architecture
Against your own records and a live payload, not against a preview screen.
Source of truth
your own order or CRM records
- Tagging subdomain resolving on your own certificate.
- Hosting account confirmed in your name.
- First-party cookies confirmed persisting past seven days in Safari on a real device.
- Deduplication verified before any legacy path was removed.
- Consent verified by denying it and confirming nothing leaves.
- Checked on a live conversion, not in preview mode.
- Reconciled over a fully closed window, matched per record.
- Re-checked 30 days later.
sGTM architecture · free audit
What we check in the free audit
- Legacy paths left running
- Subdomain not on your own certificate
- Hosting in the agency's account
- No monitoring
- Consent assumed rather than tested
Checked against
your own order or CRM records
Free30 minutesNo obligation
sGTM architecture · when not to buy
What this reference deliberately leaves out — sGTM architecture
Stated openly, because a reference that's silent about its own gaps is the dangerous kind.
- Hosting provider selection is a separate decision covered on its own page.
- Specific client and tag configuration depends on your destinations and changes as vendors update their templates.
- Container security hardening has its own checklist.
- Vendor documentation is the authority, not this page. Where the two disagree, the vendor is right and we'd like to know so we can correct it.
- Parameter names and behaviour change. Anything here is accurate as we last verified it; verify against the current documentation before you rely on it for a build.
sGTM architecture · what we deliver
The checklist — sGTM architecture
Tagging subdomain resolves on your own certificate
Not a third party's.
Hosting account is in your name
Whoever holds it holds your measurement.
Money events come from order or CRM records
Not from a page.
Consent is enforced at the container
Before dispatch, verified by capture.
Monitoring alerts a named person
Not a shared inbox nobody reads.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies your existing browser-side setup against this reference, on a live conversion.
- Implementation checked against the spec
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, built to this specification.
- First-party server container on your own subdomain
- Events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, documented to this standard.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring so the next break surfaces in days
FAQ
sGTM architecture questions, answered
No. It sits behind it. The web container still collects browser context and forwards it to your subdomain.
Leaving legacy firing paths running after the container goes live. Both send, and the account double-counts from day one.
Yours. Whoever holds the infrastructure holds your measurement, and that shouldn't be an agency — including us.
It degrades. Certificates expire, destinations change their templates, and nobody notices until a quarterly review. That's a real reason not to build one.
Free · 30 min
Get the architecture decisions right first
WhatsAppFree30 minutesNo obligation
