Appearance
Google Analytics 4 integration
The Google Analytics 4 integration pulls daily aggregates into your own data warehouse so they can be compared against first-party pageviews for the same day and the same page.
Why it pulls aggregates and not raw events
Google already ships a raw event export. Rebuilding that would be rebuilding something the vendor gives away. This integration fetches the three things that export cannot give you.
- Aggregates as Google defines them. Sessions, engaged sessions and channel grouping are computed by Google. Reimplementing that in SQL produces numbers that disagree with the customer's own screen, and a report that disagrees with the customer's screen is worthless however correct it is.
- Backfill. The native export is forward-only from the day it was switched on. The reporting API is not.
- Fleet orchestration. Running the same pull uniformly across many properties.
What the GA4 integration pulls
| Dimension or metric | Grain |
|---|---|
| Sessions | Per day, per property |
| Engaged sessions | Per day |
| Default channel grouping | Per day, per channel |
| Page path and page views | Per day, per page |
| Source and medium | Per day |
What the GA4 integration can be used for
GA4 can be used for measuring your own measurement. GA is consent-gated and blockable. A first-party tracker is neither. Running both against the same day and the same page turns the difference between them into a number instead of a suspicion, and on consent-heavy sites that number is usually much larger than people expect.
GA4 can be used for reconciling with agency and stakeholder reports, because it carries Google's own definitions rather than a reimplementation of them.
GA4 can be used for historical backfill when a first-party tracker is added to a site that has been live for years.
GA4 can be used for channel grouping continuity, so the channel labels in a new warehouse match the labels people are used to reading.
GA4 can be used to make the case for consent-independent analytics, with a number instead of an argument.
Filter bots on both sides before you quote a gap
GA filters known bots. A raw first-party event stream does not. Comparing the two unadjusted overstates the gap, sometimes by a lot. Apply the same bot filter to both populations before the number leaves the room.
GA4 combined with other integrations
| Combination | What it gives you |
|---|---|
| GA4 + first-party tracker | The measurement gap, per day and per page, once both sides are bot-filtered |
| GA4 + Search Console | Impressions and clicks against sessions, so you see where the drop-off is |
| GA4 + Shopify | Sessions against orders, with revenue coming from the shop rather than from a tag |
| GA4 + Google Ads | Paid sessions in Google's own definition, next to spend and to real revenue |
What you need to connect GA4
- The numeric property id. Not the measurement id that starts with G, which identifies a data stream rather than a property
- Viewer access on the GA property for the connector's service identity
A dry-run mode validates the credential, the property id, the API shape and the transform without needing any warehouse write permission at all, so a wrong property id surfaces before anyone grants access to anything.
Frequently asked
Does this replace the free BigQuery export from GA4? No, and it is not trying to. The export gives you raw events forward from the day you enabled it. This gives you Google's own aggregates, backfilled.
Why do the numbers differ from my first-party tracker? Because they measure different populations. GA sees consented, unblocked visitors. A first-party tracker sees the rest as well. The difference is the point.
Can I connect more than one property? Yes. The integration is designed to run uniformly across a set of properties.