Understand what actually worked

Runner plans your GA4 setup, waits for a go-ahead, then checks its own work

Somebody created the GA4 property two years ago, the web stream still points at a staging domain, and nobody remembers who set enhanced measurement. Connect your Google account from the product's analytics settings, and the default connection only reads.

If the property is fine, point the product at it. That changes nothing outside Runner. If it isn't, Runner reads what already exists and draws a plan for the property, the web stream and enhanced measurement, marking each as create, adopt, update, leave alone, or a conflict to settle first.

Nothing changes in Google until the plan is approved. An approval left unapplied for 72 hours expires, and if what the plan was drawn against has changed since, applying it is refused rather than guessed at.

The check reads the live configuration back, changes nothing, and compares it with what's stored and approved: the property is reachable, the stream exists, the measurement ID matches, the stream's address matches your production domain, and enhanced measurement is set the way the plan said.

Runner holds GA4 up against your own events, and names the reason they differ

GA4's daily event counts and sessions sync into Runner, and your product's analytics settings compare them with your own first-party events, one day at a time.

A day that differs gets a named reason when one exists: GA4 withheld the figures for privacy, the day is still inside GA4's processing window, the sync is paused or hasn't reached that date, bot or test traffic accounts for it, or consent-blocked events do.

The rule behind the labels is strict on purpose. An explanation has to cover the difference, so a reason that accounts for a sliver of a large gap leaves the day unresolved. A day GA4 withheld is never compared at all, and if Runner's own side is unreadable, the page says it couldn't compare instead of drawing a gap out of zeros.

Every number starts as an event you hold, with its consent state on it

A browser event is written only when its consent snapshot allows it: granted, along with the moment consent was recorded, or not required. Anything else is refused and counted, which is exactly what the consent-blocked reason above reads.

Events your own systems send are held to four checks, in order. The event must declare its consent state, with no default to fall back on. Its payload may not carry fields such as an email, a phone number, a message or a transcript, checked at any depth. Its name has to be in a fixed catalog that changes only in code. And its payload has to match that name's schema. A refused event is kept with the reason, never dropped quietly.

Holdouts run on the same records. Set a share of an audience to hold out, and each account's group is worked out from the audience and the account alone, so re-evaluating membership never shuffles anyone. Raise the share later and everyone already held out stays held out.

Questions buyers ask