Google Analytics
Source Analytics

Google Analytics 4 Data, Delivered to Your Database

Cleaned, enriched and modeled into ready-to-query mart tables. Currently on BigQuery. We run the pipeline, you own the data.

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 marts, 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.

Book an architecture review Ask for a sample schema

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 marts 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 mart, every month — and the sessionization SQL is our job to write and maintain, not yours.

Why can’t you see GA4 data from before the BigQuery link?

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 at the architecture review, 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 marts 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 at the architecture review — 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.

Refresh, backfill and monitoring

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.

Delivered to a database you own

Every table — raw and mart — 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 Marts 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.

What lands in your database

Not raw event tables you still have to UNNEST — named mart tables at documented grain, refreshed daily and ready to query.

  • mart_sessions_daily Sessions by channel and market at a documented daily grain — the number the whole company can agree on.
  • mart_conversion_funnel Your key events as ordered funnel steps, with step-to-step conversion per day and channel.
  • mart_revenue_by_channel Revenue and orders next to the channels that drove them, ready to sit beside ad spend.

The standard marts are the starting point, not the ceiling. When your questions need a different shape — another grain, another split, a join against your Search Console or ads marts — we define additional marts for your stack as part of the engagement.

What you can run on GA4 data

Every capability we ship works on these marts from day one.

Frequently asked questions

If something is still unclear, a discovery call clears it up fast.

Whichever your setup calls for — often both, and it’s a decision we make together at the architecture review. The native export is event-level and unsampled, the right foundation for custom modeling. The Data API is aggregated and quota-bound, but it reaches history from before the export link and is enough for report-grain marts. They aren’t rivals; they’re two grains of the same property, and the pipeline models on either.

Your GA4 events, modeled and readable — in a database you own.

Book an architecture review Ask for a sample schema

Free discovery call · Leave with an export-vs-API sizing plan