A common misconception is that the Google Analytics 4 (GA4) interface is where business reporting should live. It's understandable: the tool has charts, tables, funnels and enough dropdowns to keep a committee busy for years. It's also how someone ends up presenting a wobbly trend line in a meeting as "the truth".
In Marc Alexander's view, the GA4 interface is a measurement and exploration layer: a place to collect behavioural data and investigate patterns. It is not a reporting system built to produce board-ready, finance-grade numbers without further modelling.
Running a business from the GA4 interface is like using a Swiss Army knife as a butter knife. It works, but it's not what it was made for.
What the GA4 interface is, and what it isn't
GA4 is excellent at capturing event-based behaviour and letting analysts dig in to answer "what changed?" It falls down when you ask it to behave like a reporting platform: stable KPI definitions, consistent time series, and metrics that map cleanly to how the organisation makes money.
The difference matters because exploration is allowed to be messy and reporting isn't. Exploration is where you investigate. Reporting is where you commit.
1. The interface is built for exploration, not decisions
The GA4 interface has to work for everyone (startups, publishers, ecommerce, SaaS, enterprise), so it ends up a compromise. That's why GA4 often feels "fine" but rarely feels "right".
It's useful for diagnostics: spotting dips, spikes, broken tracking and odd shifts in behaviour. The moment you're debating targets, investment or accountability, you need metric definitions you can stand behind, and the interface isn't built to give you that governance.
Common symptoms of using GA4 as the reporting layer:
- meetings spent arguing about whose report is "correct"
- teams quietly keeping their own definitions of the same KPI
- dependence on the one person who knows which filters to apply
2. Privacy-first design means the interface can't be a ledger
GA4 is designed for consent constraints, aggregated measurement and safeguards that can reduce detail in some reports. That's sensible and necessary, but it has a consequence: if the platform applies modelling and protections, the interface can't be the definitive, auditable record.
Rule of thumb: if finance would expect to sign a metric off without a second look, it probably shouldn't come from the GA4 interface.
3. The real product is the export
GA4's most consequential feature isn't a chart. It's the native export to BigQuery, which makes GA4 part of a proper Google Cloud Platform (GCP) data setup. GA4 stops being a reporting tool you log into and becomes a data source you build on.
Once GA4 data is in BigQuery:
- KPIs are defined once, documented and repeatable
- business logic (leads, revenue, refunds, cancellations) is written down explicitly instead of left to defaults
- behavioural data can be joined to CRM, finance, product usage and offline conversions, which is where decisions come from
If GA4 is the instrument panel, BigQuery is the engine room.
4. Why Google built it this way
Why would Google ship an analytics product whose interface isn't the final reporting layer? Two reasons.
First, privacy constraints make one-size-fits-all reporting brittle. If the product has to apply thresholds and modelling, the numbers you run the business on are better defined downstream, where you control the definitions.
Second, larger organisations have moved towards warehouse-centred analytics. They want one place where data is governed, joined and modelled over time, not scattered across tools and teams. GA4's export-first approach fits that: Google collects the events, and the organisation decides what they mean.
5. Why this can be an advantage over Amplitude and Adobe Analytics
Amplitude and Adobe have historically leaned harder on their interfaces as the home of reporting, with stronger in-tool governance, metric definitions and stakeholder-ready workflows. GA4 takes a different route: a lighter interface for investigation, plus a strong path to warehouse-led reporting.
Adopted that way, the advantages can be material:
- your warehouse becomes the system of record, with governed definitions and an audit trail
- attribution and KPIs can reflect how your business works, not vendor defaults
- reporting is reproducible and explainable, not dependent on interface quirks
6. Own your reporting layer
The real mistake is leaving interpretation to the vendor's interface. Businesses don't run finance from the default charts in their accounting software; they produce management accounts with agreed rules. Marc recommends treating analytics the same way:
- separate data collection from decision reporting
- define KPIs in your warehouse, and document them
- publish those KPIs through a reporting layer designed for stakeholders, such as custom GA4 dashboards built on the governed data
7. The counterpoint
Warehouse-led GA4 isn't magic. It needs data modelling, governance, documentation and a reporting layer people will use. Amplitude and Adobe can feel better out of the box because their interfaces do more of that work upfront.
The trade-off is short-term convenience against long-term ownership of your numbers. One is easier at the start. The other tends to pay off once you're big enough that ambiguity costs money.
Conclusion
GA4 isn't broken. It's often used for the wrong job. Used well, it's a capable event collection system with a lightweight exploration interface. Used as the reporting layer, you spend more time arguing about the number than acting on it.
The organisations that get value from GA4 stop asking "What does GA4 say?" and start asking "What does the business need to know, and how do we model the data to answer it?"
Marc, a Google Analytics consultant, builds that modelling layer for clients, from the GA4 export to BigQuery to the dashboards on top.