Google Analytics
Source Analytics

Google Analytics 4

Every event your site sends — unsampled and event-level, in a database you own instead of an interface that estimates.

Insightlytics ingests your GA4 data — every event with its parameters, traffic sources, devices and ecommerce items — through the native BigQuery export, the Data API or both. We rebuild sessions with one documented definition, version your channel rules and model the raw events into session, funnel and revenue data models, refreshed daily. You get report-ready tables and the accumulated history; we run the ingestion, the sessionization SQL and the monitoring. Everything is written to a database you own — BigQuery today, with more warehouses on the roadmap.

What we ingest

GA4 exposes two grains of the same property, and they arrive as different things. We land the raw tables first and model on top — so you keep the source rows, not just our interpretation of them.

  • events_YYYYMMDD Native export

    One row per event, unsampled, with the parameter and user-property structs intact. This is the grain that makes custom sessionization and funnel logic possible at all.

  • events_intraday_YYYYMMDD Native export

    The same shape for the day in progress, replaced once the daily table lands. Useful for a same-day check, never treated as the historical record.

  • users_YYYYMMDD Native export

    User-level dimensions and lifetime aggregates Google maintains alongside the event stream, on properties that have user-data export switched on.

  • Data API reports API

    Report-grain pulls across the dimension and metric sets. This is the route that reaches topline history from before the export link — which the export itself can never recover.

Which of these you end up with depends on the route, and that decision is covered further down, in how we work with GA4 data.

The problems we solve

GA4’s raw data is built for completeness, not for analysts. These are the problems every team hits between the export and a report — and the ones this pipeline is built around.

Why is the raw GA4 events table so hard to query?

One row per event, with parameters packed into arrays of key-value structs — a schema built for completeness, not for analysts. Simple questions require UNNEST, grain decisions (event? session? user? day?) and knowledge of which parameters your implementation actually sends.

That knowledge is precisely what our modeling layer encodes, once, instead of every analyst rediscovering it per query. The raw export stays raw; the data models are what your team actually touches.

Why doesn’t the GA4 export have sessions — or channels?

The export has no session table and no default channel grouping. The interface’s sessions are estimated at report time; yours must be rebuilt from ga_session_id, and channel rules must be rewritten from source and medium — the export carries only the raw fields.

We rebuild sessions with one documented definition and version your channel rules in your database, so ‘Paid Social’ means the same thing in every data model, every month — and the sessionization SQL is our job to write and maintain, not yours.

Because the export only flows forward — the link can’t be created retroactively, and pre-link events are gone as events; no vendor can work around that. The Data API softens the loss: GA4’s aggregated history isn’t bound by retention settings, so topline series from before the link can still be pulled at report grain.

You lose event-level detail, not the trend line. The advice is unchanged: link now, not when you need the history — every unlinked day is event-level history you never get back.

What happens when you hit GA4’s 1 million events a day export cap?

The daily batch export on standard properties caps at one million events per day, and Google pauses the export if a property consistently exceeds it — usually discovered only after the tables stop arriving.

High-volume properties need the streaming export or GA4 360. That’s a sizing conversation we have on the discovery call, before the pipeline is built, not after it breaks.

Why don’t warehouse numbers match the GA4 interface?

The interface estimates high-cardinality counts with approximation algorithms and applies privacy thresholds; the export gives you raw events that we aggregate exactly. Add late-arriving events — Google updates a daily table for roughly two days after its date — and sessions rebuilt under a different definition, and small deltas are structural, not bugs.

The data models document exactly how their numbers are counted and re-read the trailing tables until they settle, so the delta is an explanation, not an argument.

How we work with GA4 data

GA4 offers two grains of the same property, and choosing between them is a consulting decision, not a checkbox.

The native BigQuery export is event-level and unsampled — the right foundation for custom modeling — but it caps at one million events a day on standard properties, starts the day the link is created and can’t backfill. The Data API is aggregated, quota-bound and subject to thresholding — but it reaches history from before the export link, which the export never can. Which route fits depends on your event volume, how much history you need and how deep your modeling ambitions go.

We settle that together on the discovery call — including the sizing question if you’re near the export cap. Many properties end up on both: the export as the modeling foundation, the API for pre-link topline history. Either way, running the pipeline is our job — sessionization, channel rules and late-event handling included; no connector to configure, no quota to babysit.

Delivered to a database you own

Every table — raw and modeled — is written to your own database, under your billing and your access controls. Our access is read-only, and if we part ways, everything stays with you.

  • BigQuery BigQuery Your data models are built in your own BigQuery project — our access is read-only, and the tables are always yours.

BigQuery is the supported database today. If you run a different warehouse, tell us — the roadmap is driven by requests.

How current the data stays

Data models rebuild every day. Where a platform restates recent numbers after the fact, we re-read those days rather than freezing the first version we saw.

Refresh

Daily, on top of Google’s export. The models re-read the trailing daily tables so late-event restatements flow through instead of freezing mid-change.

Backfill

Event-level history starts at the export link date — a platform limit no vendor can work around. Pre-link periods are recovered as aggregates through the Data API; from link day forward, events accumulate indefinitely.

Monitoring

Every sync is checked for freshness, volume and schema drift. New event parameters your implementation starts sending are picked up by the models — you find out from a note, not a broken chart.

What lands in your database

Not raw API responses — data models: named, documented tables at a stated grain, rebuilt every day and ready to query. Each one has its own page.

The shipped data models are the starting point, not the ceiling. When your questions need a different shape — another grain, another split, a join against another source — we build additional models for your stack as part of the engagement.

Own your event data before the next sampling question.

Tell us whether the BigQuery export link already exists and how far back you need to read. We’ll map what is still recoverable as aggregates and what only accumulates from here.

Free discovery call · No commitment — leave with a starting point