Most marketers treat GA4 like a reporting tool. You open the interface, you look at sessions and conversions, you export a chart, you move on. That's fine for surface-level monitoring. But if you've ever exported your GA4 data to BigQuery, you already know the interface is hiding the most valuable thing you own: an event-level, row-per-hit data model that's begging to be reshaped.
The upgrade almost nobody is doing is feature engineering. Not new models. Not fancier dashboards. Just taking the raw GA4 export and turning it into features that actually describe user behaviour in ways your reporting layer never will. And with an LLM sitting next to your warehouse, this went from a specialist SQL task to something a marketing team can do in an afternoon.
What feature engineering actually means for GA4
Feature engineering is the practice of transforming raw data into variables that better represent the thing you care about. In machine learning it's the unglamorous step that decides whether your model works. The old adage holds: better features beat better algorithms, almost every time.
The GA4 BigQuery export is raw in the truest sense. Every row is an event, with nested parameters buried in event_params arrays. Nothing in that structure tells you whether a user is engaged, hesitant, returning, or about to churn. Those are all derived concepts. They don't exist in the export until you build them.
Examples of features you can engineer from the standard GA4 export:
- Sessions-to-conversion — how many distinct sessions a user had before they converted, not just last-click attribution.
- Time-to-first-key-event — seconds between first visit and the first meaningful action.
- Scroll-and-read depth per content type — combining
scrollevents with page path to separate skimmers from readers. - Recency, frequency, engagement — the classic RFM idea, rebuilt on event data instead of transactions.
- Path entropy — how predictable or chaotic a user's navigation is before conversion.
None of these are available in the GA4 UI. All of them are one SQL transformation away from the raw export.
Why the raw export is the point
Inside the GA4 interface, the data is pre-aggregated and pre-modelled. Google decides what a session is, how attribution works, and which dimensions you can cross. Useful, but frozen. The BigQuery export gives you the atoms back. Once every event is verifiable at the row level, you can define your own session logic, your own engagement thresholds, your own conversion windows. That's the difference between consuming a data model and owning one — the same shift behind measuring AI marketing ROI with GA4 and BigQuery.
This matters more than it sounds. The moment your form-submit event is confirmed in BigQuery with its full parameter set, you can join it to everything that happened before it in the same user's journey. That join is where features come from.
Where AI changes the workflow
Here's the honest history: engineering these features always required someone comfortable with nested BigQuery SQL, UNNEST, window functions and the specific quirks of the GA4 schema. That's a real skill and a real bottleneck. Most marketing teams don't have it in-house, so the raw export sits untouched.
That bottleneck is what an LLM removes. We run an MCP setup connecting Claude to BigQuery, Google Ads and GTM. MCP — the Model Context Protocol — lets the model actually query the warehouse rather than guess at it. Instead of writing UNNEST logic from memory, we describe the feature we want in plain language: "give me each user's session count before their first form submission, plus days between first and last visit." The model inspects the real schema, drafts the SQL against the actual GA4 export table, runs it, sees the errors, and corrects them.
The key point is grounding. Because Claude is connected to the live schema through MCP, it isn't hallucinating column names — it reads the nested structure of event_params and writes against what's really there. That's what turns feature engineering from a specialist task into a conversation. You still need to know what feature you want and why. The model handles the how.
A practical starting sequence
If you want to try this, resist the urge to build everything at once. Feature engineering rewards iteration.
- Confirm the export exists and is clean. Link GA4 to BigQuery, wait for a few days of data, and verify that your key events actually land as rows. If you can't find your conversion event in the export, fix that before anything else.
- Pick one decision you want to inform. Not "understand users" — too vague. Something like "which content leads to form submissions." A feature is only useful in service of a decision.
- Name the features that decision needs. For that example: read-depth per article, sessions before conversion, and the last content viewed before the form.
- Build one feature at a time with the model. Ask for the SQL, run it against the export, and eyeball the output. Sanity-check the numbers against what you see in the GA4 UI where the two overlap.
- Materialise the good ones. Once a feature is stable, save it as a scheduled query or a table. Now it's reusable infrastructure, not a one-off.
The discipline here is treating features as assets. A well-defined engagement score you can trust is worth more than ten dashboards you half-believe.
The trap: skipping straight to models
There's a strong pull to jump from raw data to prediction. "Can AI tell me who will convert?" Maybe, eventually. But a churn or conversion model built on the raw export directly will be weak, because the raw events don't describe behaviour in the shape a model can learn from. The features do.
This is why we keep saying optimisation of your existing data model beats reaching for a bigger, shinier technique. The teams getting value aren't the ones with the most advanced models. They're the ones who took their GA4 export seriously, engineered a handful of honest features, and made sure those features were verifiable back to real events. Everything downstream — segmentation, scoring, prediction — gets easier and more trustworthy once the feature layer exists.
And because the LLM sits on top of a grounded warehouse connection, the whole loop stays honest. You can ask it to explain a feature, show you the rows behind an aggregate, or reconcile a number that looks off. When the model can query the actual table, you can check its work. That auditability is the whole game.
What to build first, realistically
If we had to name the single highest-leverage feature for most marketing teams, it's this: content-attributed conversion paths — for each converting user, the ordered list of content they viewed and how many sessions it took. It's simple, it's derivable from the standard export, and it answers the question everyone actually has, which is "what content is doing work." Build that one, verify it against your event data, and you'll immediately see why the reporting UI was never going to give it to you.
Feature engineering isn't glamorous. It's the layer between raw events and every clever thing you want to do next. The good news is that the two hard parts — the SQL skill and the schema knowledge — are exactly the parts an LLM connected to your warehouse can now shoulder.
If you want help linking GA4 to BigQuery, standing up an MCP connection to your data, or engineering features you can actually trust, that's the kind of analytics and AI work we do — see our AI solutions or talk to us at Bitegrico.