Your ad platforms are optimising on data you never sent.
Ad blockers, Safari's cookie limits and consent gating drop a third of your browser events before they ever leave the page. Bidding algorithms then optimise against the half of your funnel that happens to survive.
We move collection into a server container you own — designed, deployed, instrumented and monitored. Not a dashboard handed over for you to babysit.
- 30–45%
- of events lost client-side
- 48h
- managed go-live
- 99.9%
- monitored uptime
- EU / US
- data residency
your ad platforms
Most of it comes back.
Client-side collection delivers a little over half of what you actually earn. Moving collection into a server container recovers most of the rest — the same events, from the same visitors, over a path nobody can block.
Four failure modes, none of them your implementation.
You can build a flawless data layer and configure every tag correctly and still lose this much. These are structural properties of running measurement inside someone else's browser — which is exactly why the fix is architectural rather than a better tag.
V1 Tracker blocking −24% +
uBlock, AdGuard, Brave shields and Pi-hole style DNS filtering all match on common advertising platform URLs. The request is filtered and never made, so there is nothing reported to you about the customer.
V2 ITP / ETP cookie caps −11% +
Safari caps first-party cookies set by JavaScript at 7 days, and at 24 hours when the visitor arrived from another site. Someone who researches this week and buys next month comes back as a brand-new user, so the sale is credited to nobody and the campaign that actually earned it reads as though it did not work.
V3 Consent gating & CMP timing −7% +
Tags stay blocked until your consent banner answers. If the banner renders late, or the visitor acts before it appears, or they leave before deciding at all, the event is never created — not created and withheld, simply never created. You see a visit that did nothing.
V4 Script failure & abandonment −4% +
An unrelated JavaScript error earlier in the page can stop the container loading, the browser can drop the final request as the visitor leaves, and a slow connection can mean the tag never arrives. All three fail silently: the event does not exist, and nothing anywhere records that it should have.
Bars scaled ×2 for legibility · figures are medians across EU e-commerce and lead-gen migrations
Everything we sell, with the scope written down.
Four phases. Take the whole path or a single line item — an assessment on its own is a perfectly good place to start, and it is the only way to know whether the rest is worth buying.
Not listed and you still need it? It is probably a D-item. Ask.
Nothing leaves until it is clean.
A server container is not just a relay. Every event passes through a transform you control before any platform sees it — which is the one place in the whole stack where you can enforce privacy, drop rubbish, and add the context your bidding actually needs.
Emails, phone numbers and names are SHA-256 hashed to the format each platform expects, or dropped outright. Raw identifiers never leave your infrastructure.
The final octet is zeroed before storage or forwarding. Country and region are resolved server-side, so you keep the reporting without keeping the identifier.
Requests from cloud ranges, headless browsers and AI crawlers are dropped before they reach a destination — and before they teach your bidding algorithm anything.
Consent state is evaluated in the container against a per-destination policy. A denied signal means the request is never constructed, not merely flagged.
Margin, lifetime value, lead score and order index are joined from your CRM or warehouse in flight, so platforms can optimise for profit instead of revenue.
A shared event_id lets the browser pixel and the server event collapse into one conversion, so nothing is double-counted when both happen to arrive.
Illustrative payload. Your rules are written against your own schema and reviewed with you before anything ships.
threshold < 80% for 10m
cause meta_capi returning 502 · graph.facebook.com
notified #data-alerts · 04:12 CET
Tracking breaks quietly. Ours tells you.
The failure mode of server-side tagging is not the build — it is month four, when a developer ships a checkout change, an endpoint starts 502-ing, or a CMP update quietly flips a consent default. The container keeps returning 200. Nobody notices until the quarter is reported.
So we build these pipelines the way we build production infrastructure: SLOs with error budgets, alerts routed to a channel a human reads, dashboards you own, and a buffer that replays what was in flight when a destination went down.
This is the part of the category that is usually sold as a status page. It is the reason we exist.
- Event volume deviating from its own 7-day seasonal baseline
- Any destination returning non-2xx, with the response body captured
- Match quality or identifier coverage degrading on a rolling window
- Consent mix shifting after a CMP or banner change
- Container error rate, cold starts, memory pressure and cost burn
- Schema drift — a parameter that silently stopped arriving
Run it on our infrastructure, or on yours.
The same container, the same monitoring, the same code. The only question is whose cloud bill it lands on — and that is a procurement decision, not a technical one, so we do not charge you for making it either way.
| Target | Where it runs | Data residency | Setup |
|---|---|---|---|
| › Managed — EU | Our infrastructure, eu-west | European Union | 48 hours |
| › Managed — US | Our infrastructure, us-east | United States | 48 hours |
| › Google Cloud | Cloud Run in your project | Your region | 3–5 days |
| › AWS | ECS or EKS in your account | Your region | 3–5 days |
| › Microsoft Azure | Container Apps or AKS | Your region | 3–5 days |
| › Kubernetes | Helm chart, any cluster | Your cluster | 3–5 days |
We operate it.
You own it.
- Provisioning and Terraform / Helm definitions
- Tagging subdomain, DNS and certificate renewal
- Autoscaling, capacity and cost ceilings
- Container image and dependency patching
- Monitoring, alerting and on-call response
- Change review, staging and rollback
- The GTM account and every container in it
- Raw event data, in your own warehouse
- The cloud project, when you bring your own
- The infrastructure code and the runbook
- Your choice of region and retention period
- The right to leave, with a documented exit
Published prices. No discovery call required.
Fixed fees for fixed scope. If your setup genuinely does not fit one of these, we will tell you that in the first email rather than in the fourth meeting.
A measurement of your actual signal loss, a container audit, and a written remediation plan. Credited in full against a build if you go ahead within 60 days.
- Capture rate measured on your own traffic
- Per-browser and per-consent-state breakdown
- Match-quality score per ad destination
- Prioritised remediation plan with effort estimates
- 60-minute walkthrough with your team
5 business days
The full build on our infrastructure, then operated for you — monitored, patched, and on call. Setup is included; you are paying for the running, not the launch.
Requests per month. Pass a cap and we move you up a tier and tell you before we do — never an overage invoice. Above 5M, quoted on the assessment.
- sGTM container, tagging domain, DNS and TLS
- Conversions API layer across 7 destinations
- Server-side Consent Mode v2 enforcement
- Monitoring, SLOs and alerts into your Slack
- Change review with staging and rollback
- Documentation, runbook and recorded handover
Live in 48 hours
The same architecture deployed into your GCP, AWS, Azure or Kubernetes environment, handed over as infrastructure code. Monitoring is not included by default — add C-phase operations as a retainer if you want us to keep watching it.
- Terraform or Helm definitions you keep
- Conversions API layer across 7 destinations
- Server-side Consent Mode v2 enforcement
- Monitoring stack deployed in your account
- 30 days of post-launch support
- Optional operations retainer from $340 / month
3–5 business days
| Line item | Typical market rate | Ours |
|---|---|---|
| › Tracking / measurement audit | $2,000 – $8,000 | $950 |
| › sGTM + CAPI build, one-time | $2,000 – $5,000 | $1,250 |
| › Managed hosting, first year | $900 – $1,600 | $588 |
| › Ongoing maintenance | $200 – $500 / mo | included on managed |
| › Specialist consulting | $100 – $300 / hr | $105 / hr |
Ranges are from published pricing and rate cards of EU and US server-side tagging providers and analytics agencies. Cheaper exists — productised, self-serve setups start around $300–650 — but none of them include monitoring, and most bill hosting separately.
Data engineering
Warehouse streaming, real-time enrichment, offline and CRM conversion imports, app and server-to-server events, custom destinations.
Rescue work
An sGTM setup that was built by someone else and never delivered the recovery it promised. We diagnose it and quote the fix, not a rebuild.
Team enablement
Your analysts and developers trained on the container you now own, so the next change does not need us.
Managed hosting is capped per tier, never metered by surprise · high-traffic and high-availability tiers quoted on the assessment · all prices exclude VAT
Tell us what your stack looks like.
You will get a reply from the engineer who would do the work, usually within one business day, and it will contain an actual opinion rather than a calendar link.
We already have server-side GTM and it did not help. +
That is the most common reason people call us. A container that forwards GA4 and nothing else recovers almost nothing — the gains come from the CAPI layer, first-party identity, deduplication and consent handling around it. The assessment tells you which of those is missing before you spend anything on a rebuild.
How is this different from Stape or Addingwell? +
Those are hosting products, and good ones — we will happily run your container on either. What they do not sell is the architecture, the tracking plan, the CAPI and consent design, or someone who notices at 04:12 that purchases stopped arriving. That is the part we do.
What will the cloud actually cost us? +
For most sites under 5 million events a month, $25–80 a month of compute. We set a cost ceiling and alert on burn, so a traffic spike or a runaway loop cannot produce a surprise invoice. On managed hosting it is included in the monthly fee.
Do we lose control of our own tags? +
No. The GTM account stays yours, you keep publish rights, and the infrastructure code is handed over either way. We would rather you could replace us than depend on us.
Does this work with Shopify, WooCommerce or a headless stack? +
Yes, including Checkout Extensibility, and it is usually easier on headless because the events already exist server-side. Lead-gen and B2B stacks are well covered too — that is where offline conversion imports tend to matter more than the web tracking itself.
Is server-side tagging a way around consent? +
No, and anyone selling it that way is selling you a liability. Moving collection server-side changes where processing happens, not whether you need a legal basis. We enforce consent in the container so it is harder to get wrong, not easier to skip.
You talk to the people who build it.
server.events is the server-side practice at Brinkhorst Consulting in Zeist. There is no account layer between you and the engineering — whoever scopes your build is on the call when it goes live, and on the alert when it breaks.
We build measurement pipelines the way production infrastructure gets built, because that is what they are. My own background before server-side tagging was Kubernetes, observability and CI/CD — Prometheus, Thanos, Loki, Tempo, Pyroscope, Grafana — which is why this site talks about SLOs and error budgets where the rest of the category talks about dashboards.
That is also the honest reason monitoring is what we push hardest. It is the discipline we already had, and it is the part of a tracking pipeline that almost nobody else in this market offers at all.