A few days ago, I was doing something that should have been routine: implementing analytics tags on a healthcare website for Amalife. I wanted to track appointment bookings and send the service cost as an event parameter. In my head, it was simple. I already had my own parameter names, like appointment_cost and appointment_currency. That’s how you’d do it in a web app. That’s how you’d do it in MongoDB. That’s how you’d do it in most systems where you control the data model.
Then GA4 surprised me. It didn’t “understand” my fields the way I expected. Worse, it interpreted the number in a way that didn’t match my currency intent. I realized, a bit too late, that I was not just sending data to a place that stores it. I was feeding an analytics product with a predefined semantic model. And if I didn’t respect that model, the system would happily accept my payload… and still report something different than what I meant.
That confusion led to a long discussion with a friend who worked on analytics at a large enterprise, and it sent me down a rabbit hole that cleared up something I wish someone had explained to me ten years ago: the difference between products with predefined schemas, BI tools, and “regular” web applications isn’t a detail. It’s the whole game. It’s also the reason why roles like web developers, tag implementation specialists, analytics people, BI developers, and data engineers often sound like they’re talking about different universes.
This article is my attempt to reconcile those universes in plain English, for CIOs, IT directors, product managers, IT students, and web analytics specialists.
GA4 vs Database: Why Google Analytics Is Not a Raw Data Store
If you build web apps or data pipelines, your intuition is usually correct in most places. You send structured data, you store it, you query it. If you use MongoDB, you can write a document with appointment_cost: 200 today and add something_else tomorrow. MongoDB doesn’t require you to register that field in advance. MongoDB also doesn’t try to guess what the field means. It’s just a key-value pair stored in a document. When you query, you say what you mean.
In GA4, that mental model breaks, because GA4 is not a general-purpose datastore. It is an analytics engine with a contract. It can ingest your events, but reporting and interpretation depend on whether your payload matches Google’s predefined semantics.
That’s why appointment_cost didn’t automatically become “money” in GA4. In Google’s world, “money” is value plus currency. Those keys are special because the product is designed to treat them specially. So my custom field wasn’t wrong syntactically. It was wrong semantically.
This sounds like a small detail, but it reveals a major system-design principle: analytics systems are not just storage. Analytics systems are semantics plus aggregation.
Products With Predefined Schema: GA4 Is Closer to Everflow Than to a Database
The clearest analogy that emerged from our discussion was this: GA4 behaves more like Everflow than like a database.
Everflow expects clicks, conversions, and events. You can fire them in many ways, but the platform already “knows” what a click is and what a conversion is, and it has predefined reports and logic built around those concepts. If you send the wrong thing to the wrong place, it may still accept it, but the reporting will be off because you violated the contract.
GA4 is the same pattern. It is an event collection and reporting product with a semantic model. It is optimized to provide a ready-made suite of reports about users, sessions, events, attribution, and funnels. The price you pay for “ready-made” is compliance. Your events must match how the product thinks about the world.
That compliance requirement is exactly why a whole industry exists around tracking and tagging implementation. These specialists aren’t just “installing tags.” They’re translating messy real-world business behavior into the platform’s predefined mental model. They memorize the rules because the rules are not obvious and not transparent.
From a system architecture point of view, this is not a flaw. It’s a tradeoff. A predefined semantic model enables fast reporting at scale for non-technical teams. But it will frustrate anyone who expects full control over the model.
GA4 vs Power BI: What’s the Real Difference?
Now compare that to Power BI.
Power BI is not an analytics product in the same way GA4 is. Power BI is a modeling and visualization tool. It consumes data from databases, warehouses, APIs, files, and semantic layers. It doesn’t decide what “revenue” means. You decide. It doesn’t decide what “session” means. You decide. It doesn’t decide currency conversion logic. You decide.
This is liberating, but it’s also expensive in effort. In BI, you own the contract. You own the definitions. You own the relationships. You own the measures. You own the edge cases.
If you want sessionization, attribution logic, deduplication, identity stitching, currency handling, and reconciliation, you can build all of it in a BI-driven architecture. But the BI tool won’t hand you those concepts pre-built. GA4 will. That’s the entire difference.
BI is an “agnostic engine.” GA4 is an “opinionated product.”
MongoDB vs GA4: Schemaless Storage vs Predefined Analytics Models
The MongoDB example is instructive because people often confuse “schemaless” with “no structure.”
A database can be schemaless in terms of field registration and still be semantically blind. MongoDB does not interpret your fields. Your application and your analysts interpret them. In other words, semantics live outside the database.
GA4 does the opposite. It stores and processes events, but it also interprets specific keys in specific ways, because the product’s value is the interpretation and the reporting.
This is also why GA4 doesn’t behave like a transactional system.
OLTP vs OLAP Explained: Why GA4 Is Analytical, Not Transactional
At some point, the conversation shifted to what feels like a philosophical question but is actually an architectural one: why doesn’t GA4 allow updates or deletes, like a “proper” system would?
The answer is that GA4 is designed for analytical workloads, not transactional truth.
Transactional systems like WMS and ERP are OLTP systems. They are designed to be the source of truth. They need strict correctness, row-level updates, referential integrity, concurrency control, and auditability.
A missing row in a WMS can mean a customer never receives the product. A duplicated invoice in an ERP can mean financial misstatement. By contrast, a missing conversion in GA4 might slightly shift a conversion rate from 2.41% to 2.39%. A missing page view might slightly alter a funnel drop-off percentage. It might marginally affect a dashboard trend line. The business does not collapse. The warehouse does not ship the wrong item.
Analytics systems like GA4 are OLAP-oriented. They are designed for aggregation, trend detection, and decision support. The system is optimized for ingesting enormous volumes of append-only events and producing aggregated insights. It is not optimized for row-level mutation. If you allow mutation at internet-scale analytics ingestion rates, you create a performance and complexity nightmare. You also undermine the entire pipeline design, which relies on append-only processing and precomputed aggregation.
That “append-only by design” is not laziness. It’s what makes large-scale analytics possible.
But it also means GA4 can never be your operational ledger. It is not a WMS. It is not an ERP. It is not your billing system. It should not be your source of truth for revenue.
That point matters, especially for CIOs and IT directors who look at eight-figure marketing budgets and rightly ask why the measurement layer tolerates approximation. Marketing spend is not trivial. However, the analytics interface you use to evaluate campaigns is still a decision-support system, not an accounting ledger.
If you need accounting-grade accuracy, your source of truth must live in an operational system. That means your actual orders, invoices, refunds, and revenue should be recorded and reconciled inside your CRM, ERP, or ecommerce platform such as Shopify. Those systems are designed for transactional correctness. They enforce integrity. They handle adjustments. They survive audits.
GA4 should not be treated as the place where revenue “exists.” It should be treated as the place where behavioral context exists.
The correct architectural pattern is this: you track actual transactions in your CRM or ecommerce platform. Separately, you capture attribution signals and touchpoints in GA4. Then you either push attribution data into the CRM at the time of order creation, or you build a multi-touch attribution layer that joins behavioral data with confirmed transactional revenue. Only then do you analyze ROI by campaign, channel, or marketing effort.
In other words, GA4 helps you understand how users arrived and behaved. Your CRM or ecommerce platform confirms what they actually purchased and paid. Real ROI analysis happens when those two layers are reconciled deliberately, not when one system tries to impersonate the other.
GA4 vs BigQuery: Why the Numbers Don’t Always Match
Another turning point in our discussion came from enterprise experience at a large telecom company. Even when GA4 and BigQuery export are available, teams often notice that counts in the GA UI and counts in BigQuery don’t match perfectly. They are usually close, but not identical.
This doesn’t necessarily mean GA4 is “wrong.” It means the UI often applies layers that BigQuery export doesn’t. Explorations can sample. The UI can apply thresholding for privacy. Some metrics are modeled. Some dimensions have cardinality limits. The product optimizes for interactive experience and cost.
BigQuery export, on the other hand, gives you the raw event stream. That makes it closer to the underlying truth, but it shifts work onto you. You now have to write SQL, build models, and recreate definitions consistently.
It’s also not “free” in the real sense. GA4 might export to BigQuery without a license, but you pay for BigQuery storage and processing. For a technical team, that’s a fair trade. For a marketing team that needs fast UI answers at scale with minimal engineering involvement, it can be a non-starter.
What Is GA4 360 and Is It Worth the Cost?
This leads to the question that triggered a lot of debate: if BigQuery export is accurate, is GA4 just a free report tool and GA4 360 just a paid version of the same thing?
Not exactly.
GA4 360 is not primarily “GA4 with perfect accuracy.” GA4 360 is GA4 built for enterprise operations. It’s about governance, SLAs, limits, support, and scale. It’s about enabling hundreds of non-technical stakeholders to use the UI reliably at high data volumes, with fewer restrictions. It’s about managing complex organizations with subproperties and rollups. It’s about support contracts and predictable service.
If you are already BigQuery-first, already modeling your own metrics, and already using BI, GA4 360 may be redundant. But if you’re a multinational with massive teams and you need UI-driven workflows, governance, and SLAs, it becomes easier to justify.
The simplest framing is this: GA4 360 often buys comfort and scale, not magic.
When to Use GA4 vs Build a Custom BI Stack
At one point I had a realization that will resonate with anyone building a data product.
If I decide I dislike GA4’s constraints and I build my own stack like Next.js → MongoDB → Power BI, I gain full control. I can store whatever I want. I can model whatever I want. I can report however I want.
But if I want that stack to be reusable across multiple customers, I will still need a predefined contract. I will still need to tell every customer, “Send events in this format, with these properties, otherwise it won’t map cleanly into the model and the dashboards.”
In other words, if you want reuse at scale, you need a schema and semantics. There is no analytics product without a contract. GA4 has Google’s contract. Your internal BI product has your contract. CatStats has your contract.
This is where the worlds reconcile. The difference isn’t whether a contract exists. The difference is who owns it, and how opinionated it is.
Data Product vs Analytics Tool: What’s the Difference?
This is the part that becomes exciting if you’re building domain-specific software.
CatStats is a data product for affiliate marketing. It collects data from tracking platforms like Everflow and NATS. It models the data into fact tables. It exposes a semantic layer. It scores performance. It provides domain-specific dashboards.
Structurally, that is similar to GA4. It is still event ingestion plus semantics plus reporting. But semantically, it’s a different universe.
GA4’s world is sessions, users, page views, engagement, attribution, and ecommerce conventions.
CatStats’ world is offers, affiliates, payouts, EPC, approval rates, fraud signals, offer exposure, and revenue leakage.
If I tried to use GA4 to run CatStats-style analytics, I’d fight the system. If I tried to use a WMS-like transactional model for GA4, I’d create an unusable monster.
What matters is that semantics must match the domain. The product is the semantic layer.
Why Web Developers, Data Engineers, and Analytics Teams See Data Differently
The reason web developers, tracking specialists, analytics people, BI developers, and data engineers often struggle to align is that each role optimizes for a different goal.
- Web developers optimize for shipping product experiences and instrumentation hooks.
- Tracking specialists optimize for correct mapping into opinionated analytics platforms under privacy constraints.
- Analytics specialists optimize for decision-making under imperfect measurement.
- BI developers optimize for modeling, measures, and stakeholder reporting.
- Data engineers optimize for pipelines, reliability, and scalable computation.
If you try to solve an “analytics contract” problem as if it’s a database problem, you get frustrated. If you try to solve a transactional truth problem as if it’s an analytics problem, you get burned. If you try to solve enterprise governance as if it’s a weekend dashboard, you get chaos.
Once you accept that each layer has different correctness and performance constraints, the fragmentation becomes less annoying and more understandable.
A Practical Mental Model That Stops the Confusion
If you remember only one thing, remember this:
A product with predefined schema is a semantic engine. A BI tool is a semantic workshop. A web app plus database is a data factory.
GA4 is a semantic engine optimized for marketing analytics at scale. Power BI is a semantic workshop where you define truth. A web app plus MongoDB can store anything, but it won’t interpret anything unless you build that interpretation.
Once you adopt that model, your expectations become accurate. And when your expectations become accurate, systems stop feeling “stupid” and start feeling like what they actually are: a set of intentional tradeoffs.
Closing: The Lesson I Wish I Had Ten Years Ago
My tagging mistake at Amalife wasn’t really about a parameter name. It was about assuming that “sending data” means “the system will understand my intent.”
Databases store. Analytics products interpret. BI tools let you define interpretation. Data products are where you codify interpretation for a domain.
If you’re a CIO or IT director, the key takeaway is that you should never ask one system to be all systems. Decide what is source of truth, decide what is decision support, decide what is domain reporting, and then connect them with clear contracts.
If you’re a product manager, the key takeaway is that predefined semantics are what make products scalable and easy. But they always reduce flexibility. That tradeoff must be intentional.
If you’re a student or early-career engineer, the key takeaway is that most confusion disappears once you can label a system correctly: OLTP truth system, OLAP analytics system, BI modeling tool, or domain data product. Each has different rules because each serves a different purpose.
And if you’re a web analytics specialist, the key takeaway is that your job is not “tagging.” Your job is semantic translation. You are mapping reality into the mental model of an opinionated engine.
