If you are still relying entirely on browser-side pixels in 2025, you are likely missing 30–60% of your conversion data. iOS privacy changes, Chrome's third-party cookie deprecation, and the rise of mainstream ad blockers have made client-side tracking unreliable at scale.
Server-side tracking moves the data collection off the user's browser and onto your server, where blockers cannot reach it. Here is how to implement it without breaking your existing setup.
Why browser-side tracking fails
When a visitor hits your site, their browser fires a tag (Meta Pixel, Google tag, etc.) directly to the ad network. That request can be blocked by:
- Browser extensions (uBlock Origin, Privacy Badger, AdBlock Plus)
- Safari's Intelligent Tracking Prevention (ITP)
- iOS 14.5+ App Tracking Transparency
- Firefox's Enhanced Tracking Protection
- Network-level DNS blocking
Depending on your audience, ad block rates can range from 15% for general e-commerce to over 40% for technical or developer audiences. Every blocked pixel is a conversion your attribution model never sees.
How server-side tracking works
Instead of the browser firing directly to Meta or Google, your server acts as a middleman:
- User takes an action on your site (purchase, sign-up, page view)
- Your site sends that event to your own server endpoint
- Your server forwards the event to Meta CAPI, Google Measurement Protocol, or any other destination
- Because the request comes from your server (not the user's browser), blockers cannot intercept it
Setting up server-side GTM
Google Tag Manager's server-side container is the most practical starting point for most businesses. You deploy a tagging server (on Google Cloud Run, which has a generous free tier) and route your events through it.
Step 1: Create a server container in GTM. Go to Admin → Create Container → Server.
Step 2: Provision the tagging server. GTM will guide you through deploying to Google Cloud Run. The default configuration handles auto-scaling and costs essentially nothing under 10M requests per month.
Step 3: Configure your web container to send to the server. Add the GA4 client to your server container, then update your web container's GA4 tag to point at your server URL instead of Google directly.
Step 4: Add destination tags. On the server container, add tags for each destination: Meta CAPI, Google Ads, LinkedIn Insight Tag, etc.
Meta Conversions API (CAPI)
Meta's CAPI is the most impactful server-side implementation for most advertisers. With iOS 14.5 changes, many Meta advertisers saw 20–50% drops in reported conversions. CAPI restores that signal.
The key is deduplication: you run both browser pixel AND CAPI in parallel, and Meta deduplicates them using the event_id parameter. This gives you maximum coverage without double-counting.
{
"data": [{
"event_name": "Purchase",
"event_time": 1697382000,
"event_id": "order_12345",
"user_data": {
"em": ["hashed_email"],
"ph": ["hashed_phone"]
},
"custom_data": {
"currency": "USD",
"value": 149.00
}
}]
}Validating your setup
Before going live, validate using these tools:
- GTM Preview mode: confirm events fire on the server container
- Meta Events Manager: check the Event Match Quality score (aim for 6.0+)
- GA4 DebugView: confirm events arrive with correct parameters
- Postman or curl: test your server endpoint directly
A common mistake is forgetting to pass hashed user data (email, phone) with server events. Hashed PII dramatically improves Meta's ability to match events to users, which directly improves your ROAS.
What to expect after implementation
Most clients see a 15–35% increase in reported Meta conversions within 7 days of enabling CAPI alongside their browser pixel. Google Ads typically sees a 10–20% improvement in conversion reporting. The improvement varies based on your audience's ad-block rate and device mix.
More importantly, your bidding algorithms now have more signal to work with, which means smarter optimisation and better returns over time.