With the growing adoption of server-side tagging, many people assume that using a custom domain automatically means the data is collected server-side.
It sounds logical — but the reality is more nuanced.
There are two independent dimensions to consider:
- Where the data is collected: client-side vs server-side
- Which domain is used for collection: Google, Adobe, or your own
Case 1: Google Analytics 4
By default, GA4 sends its hits to:
https://www.google-analytics.com/g/collector its regional variant:
https://region1.analytics.google.com/g/collect
These are Google-owned endpoints, used in all standard client-side implementations.
The browser sends the hits directly using gtag.js or gtm.js.
No server intervention is involved on your side.
When the Domain Changes
If you notice requests going to:
https://analytics.mybrand.com/g/collect
or
https://ga.mybrand.fr/mp/collect
then a custom collection domain has been configured.
For this setup to work, you need to:
- Create a DNS record (CNAME or A record) pointing your domain to a server container (usually a GTM Server-Side container, hosted on App Engine, Stape, or a reverse proxy);
- Update the Server Container URL setting in your GA4 tag;
- Configure a GA4 Client in the server container to receive the hits.
The browser now sends the data to your own domain, and your server container forwards it to Google.
This is the typical server-side tagging architecture.
Why “Probable,” Not “Certain”
Seeing a custom domain is a strong indicator of a server-side setup — but not an absolute guarantee.
There are several alternative configurations that mimic the same network pattern.
| Scenario | Description | Nature |
|---|---|---|
| Simple reverse proxy | The domain analytics.mybrand.com simply redirects requests to www.google-analytics.com. No processing, just a pass-through. | Not real server-side |
| Edge function / CDN worker | Requests are routed through a Cloudflare or Akamai edge function. This acts as a relay, not a tagging container. | Network intermediary |
| Internal micro-gateway (Google Gateway, API) | The domain receives hits and forwards them to Google via the Measurement Protocol API. | Partial server-side |
| Self-hosted script + redirect | Hosting gtag.js locally and proxying the requests. | Cosmetic masking |
These solutions look like server-side implementations from the outside,
but they don’t involve actual server-side data handling or logic.
That’s why “server-side probable” is the right term.
Case 2: Adobe Analytics
Adobe has offered custom tracking domains for a long time, through the variables:
s.trackingServer = "metrics.mybrand.com";
s.trackingServerSecure = "smetrics.mybrand.com";
These are created by Adobe Customer Care and configured via CNAME records pointing to Adobe’s servers.
This setup allows cookies to be considered first-party, since the domain belongs to your site.
However, the data collection remains client-side:
the AppMeasurement.js library runs in the browser and sends hits directly.
You’re not performing any server-side processing — only domain masking.
When the Experience Cloud ID (ECID) service is enabled, Adobe uses the demdex.net domain to synchronize user identifiers.
The main ID cookie can be regenerated or matched through a master ID (MID), but all of this still happens in the browser.
Summary Table
| Context | Example Domain | Collection Type | Cookie | Nature |
|---|---|---|---|---|
| GA4 default | www.google-analytics.com | Client-side | 3rd party | Standard |
| GA4 custom (true server-side) | analytics.mybrand.com | Server-side | 1st party | Server container |
| GA4 custom (proxy/gateway) | analytics.mybrand.com | Proxy / Edge / API forwarding | 1st party | Intermediate |
| Adobe default | metrics.adobedc.net | Client-side | 3rd party | Standard |
| Adobe with CNAME | metrics.mybrand.com | Client-side | 1st party | Masking |
| Adobe ECID (demdex) | dpm.demdex.net | Client-side | cross-domain | Master ID |
Conclusion
Seeing your own domain in network requests is often a sign of a server-side setup, but not definitive proof.
Some configurations (proxies, gateways, CDN workers) can mimic the same pattern without real server-side processing.
Conversely, using Google’s default domain doesn’t mean you can’t be server-side — you could still forward data from your own backend to www.google-analytics.com via the Measurement Protocol.
In short:
- Default GA4 domain → client-side
- Custom GA4 domain → server-side probable (unless proxy/gateway)
- Custom Adobe domain → first-party cookie, not server-side
Changing the domain affects visibility and cookie ownership.
Switching to server-side impacts data control and processing logic.