How GA4 data flows to the US: a technical deep dive

What the GA4 script does in the visitor's browser

When a visitor lands on your site and GA4 is installed, the following happens within 200 milliseconds, even before the page is ready to read:

• gtag.js (about 70 KB after gzip) loads from https://www.googletagmanager.com.
• The script sets a first-party cookie _ga with a randomly generated visitor identifier that lives for two years.
• Another cookie is set per Property, in the format _ga_XXXXXXXXXX. It stores session identifiers and a timestamp.
• The script sends a first request to https://www.google-analytics.com/g/collect with a payload that contains the URL, referrer, browser info, screen size, language, country (derived from Google's IP database), the cookie values, and everything else gtag.js can see in the visitor's browser.
• If Google Ads conversion tracking is present on the site, a parallel request is made to https://www.googleadservices.com/pagead/conversion/.

What the payload actually contains

If you open the Network tab in devtools and inspect the request to/g/collect you see roughly this:

POST https://www.google-analytics.com/g/collect?v=2&tid=G-XXXXXXXXXX
  &gtm=...&_p=...&cid=1234567890.1717252800&sid=1717252801
  &dl=https%3A%2F%2Fyourcompany.com%2Fpricing
  &dr=https%3A%2F%2Fwww.google.com%2Fsearch%3Fq%3Dweb%2Banalytics
  &dt=Pricing%20%C2%B7%20Your%20Company
  &sr=1920x1080&ul=en-US&_uid=4567890&_geo=SE
  &en=page_view&ep.session_engaged=1&...

Translated into plain English:

• cid: client id, a randomly generated identifier that follows the visitor for two years. Persisted in the _ga cookie.
• sid: session id, new after 30 minutes of inactivity.
• dl, dr, dt: URL, referrer, page title.
• sr, ul: screen size and language.
• _geo: a two-letter country code derived from the visitor's IP before that IP is possibly anonymized.
• en: event name. For a pageview it says page_view; for a conversion purchase, and so on.
• ep.*: event parameters, everything you have sent along yourself via gtag('event', ...).

Where the packet ends up

The request lands at one of Google's edge nodes. For European visitors that is most often iad-gcm-014.1e100.net (Iowa) or fra02s27-in-f14.1e100.net (Frankfurt) depending on the moment. The edge node terminates TLS, does basic validation and forwards the packet to Google's analytics pipeline in the US.

In the pipeline the packet passes through the following hands inside Google's infrastructure:

• A pubsub queue for buffering.
• A Dataflow pipeline for enrichment (adds user-agent parsing, additional geo data, bot detection, ad-platform mapping).
• A BigQuery table for long-term storage (default 14 months in the GA4 console, longer if the customer pays for Analytics 360).
• If Google Signals is enabled: the packet is matched against Google accounts that are logged in to Google services (Gmail, Search, Maps, Android) to build cross-device identity.
• If Google Ads is linked to the GA4 property: the packet is forwarded to the Ads database for audience creation and remarketing.

What the "data is not personal data" argument misses

Google's standard answer when IMY or the courts ask is: "GA4 data is pseudonymized, not personal data." Technically that is not true.

The client id (cid) is a pseudonymous identifier that follows the visitor for two years. When it is combined with the URL, referrer, browser fingerprint (sr+ul+dr+ua), country and a possible Google account identity (via Signals), the pseudonymity becomes practically reversible.

The Court of Justice of the EU has been consistent on this point in several cases (Breyer C-582/14, Patrick Breyer v Germany C-93/22): if an actor has a realistic possibility of identifying a person via a pseudonym, that pseudonym is personal data. Google has that possibility through all of its other products.

Who has access in the US

Three categories of actors:

1. Google employees

Probably several thousand engineers have potential access to raw packets via debug and support tooling. In practice all queries are logged, but in a legal sense the access is possible.

2. Advertisers in Google's ecosystem

If you have Google Ads connected to your GA4 property, your audience data can be used by other advertisers via Audience Insights and Similar Audiences. Your competitor can therefore, indirectly, target ads at visitors who have been on your site.

3. US authorities

Under FISA 702 and Executive Order 12333, the NSA and other federal agencies can demand access to data held by US companies without the affected EU citizen ever finding out. The Data Privacy Framework (DPF) establishes a new complaint mechanism (DPRC) but does not change the underlying legislation.

What is literally "sold"?

The standard reflex from Google's sales team is "We do not sell your data." That is true in a very narrow sense. Google does not sell your raw-packet database to a third party. What they do is use your data to improve their own advertising products, which they then sell to other advertisers.

That distinction may be important legally for Google, but for you as the data controller the end result is the same: your visitors' data powers Google's ad engine. You are a free data producer in a value chain where the money changes hands at the other end.

What you actually send every month

For a site with 10,000 unique visitors per month and a typical session of 3 pageviews plus 2 events, the following is sent to Google:

• 50,000 requests per month to /g/collect.
• ~10 MB of raw data (50,000 × 200 bytes/payload).
• ~10,000 unique cid values, each linked to a browser fingerprint, pages visited, links clicked and any Google account identities.
• 1 dataset per month fed into Google's ad-audience system.

All of this so that in the GA4 console you can see a bar that says "10,000 visitors." As we have written before, GA4 would actually show around 4,500 if you subtract those who rejected the cookie banner. But 50,000 packets have already been sent to manage to count 4,500.

What Spårlös sends instead

For the same 10,000 unique visitors per month, Spårlös sends:

• ~30,000 requests per month to a Swedish endpoint (same number of pageviews, no extra event overhead).
• ~3 MB of raw data (less per request because the payload is minimal: e, s, u, r, w, h, l, d and nothing else).
• No cookies. No long-lived identifiers. The visitor's IP is deleted immediately after the country lookup.
• No Google account, no Ads audience, no cross-device matching.
• No US-based sub-processors in the data path. The entire processing happens within the EU.

Concrete action plan

If you are reading this as the technical lead:

• Open devtools on your own site. Inspect the request to /g/collect. The first thing that shocks people is usually the size of the payload.
• Count the number of requests per pageview. Many sites have GA4 plus Google Tag Manager plus Google Ads plus Facebook Pixel plus LinkedIn Insight. Each one sends its own request. For an active site that adds up to 50 to 200 third-party requests per pageview.
• Measure the performance impact in Lighthouse. GA4 alone typically costs 0.3 to 0.5 seconds in Total Blocking Time.
• Discuss with your data protection lead whether the DPF assessment is documented in a TIA (transfer impact assessment).

If the picture above feels uncomfortable, read on: Why Swedish companies are switching, Schrems II in practice, or jump straight to a side-by-side comparison.