Server-side tagging, built on infrastructure you own.

What this covers

A server container receives events on infrastructure you own and forwards them to vendors from there. This is the work of designing that setup, provisioning it, moving your existing events onto it without losing a week of data, and handing it back documented.

The client and server split. Something still fires in the browser: a loader, an event, the page context, the click identifiers. The server container takes that request and decides what each vendor gets from it. Drawing that boundary is most of the design. Which events start in the browser, which come from your backend, and which are assembled from both.

A collection endpoint on your own domain. The container answers on a subdomain of your site, which means a DNS record, a certificate and a host. How that name resolves matters more than the name. A first-party hostname resolving by CNAME to a vendor endpoint is treated by Safari as third-party, so the benefit is lost while the setup looks correct.

Cookie lifetime. This is the durable gain. Safari caps cookies written by JavaScript in the page at seven days. A cookie set in the HTTP response by a server on your own infrastructure is not subject to that cap, so a returning visitor keeps the same analytics identity across a longer window. It does nothing for third-party advertising cookies, which are a separate mechanism.

Enrichment. The server is where a payload gets corrected before it leaves. Order value read from your system of record rather than a page showing a discounted subtotal. Currency normalized. Hashed customer data assembled once and passed consistently to every destination that accepts it. Fields that should never reach a vendor removed rather than hoped over.

Meta Conversions API with deduplication. The browser pixel and the server event have to carry the same event name and the same event_id, generated once per user action and passed down both paths, and they have to arrive inside Meta’s dedup window. Regenerate the id on the server and every purchase counts twice. The build forwards fbp and fbc too, because a server event with no click identifier and no browser cookie is weaker than the pixel it was meant to strengthen.

How it runs

Scoping first, then a fixed price. The call establishes what you run today, the volume the container must carry, and where each event comes from. The project is quoted fixed-price after that, and the $900 audit fee is credited in full.

The event map is written before anything is provisioned. Every event, its source, its destinations, the parameters each destination needs, and the consent state that governs it. Infrastructure decisions follow that document, not the other way around.

Hosting lives in your account. The container is provisioned in your own cloud project, under your own billing. It is a service you own and pay for monthly, sized to request volume and usually kept warm rather than cold starting. That bill is a real line item, estimated during scoping rather than discovered afterwards.

Parallel run before cutover. The server path runs alongside your existing client-side tagging into a separate destination, and both are compared against your order or lead records. Nothing is switched off until the numbers agree within a margin you accept. That is a data decision, not a date.

Published only with your approval. Container changes are built in a separate GTM workspace and published as one named version that can be reverted in a single action.

What you get

• A server container on your own domain and in your own cloud account, DNS record and certificate documented.
• A written event map: sources, destinations, parameters, consent gating.
• Your client-side container rewired to route through the endpoint, with the tags that belong in the browser left there.
• Meta Conversions API sending with deduplication verified against live events in Events Manager, not assumed from configuration.
• Consent state carried into the server container and enforced on server tags.
• The parallel run comparison, so you can see what changed and what did not.
• Monitoring on the endpoint and a short runbook for the failures that matter: container down, destination rejecting payloads, cost spike.
• A recorded walkthrough, documented well enough that your developer can take it over.

When this is the wrong fit

Your client-side layer is the actual problem. If the dataLayer is wrong, the trigger is wrong, or the event never fires, forwarding it from a server makes it wrong somewhere more expensive. Fix the source first.

You are buying it to get around consent. Moving a tag off the page does not move it outside the choice the visitor made. A denied state has to be honored on the server too, and it will be.

You are buying it to get around blockers. The first request still leaves the browser. A first-party endpoint is harder to match on a filter list than a known vendor hostname, which recovers some volume, and only events sent from your own backend sit outside the browser entirely. Nobody should promise you the rest.

The volume does not justify the bill. A low traffic site can spend more on hosting and monitoring than the recovered signal is worth. Better heard before the project than after.

If you already know a server container is what you need, a scoping call is enough to quote the build. If you are not sure, the Missing Conversions Audit is the cheaper way in: it measures what your setup is losing today and where a server container would and would not change that. The $900 is credited in full against the build.