Aliceby TranX
← All posts
GA4AttributionField notes

The 3 GA4 Bugs Quietly Stealing Your Signup Credit

Blake Wu··7 min read
Share

Imagine your office receptionist signed for every package that arrived, and your ops team — seeing the same name on every delivery slip — concluded the receptionist was your biggest supplier. Absurd. Yet that is, almost exactly, what GA4 is telling a large share of SaaS companies about where their signups come from.

Delivery couriers labelled LinkedIn, Google, Reddit and Email hand parcels to a receptionist, while an analyst points at a chart showing the reception desk as the source of 100% of deliveries.
Every channel hands its signup through the same door, and the door gets the credit. This is what GA4 reports when your login flow bounces through an auth provider.

We build Alice, an AI growth agent for product-led B2B SaaS, which means we spend a lot of time inside GA4 properties. Three attribution bugs show up so often that we now check for them before we trust any channel report. They share one nasty habit: they corrupt exactly the sessions that convert and leave the boring ones alone — so the totals stay plausible, nobody questions the dashboard, and the wrong channel quietly gets the credit.

To be precise about the word: none of these are GA4 malfunctioning. Every one of them is GA4 doing exactly what it was told, on a setup nobody finished telling it about. They are bugs in your funnel's measurement, which is worse in one specific way — nothing errors, nothing alerts, and the numbers keep arriving on schedule looking completely reasonable.

Bug #1: The OAuth bounce (the receptionist)

A visitor finds you on LinkedIn, reads your site, clicks “Sign in with Google”. On the way into your app they pass through Google's login page, accounts.google.com. When they come back, GA4 treats them as a brand-new visitor referred by that login page, and starts a fresh session credited to it. LinkedIn — the channel that actually earned the signup — gets nothing.

The cruel part: this only happens to people who log in. Which is to say, your converting visitors. When we ran our detector against a property with a standard “Sign in with Google” button, a third of all sessions carried this signature. Nothing was misconfigured. This is GA4's default behavior until someone tells it otherwise — and almost nobody does, because nothing looks broken.

Bug #2: The subdomain break

The standard SaaS topology: marketing site on www, product on app. GA4's documentation promises that journeys across your own subdomains stay stitched together automatically — and they do, as long as the exact same tag runs on every subdomain a visitor touches. Then a hosted login page that can't carry your tag shows up mid-journey, or a consent banner's “accept” doesn't carry across the subdomain boundary, and the session snaps in half. The first half ends on your marketing site, unconverted. The second half begins on your login page, out of thin air, with source “direct” — and it absorbs the signup.

The giveaway is beautifully simple: GA4 reports sessions starting on your login page. Set aside password managers and bookmarks, and ask how a stranger arrives at /account/login as their first-ever page. They don't. Unusual volume there is a measurement wound, not a traffic source. A 20-year analytics practitioner we compared notes with measured a quarter of a client's sessions resetting at exactly this hop.

Bug #3: The self-referral

Your own domain listed as one of your traffic sources. GA4 is supposed to ignore referrals from your own site automatically, so when one appears anyway, it means the automatic detection has failed somewhere — usually a subdomain missing the tag. Think of it as your own phone number showing up on caller ID. The call itself is harmless. The fact that it happened at all is the information.

Why only a portion of sessions break

A fair question: if these bugs are mechanical, why is it a third of sessions and not all of them? Because each bug is deterministic per condition, and your visitors are spread across conditions — like a bridge with one broken lane. Every car in that lane goes down; most traffic is in the other lanes, so the bridge looks mostly fine. Visitors who accepted your cookie banner carry their session across the hop; the ones who declined mint a fresh one. Chrome carries cookies that Safari's tracking prevention has already expired. Visitors who log in through OAuth hit bug #1; visitors who go straight to the app never cross the seam at all. The share of broken sessions is itself diagnostic: it roughly measures how much of your audience sits in the breaking conditions — and if it jumps after a deploy, something moved a lane's worth of traffic into the broken one.

The five-minute check

In GA4, pull a report of landing page by session source for the last 28 days. You're looking for two things: an auth domain (accounts.google.com, appleid.apple.com, your own auth.* subdomain) appearing as a session source, and sessions starting on /login, /signup or /account/* pages with source “(direct)”. Either one, and you've found it.

The sixty-second fix (for bug #1)

GA4 Admin → Data streams → select your web stream → Configure tag settings → “List unwanted referrals” → add your auth domains. That tells GA4 to stop treating the login bounce as a referral, so sessions keep the channel that actually earned them. One caveat: the fix is forward-only. Historical data stays wrong forever, which is very GA4 of it — and it's also the argument for fixing it this week rather than after the next campaign you'll want to measure.

Bugs #2 and #3 are more setup-specific: uniform tagging across subdomains, consent state stored at the root domain rather than per-subdomain, and — the deeper cure for the OAuth bounce — a login flow that never navigates away from your page in the first place.

Why we turned this into software

A one-time audit rots. The next deploy, the next consent-banner tweak, the next subdomain quietly reintroduces one of these — and the dashboard goes back to telling a confident, internally consistent, wrong story. Worse, any AI reading that data inherits the confidence without the wrongness ever being visible.

So we encoded the whole family as deterministic detectors inside Alice. They run when you connect GA4, again every week, and whenever the fingerprints surface mid-analysis. Findings arrive quantified (“157 of your 465 sessions lost their channel to the OAuth bounce”), with the exact setting to click, they land on your action-items list, and the following week's check reports whether the fix actually moved the numbers. Detection lives in code, the judgment stays yours, and the receipts come back on their own.

Run the five-minute check on your own property this week. If the receptionist is signing for your packages — and with OAuth login, she probably is — the fix costs you sixty seconds. Or connect your GA4 to Alice and she'll run the whole family of checks for you, this week and every week after.

Want these checks to run themselves?

Alice runs the whole family of attribution detectors when you connect GA4, again every week, and reports back whether your fix worked. Free to try, 30 seconds to connect.

Try Alice Free