Three different losses
Content blockers (uBlock Origin, AdGuard, Brave Shields, DNS-level blockers) match request hostnames and script URLs against public lists. connect.facebook.net, googletagmanager.com and analytics.google.com are on those lists; the page's own subdomain is not. The block happens before any code runs, so nothing on the page can tell you it happened — the visitor simply does not appear.
Browser tracking prevention (Safari ITP, Firefox ETP, Brave) does not block requests to first-party hosts; it limits state: third-party cookies are partitioned or blocked, script-written cookies expire after 7 days, and cookies set through a CNAME to a third-party address are capped as well. The visitor appears, but as a new visitor more often than reality.
Consent refusal is the visitor saying no. Nothing technical is broken; the data must not be collected. A setup that "recovers" this loss is not measurement, it is a violation.
How large each one is
It varies by audience. Technical and younger audiences in Germany show content-blocker rates well above the global average; Safari share drives ITP effects; consent rates depend on the CMP design and the site's trust. Rather than quoting industry averages, measure your own: compare the collector's accepted page views (events page, by source) with the page-view count the vendor tag reports for the same period — the gap is your content-blocker loss on that vendor's host. The consent page gives the refusal share directly, and the returning-visitor ratio by browser in your analytics shows the ITP effect.
What a first-party, server-side setup recovers
- Consented events blocked by list-based blockers. The SDK loads from your subdomain and posts to your collector; blockers do not match it. The consented event reaches your collector and, from there, the vendors' server APIs. Match quality depends on which identifiers consent allowed.
- Server-side delivery of what the browser could not send. Purchases and leads confirmed by the shop or the server are delivered even when the vendor pixel never loaded.
- Vendor outages and transient failures. The worker retries; the browser never did.
What it does not change: the anonymous id is written by the SDK under analytics or marketing consent, and Safari still caps script-written storage at seven days. Recognition of returning Safari visitors beyond that stays limited; Track does not work around it.
What it must not recover
- Refused consent. No click ids, no identifiers, no marketing destinations. The router enforces this per event; it is not a configuration you can switch off.
- Blocked vendor pixels as such. If the visitor blocks
fbevents.js, the browser side of Meta stays blocked. The server path receives the consented event, which is the design — but it does not inject the pixel by another route. - Fingerprinting to replace identifiers. Not implemented, not configurable. Unknown stays unknown.
Reading vendor "event match quality" honestly
Vendors score how many identifiers each server event carries. After moving to server-side, the score often rises because hashed e-mail from the order system is now included. That is a real improvement for consented purchases. It is not evidence that more people are being tracked; the consent page shows the same refusal share as before.
Practical steps
- Put the collector and SDK on a first-party subdomain (see the first-party domain guide).
- Send purchases and leads from the server with the same event id as the browser.
- Compare counts per browser on the data quality page; expect the gap to shrink for Chrome with blockers and Firefox, and returning-visitor recognition to improve on Safari.
- Leave the consent rate alone, or improve it with a clearer banner — never with technology.