The replacement myth
Since 2024, server-side tagging (sGTM, Meta CAPI, TikTok Events API) has become the standard recommended by every ad platform. Rightly so: it gets around ad blockers, withstands iOS restrictions and significantly improves the quality of conversion data.
The dominant message is simple: "go server-side and your tracking problems are solved." That message is incomplete. Server-side solves one set of problems, creates others, and misses some that only client-side can detect.
What server-side does well
The gains are real and measurable. Here's what we see on sites that migrate to a properly implemented server-side setup:
- Match rate: from 60-80% (client-side only) to 93-95% (server-side)
- Volume of tracked conversions: one e-commerce brand went from 1,724 to 4,512 tracked purchases per month (+162%) after turning on Meta CAPI + sGTM
- Resistance to blockers: ad blockers block 25-40% of client-side requests. Server-side gets through 100% of the time
These figures justify the investment, but they leave out what happens in the browser.
What server-side can't see
Server-side receives the data your server sends it. It knows nothing about what happens in the user's browser. Here's the detailed comparison:
| Signal | Client-side | Server-side |
|---|---|---|
| Meta/GA4/TikTok pixel actually fires | Yes: checks real execution | No: assumes the server sent it |
| CMP blocking (cookie banner) | Yes: detects refusal and blocking | No: doesn't know whether the pixel was blocked |
| JavaScript error on the page | Yes: detects script conflicts | No: the server doesn't see JS errors |
| Real LCP / Web Vitals | Yes: measured in the browser | No: no front-end performance data |
| Stock status shown to the user | Yes: reads the page DOM | No: reads the server catalog (can diverge) |
| Active ad blocker | Yes: detects the blocking | No: bypasses it without knowing |
| Amount displayed vs amount sent | Yes: compares DOM and dataLayer | No: only sees the server dataLayer |
| Full user session (navigation) | Yes: follows the real journey | Partial: depends on the events sent |
A real case that shows the problem
A fashion e-commerce site (€35M in annual revenue, €80,000/month paid budget) migrated to sGTM + Meta CAPI in January 2026. The tracking results were excellent: +47% attributed conversions, Meta ROAS apparently up from 2.1 to 3.4.
Meanwhile, a front-end deployment introduced a JavaScript conflict between their new carousel and the client-side GTM script. The consequences:
- LCP climbed to 8.2 seconds on mobile product pages
- The paid mobile bounce rate rose from 38% to 61%
- The
add_to_cartdataLayer event stopped firing on Safari
Server-side kept sending the final conversions (the ones that still made it to checkout). The dashboard showed ROAS going up. Nobody saw the problem for 14 days.
Estimated impact: €12,000 of paid budget wasted on mobile traffic that bounced immediately because the page was too slow.
The visibility paradox
The more you automate server-side data sending, the less you see of what actually happens in the browser. Server-side increases the amount of data sent to the platforms, but it can mask problems that directly hurt the user experience, and with it real performance.
Meta and Google's bidding algorithms receive more conversions. They optimize better, on the surface. But if 30% of your mobile traffic has a degraded experience that server-side can't detect, bids rise on audiences that no longer convert.
How they complement each other in practice
The ideal setup combines both approaches. Each one covers the other's blind spots:
Server-side to:
- Send conversions to ad platforms with the highest possible match rate
- Get around ad blockers and browser restrictions
- Enrich first-party data (Enhanced Conversions, Advanced Matching)
Client-side to:
- Check that pixels actually fire in the browser
- Measure Web Vitals (LCP, INP, CLS) on paid traffic
- Detect JavaScript errors that break the purchase journey
- Confirm that the CMP isn't blocking tracking by mistake
- Cross-check paid traffic against the stock status displayed
Korvus sits on the second side. It's a lightweight client-side snippet (under 5 kb) that watches exactly what server-side can't see: did the pixel actually fire in the user's browser? Was the page fast enough? Was the product in stock when the paid visitor landed?
The cost of the blind spot
To quantify the impact, here's what the lack of client-side monitoring costs on a site with a €50,000/month paid budget:
| Undetected problem | Average time to detection | Estimated cost |
|---|---|---|
| Dead pixel (JS conflict) | 72 hours | €5,000 to €10,000 |
| LCP > 5s on paid mobile | 14 days | €8,000 to €15,000 |
| CMP blocking a pixel after an update | 7 days | €4,000 to €8,000 |
| Sponsored product out of stock | 48 hours | €1,500 to €3,000 |
Server-side can't see any of these problems. It keeps sending what it can, and nobody sees what's missing.
Key takeaways
- Server-side lifts the match rate from 60-80% to 93-95%: an investment that pays for itself
- But it can't see browser-side problems: LCP, JS errors, CMP blocking, real stock status
- A problem invisible server-side can cost €5,000 to €15,000 before it's detected manually
- Combining server-side + client-side is the only approach that covers every blind spot
- Client-side monitoring has to be lightweight (no performance impact) and focused on the signals server-side ignores