Skip to content
Sultan Kautsar

Home / Notes /

Google Analytics 4

Most Google Analytics 4 (GA4) setups I inspect are technically “installed” and practically useless: a tag firing on every page, a handful of default events, and a dashboard nobody trusts enough to make decisions from. That gap between “we have analytics” and “we have answers” is the problem I solve.

This note explains how I approach GA4: how it models data, what a good setup includes, the mistakes I see most often, and the steps I follow. It is one of four notes on the measurement stack, together with Google Tag Manager, Consent Mode V2, and Google Ads Conversion Tracking.

The Problem

GA4's event-based model gives you the flexibility to track anything. That flexibility is also why most implementations fall apart without a clear framework. Nobody decides up front what should be measured, so every new campaign or feature adds a few more events in its own style. After a year, teams are drowning in noise:

  • Duplicate events that inflate counts.
  • Inconsistent naming, such as form_submit, formSubmit, and contact_form for the same action.
  • Parameters that are collected but never used in a report.
  • Key events that do not match what Google Ads or the CRM reports.

The reports still load, so the problem is easy to miss. It shows up later, when someone asks a hard question and the data cannot answer it.

How GA4 Models Data

Understanding a few building blocks makes the rest of the setup much easier to reason about.

Events
Everything in GA4 is an event: a page view, a scroll, a form submission, a purchase. Some are collected automatically, some come from enhanced measurement, and the rest are custom events you define.

Parameters
Each event carries parameters that describe it, such as the form name, the value of a purchase, or the plan a user picked. Parameters only appear in standard reports after they are registered as custom dimensions or metrics.

User properties
Attributes that describe the user rather than a single action, such as customer type or membership level. They are useful for segmenting audiences across sessions.

Key events
Events you mark as important to the business. GA4 used to call these conversions. They drive reporting and can be imported into Google Ads.

A good setup is mostly a set of deliberate decisions about these four things: which events exist, which parameters each one carries, which user properties matter, and which events count as key events.

What a Good Setup Includes

I build GA4 implementations around the journey the business actually cares about, not the default template. That means full customer-journey tracking:

  • A structured event taxonomy: every event and parameter is named and scoped deliberately, so reports stay readable as the site or product grows. Where Google has a recommended event name, such as generate_lead or purchase, I use it.
  • Cross-domain and cross-device tracking: a user who starts on a landing page and converts in an app, checkout, or booking system is not counted as two different people.
  • Enhanced measurement tuned, not just switched on: scroll, engagement, video, and file-download tracking configured to reflect real intent instead of firing indiscriminately.
  • Custom key events and audiences: tied to the actions that move revenue, such as qualified leads, completed onboarding, and repeat purchases, not just “page loaded.”
  • Clean funnel and exploration reports: built on top of the data, so you can see exactly where users drop off and where the unexpected wins are hiding.
  • Property settings that match the business: data retention, internal traffic filters, and unwanted referrals configured on day one rather than discovered later.

An Example Tracking Plan

The tracking plan is the document that turns the taxonomy into something developers and marketers can both check. For an illustrative lead generation site, a small part of it might look like this:

Event When it fires Key parameters
view_item A visitor opens a service or product page item_id, item_category
form_start A visitor interacts with a form for the first time form_id
generate_lead A form is submitted and the server accepts it form_id, lead_type, value
purchase An order is confirmed transaction_id, value, currency

Notice that generate_lead fires when the server accepts the form, not when the button is clicked. Small definitions like that are what make the numbers line up with the CRM later.

Where It Fits

GA4 sits at the end of the measurement chain. It can only report what the layers before it allow through.

A visitor lands on the site
   ↓
Consent defaults load, then update on their choice
   ↓
The site pushes events into the data layer
   ↓
Google Tag Manager fires the tags consent allows
   ↓
GA4 records the journey, Google Ads receives the conversions

Events reach GA4 through Google Tag Manager, and whether they may be stored at all is decided by Consent Mode V2. The same events often become the conversions that Google Ads Conversion Tracking bids on, which is why a naming mistake here can end up as a bidding mistake there.

Common Mistakes

  • Two installations at once: a hardcoded GA4 tag on the site and another one in Tag Manager, so every page view is counted twice.
  • Personal data in parameters: email addresses or phone numbers sent in event parameters or page URLs. This is against Google's policies and hard to clean up afterward.
  • Payment gateways as referrers: a user leaves for the payment page and returns, and the purchase is credited to the gateway instead of the original campaign.
  • Internal traffic counted as customers: the team's own visits inflate engagement and test key events.
  • Short data retention: the default retention for exploration reports is two months. Year-over-year analysis is impossible if nobody changed it.
  • Unregistered parameters: data is sent, but never registered as a custom dimension, so it never appears in reports.

Why It Matters

Bad tracking does not just mean bad reports. It means bad decisions upstream of the report. Budget gets allocated to the wrong channel, a “high-performing” campaign turns out to be a tracking artifact, and the actual growth lever in the funnel stays invisible because nobody configured GA4 to see it.

A properly architected GA4 setup does the opposite: it becomes a source of truth your team argues with, not about.

How I Approach It

1. Audit
Review the current setup to find what is firing, what is duplicated, what is missing, and where the data disagrees with reality.

2. Map the customer journey
Specific to the business model, from first touch to conversion, and after conversion where relevant.

3. Architect the tracking plan
Define the events, parameters, and key events, then implement them in Google Tag Manager as a clean, documented structure the team can maintain after I am gone, not a black box.

4. Validate
Check every event against real user behavior in DebugView and Preview mode before it ships, not after.

5. Hand off
With documentation and reporting that marketing, product, and finance can all read the same way.

Before You Trust the Numbers

A short checklist I run before calling a GA4 setup done:

  • Each page view is recorded once.
  • Every key event fires once per real action, and matches a count from another system.
  • Consent states change what is collected, as expected.
  • Internal traffic is filtered, and payment domains are excluded as referrers.
  • Data retention is set to the longest option available.
  • Custom parameters that matter are registered and visible in reports.

If your data does not hold up under a hard question, it is not ready to run a business on. If you want a second look at your setup, get in touch.

Related notes

  1. Google Tag Manager
  2. Consent Mode V2
  3. Google Ads Conversion Tracking

All notes →