Your Analytics Tool Contacts 7 Domains. Here Is Why That Matters.

Every time a visitor loads your site, your analytics tool phones home. Not to one server — to several. Each external domain your analytics contacts means a DNS lookup (50–100 ms), a TLS handshake (100–200 ms), a data transfer to a third party, and — if that domain resolves to a US server — a potential GDPR cross-border transfer issue that your DPO needs to document.

We opened Chrome DevTools on a clean browser profile and mapped every unique domain contacted by nine analytics tools. Then we ran dig on each domain to identify where the data actually goes.

What we mapped

For each tool, we recorded: the total number of unique domains contacted, how many of those are third-party (not your own domain), where the data lands geographically, and the specific domain names involved. The methodology is reproducible — steps are at the bottom of this post.

The results

The range is stark. SealMetrics contacts one domain — your own. Adobe Analytics contacts four third-party domains, all resolving to US infrastructure.

The performance cost

Every unique domain requires two network round-trips before a single byte of data moves: a DNS resolution (50–100 ms) and a TLS handshake (100–200 ms). That is 150–300 ms per domain, on the first visit.

Adobe Analytics contacts 4 domains. That is 600–1,200 ms of network overhead before analytics data even begins to transfer. GA4's 3 domains cost 450–900 ms. SealMetrics, with one first-party domain, costs 150–300 ms — and that domain is already resolved because it is a subdomain of your own site.

On a mobile connection with 80 ms RTT, four domains add nearly a full second of latency. That latency competes with your content, your images, your fonts. It is not theoretical — it shows up in Largest Contentful Paint and Interaction to Next Paint.

The privacy and GDPR cost

Post-Schrems II, every data transfer to a US entity requiresStandard Contractual Clauses plus a Transfer Impact Assessment. Each third-party US domain is a legal surface your organization must document and defend. Your DPO needs to account for each one.

GA4 sends data to three Google-owned domains, all resolving to US infrastructure. Adobe sends data to four domains — including dpm.demdex.net, Adobe's audience management platform, which processes data in the United States. Each domain is a separate data processor relationship that requires GDPR compliance documentation.

Zero third-party domains means zero cross-border transfer issues. One domain — your own — means one data processing relationship: yours.

The data residency question

Where do the bytes actually go? We ran traceroute and GeoIP lookups on every domain in the table.

GA4's primary endpoint — googletagmanager.com — resolves to Mountain View, California (216.58.215.136). Its collect endpoint region1.google-analytics.com resolves to Austell, Georgia (216.239.34.36). Note that google-analytics.com serves from a CDN that may resolve to EU nodes (we measured Frankfurt), but the data processing still occurs on Google's US infrastructure. Adobe's domains use CDN and AWS endpoints — assets.adobedtm.com serves via Akamai (we measured Madrid), dpm.demdex.net resolves to AWS Dublin (54.246.175.19). CDN edge location does not equal data residency — the processing and storage may still happen elsewhere.

SealMetrics resolves to the customer's own subdomain (e.g. collect.yourdomain.com), which points to EU infrastructure in Barcelona, Spain (91.242.131.41, Noraina) via a CNAME record. The data residency is verifiable: run dig collect.yourdomain.com and check the IP yourself.

First-party vs third-party collection

The distinction matters for more than compliance. Third-party domains are the primary target of ad blockers, browser privacy features, and content security policies. When your analytics runs on googletagmanager.com or demdex.net, every blocklist in the world knows to intercept it.

SealMetrics uses cookieless first-party collection through a CNAME on the customer's own domain. To the browser, to DNS resolvers, and to ad blockers, it looks like a first-party request — because it is one. No third-party domain to block, no cross-border transfer, no additional DNS lookups. The collection architecture is designed so that the analytics request is indistinguishable from any other request to your own site.

How we mapped this

The test is reproducible. Here are the steps:

1. Open Chrome with a clean profile (no extensions, no cached data).
2. Open DevTools → Network tab. Enable “Preserve log” and disable cache.
3. Install each analytics tool on a minimal HTML page, one at a time.
4. Load the page. Record every unique domain in the Network tab.
5. Run dig [domain] on each domain to get the resolved IP address.
6. Use GeoIP lookup on each IP to determine the physical location of the server.
7. Classify each domain as first-party (your domain) or third-party (vendor domain).

No special tools required. Anyone with Chrome and a terminal can verify these results in under an hour.

The bottom line

Every external domain your analytics contacts is a performance penalty, a privacy liability, and a legal surface. Four domains means four DNS lookups, four TLS handshakes, four third-party data processors, and four entries in your Transfer Impact Assessment. One domain — your own — means none of that.

SealMetrics collects data through your subdomain, stores it in EU infrastructure, and contacts zero third-party domains. Read the full security and compliance architecture or calculate how much data your current setup is losing.