Mostly, yes. You can't see someone else's server, but server-side setups leave fingerprints in the browser. Here are the external signals - and where they stop.
Server-side tracking - server-side Google Tag Manager, Meta's Conversions API (CAPI), first-party data collection - is deliberately harder to see than a browser pixel. That's the point of it: move the tracking off the visitor's browser so ad blockers, ITP and consent tooling can't strip it. So can you tell from the outside whether a website uses it? Mostly yes. You can read the signals with nothing but your browser's DevTools - here's what to look for, and where external detection hits its limit.
Open DevTools → Network, reload the page and complete an action, then look for these tells:
In the Network tab, sort by Domain. Data flowing to first-party subdomains instead of the platforms' own domains is the headline clue.
Filter for /tr/, open a request and look for eventID in the query string. Present = a server counterpart almost certainly exists.
On the main document request, check Response Headers for Set-Cookie lines setting analytics cookies - a sign the server, not JS, owns them.
You can confidently infer that server-side tracking exists, but you can't fully verify its quality from the outside. What you can't see without a real transaction or account access:
That's exactly the line between a quick external check and a full audit with a real test purchase.
duckmetric looks for these signals automatically - first-party endpoints, CAPI eventID presence, server-set cookies and proxied requests - and tells you whether a site appears to use server-side tracking, plus what a quick check can and can't confirm.
Mostly yes. Using browser DevTools you can spot first-party collection endpoints, Meta CAPI eventIDs, server-set cookies and proxied requests. You can confirm server-side tracking exists, but not fully verify its quality without a real transaction or account access.
Instead of requests to google-analytics.com or facebook.com/tr, you'll see them go to a subdomain of the site itself - like sgtm.example.com or a /g/collect path on the site's own domain. That's server-side GTM proxying the data.
Almost always. The eventID exists so a browser Pixel event and a server-side CAPI event can be matched and de-duplicated - so its presence strongly implies a server event is being sent too.
To recover conversions lost to ad blockers, Safari/ITP and consent tooling, to extend first-party cookie lifetime, and to control what data leaves for third parties. It generally produces more complete, more durable tracking than browser-only setups.
Related: Meta Pixel & CAPI audit · how to check GTM tracking · full audit
Paste any URL and check what fires, including first-party and CAPI signals.