Four minutes to create the service account. Sixteen months of Search Console history backfilled on the first sync. Two seconds for a domain that's already verified and permissioned. And two months — the number that causes more support tickets than the other three combined, because it's GA4's default data retention window, and almost nobody knows to check it before they connect.
The setup itself is short: one credential in Settings → Google Accounts, two connect buttons in Domain Management, and then you mostly forget this page exists. But that two-month figure is worth a full explanation, because it explains why some domains show a fat, useful Analytics history on day one and others show almost nothing for weeks — and it's not a platform bug when that happens.
One credential, granted once
You upload a Google service-account key — a JSON file, not a personal login. Robot identity, not a human OAuth token that expires or breaks when someone changes their password. Google Cloud issues it once and it keeps working until you delete it, which is also how the platform syncs at 3am without anyone logged in.
Creating one takes about those four minutes if you've never done it: new or existing project, IAM & Admin → Service Accounts → Create, download the key. The permission matters more than the dropdown makes it look — grant Viewer on the Search Console property and the Analytics property, nothing higher. I've watched teams grant Editor because it's the top option, and six months later nobody can explain why a robot account has write access to their GA4 config. Read-only is correct; the platform never touches your settings.
One key covers every domain under that Google Cloud project. If you're an agency running a dozen client sites, that argues for one service account per client rather than one for everything — offboarding a client becomes deleting a key, not auditing which domains quietly shared credentials with someone who just left.
Search Console: fast when it's fast, annoying when it isn't
- Open Connect on a domain. Search Console and Analytics each get a card, and Analytics has a "same as Search Console" shortcut, because one key usually covers both.
- Already verified with your service account granted access? Instant — a permission check, done in about two seconds.
- Not verified yet: automated DNS verification if you hand over your registrar's API key (Cloudflare, Route 53, a few others), or a manual TXT record you add yourself.
The manual path is where people get impatient. Propagation genuinely varies — ninety seconds one time, four hours another, depending on TTL and resolver caching. The platform polls, so you add the record and walk away. If a day passes with no verification, it's rarely propagation; it's a typo in the value or the record landing on the wrong zone (apex instead of subdomain, or the reverse). Run a `dig TXT` against what's actually live before blaming Google.
The API-key path skips all that by writing the record for you, but it means handing a third-party tool write access to your DNS — and if that DNS fronts production traffic, I don't think hesitating is unreasonable. The manual route costs a few minutes up front and buys you never thinking about it again.
Analytics, and the retention gap nobody warns you about
Analytics connects by discovery rather than verification — the platform looks for an existing GA4 property on the domain and connects if your service account has access, since GA4 permissions are already gated on Google's side. It can create a property if nothing exists, but only let it do that for genuinely new sites. If you migrated off Universal Analytics or have a property with years of history, connect to that one explicitly. A fresh property with three days of data is a much worse starting point than a nine-year-old one with seasonal patterns baked in, and the optimization loop leans on that history more than the connect flow implies.
Here's the gap that catches people: Search Console backfills up to sixteen months of query data on first sync, because Google keeps that much history server-side regardless of when you connected. GA4 doesn't have an equivalent guarantee — its backfill is capped by whatever the property's own data retention setting is, and that setting defaults to two months unless someone in your org changed it. So a domain can show sixteen months of impressions and clicks the moment you connect, and two months of sessions, on the exact same day, from the exact same setup flow. That's not a sync failure. It's Google's retention default doing exactly what it's configured to do, and the fix — if you want more than two months going forward — is changing the retention window in the GA4 property settings directly, not anything on this platform's side. Worth checking before you connect, not after you're confused by the mismatch.
Shared properties and what runs after
One more Analytics wrinkle: if your org runs a single GA4 property collecting for five sites — common when someone set up tracking years ago and nobody split it since — connection still works fine, but every query gets filtered by hostname behind the scenes. Not a checkbox, not something you can accidentally disable. It's why the dashboard always shows this domain's numbers and never the property's combined total.
Once both connections land, sync runs daily on a schedule you control (see the schedules chapter), and store analytics join automatically for anything built on the platform. The domain row shows pending, partial, or active — "partial" means one of the two connections is live and the other isn't, and that's your cue to go check which card is red instead of trusting the aggregate status.
Where it actually breaks
Nearly every ticket I've seen falls into three buckets, none exotic. One: the service account key is valid but scoped to the wrong Google Cloud project, so the permission check comes back empty even though the key itself uploads fine. Two: nobody actually added the service account's email — something like [email protected] — as a Viewer inside Search Console or GA4's own access settings; uploading the key to the platform doesn't grant it anything on Google's end. Three, sneakier: a domain gets reconnected under a new service account after the old one's deleted, but the schedule keeps quietly failing against stale credentials for a week before anyone notices the numbers stopped updating.
None of those are platform bugs — they're the ordinary cost of a robot needing permission on two separate Google products, and Google's own model doesn't make that obvious. Budget fifteen minutes for your first domain, not the two minutes the flow implies. Every domain after that is fast, because the credential and the muscle memory both carry over.
