Setting Up Google Analytics 4 Correctly

Property and data stream setup

Inside a Google Analytics account, a property represents one business or one website's worth of data. Inside that property, a data stream is the specific source feeding it data — typically your website, and separately your iOS or Android app if you have one. For a single-website small business, the setup is usually one property containing one web data stream. If you run more than one distinct website — say a main business site and a separate booking portal — it is usually cleaner to give each its own property rather than mixing them into one, unless you specifically want combined reporting across both.

When you create a web data stream, GA4 gives you a Measurement ID (it looks like G-XXXXXXXXXX) and a small snippet of tracking code, the Google tag. That tag needs to be present on every page of your site — not just the homepage — for GA4 to see the full picture of how people move through it. A tag installed only on the homepage will show inflated bounce and exit rates for every other page, simply because GA4 cannot see anyone actually leave from a page it was never watching.

If you use Google Tag Manager instead of pasting the tag directly, install the GA4 configuration tag there once and it fires site-wide, which is generally the cleaner long-term approach because it lets you add more tags later — conversion events, third-party pixels, remarketing tags — without editing site code again for each one. This is worth setting up correctly even if you only need GA4 today, because the alternative is going back into the site's code every time a new tracking need comes up.

While you are in the setup screens, fill in the basics properly: correct business time zone and currency, industry category, and business size. These small details affect how some reports are calculated and benchmarked, and they take two minutes to get right at setup versus a headache to fix months of data later — the time zone in particular affects how "today" and "this week" are calculated in every report from that point forward, and cannot be cleanly corrected retroactively once data has already accumulated under the wrong setting.

From sessions to events — the mental model shift

If you or anyone on your team used the older Universal Analytics, GA4 requires a real shift in thinking, not just a new interface. Universal Analytics organised everything around sessions and pageviews — a visit was a session, and within it you had pageviews, with a separate bolt-on system for "events" like button clicks, added on top of that session-based structure rather than built into it from the start.

GA4 flips this around: everything is an event. A pageview is an event (page_view). A scroll is an event (scroll). A click, a video play, a file download, a form submission — all events, all first-class citizens in the data model, not an afterthought bolted on separately. Sessions still exist as a concept in GA4's reports, but they are now derived from events rather than being the fundamental unit everything else hangs off — a session in GA4 is essentially a calculated grouping of events that happened close together in time from the same user.

This matters practically because it changes what "engagement" means. Universal Analytics had bounce rate — the percentage of single-page sessions with no interaction. GA4 instead has engaged sessions and engagement rate, based on whether a session lasted a meaningful amount of time, had a key event, or included at least two pageviews. The numbers will not match your old reports, and that is expected — they are measuring genuinely different things, not the same thing with a different label. Anyone comparing a GA4 engagement rate directly against an old Universal Analytics bounce rate and expecting them to roughly agree is going to be confused for no good reason; the two metrics are simply not counting the same behaviour.

The practical upside of the event-based model is flexibility. Because everything — including a pageview — is just an event with parameters attached, it is far easier in GA4 to build custom tracking around whatever specific action matters to your business, without needing a separate "events" framework bolted onto the side of the main reporting. This is part of why Chapter 3 spends real time on the distinction between automatic and custom events, and why Chapter 5 treats defining key events as a first-class setup task rather than an afterthought.

Common setup mistakes

Most GA4 data quality problems trace back to a handful of setup errors made in the first week and never revisited. Each one is easy to avoid, but only if you know to check for it:

• Duplicate tracking. The GA4 tag pasted directly into the site's code and installed again through Google Tag Manager, or two GA4 config tags fired from two different plugins. The result is inflated pageviews and sessions that never match reality — check your page source or a tag-checking browser extension to confirm exactly one Google tag firing per page load.
• Missing cross-domain configuration. If a checkout, booking system, or payment page lives on a separate domain or subdomain from the main site, GA4 will treat a visitor moving between them as two different people arriving from two different sources unless cross-domain measurement is explicitly configured. This silently breaks conversion attribution for anyone using a hosted checkout or third-party booking tool, and it is easy to miss because both halves of the journey still show up in GA4 individually — they just never get connected as one visitor's single journey.
• Wrong default reporting identity or data retention left too short. These sit in Admin settings and are easy to skip past during setup, but they affect how returning visitors are counted and how far back you can query custom reports — the default retention window is shorter than many people expect, and it cannot be extended retroactively for data already past that window.
• No internal traffic filter. Without one, your own visits, and your developer's or agency's, blend into the same reports as real customers — covered in more depth in Chapter 8, but worth setting up during initial configuration rather than treating as an afterthought.
• Never checking Realtime after launch. The single fastest way to catch a broken setup is to open the Realtime report and browse your own site in another tab. If your own visit does not show up within a minute, the tag is not firing — and every day after launch that goes unnoticed is a day of lost data that can never be recovered, since GA4 cannot retroactively record traffic it never saw at the time.

None of these mistakes are difficult to fix once spotted — the risk is entirely in not spotting them, sometimes for months, because the reports still populate with numbers and nothing about a duplicated or misconfigured tag looks obviously broken at a glance.