Fundamentals & implementation
Universal Analytics is gone, and GA4 is not a reskin of it — it is a different machine built for a web of many devices and few cookies. This module rebuilds your mental model from the ground up: where GA4 came from, how its event data model actually works, how to architect accounts and properties you will not regret, and how to implement and debug a setup you can trust.
What you will learn
Why GA4 had to exist
GA4 exists because the web stopped being a stack of page views. Universal Analytics was built around the session — a visit to one website, on one device, measured in pageviews and bounce rate. People now move between a phone, a laptop, and an app inside a single buying decision, and a chunk of them refuse cookies outright. GA4 rebuilt the whole model around events and a privacy-durable idea of a user, so the measurement survives a world where the old session no longer describes how anyone actually behaves.
Spend ten minutes with someone who learned analytics on Universal Analytics and you will hear the grief. Bounce rate is gone. Sessions count differently. The reports they memorized have moved or vanished. It feels like Google broke a working tool out of spite. It did not. Universal Analytics was a 2012 design resting on a 2005 foundation, and the internet it was built to measure quietly disappeared underneath it.
Three forces did the killing. First, devices multiplied: a person researches a mattress on their phone at lunch, reads reviews on a work laptop, and buys on a tablet at night — Universal Analytics saw three disconnected sessions and three separate “users.” Second, apps mattered, and the session model never fit a mobile app where there is no page to view. Third, and most decisively, privacy law and browser changes (GDPR, Apple’s ITP, the long retreat of the third-party cookie) made the old deterministic tracking both illegal in places and technically unreliable everywhere. You cannot build trustworthy reports on a foundation that is cracking in three directions at once.
Claim: GA4 was announced on October 14, 2020, rebuilt around an event-based model with machine learning “at its core.” Source: Google — Introducing the new Google Analytics. Context: Google framed the change as a response to cross-device journeys and tightening privacy, not a cosmetic refresh.
Today we’re announcing a new, more intelligent Google Analytics — with machine learning at its core — to automatically surface helpful insights and give you a complete understanding of your customers across devices and platforms.
So the honest framing for the rest of this series is not “learn the new buttons.” It is: the questions changed. The right question stopped being “how many sessions did this page get” and became “what did people do, across every surface we own, and which of those actions are worth money.” Once you accept that, GA4’s strangeness starts to look like answers instead of obstacles.
When I onboard a team that is angry at GA4, the fix is almost never a setting. It is unlearning. They keep asking GA4 to answer Universal Analytics questions and reading its refusal as a bug.
I make them write their top ten reports on a whiteboard, then we cross out every one phrased as “sessions on a page” and rewrite it as “an action a person took.” Eight of the ten survive the translation and come back stronger.
The two that don’t survive were usually vanity metrics nobody acted on anyway. The grief passes fast once the questions are right.
The road from urchin.js to GA4
Google Analytics has four eras. Urchin (2005), the tracking engine Google bought. Classic Analytics with ga.js (2007–2012). Universal Analytics with analytics.js (2012–2023), which introduced the User ID and the measurement protocol. And GA4 (2020→), which began life as the “App + Web” beta in 2019 and became the only version still collecting data after Universal Analytics shut down on July 1, 2023. Each era was a response to how people had started using the internet.
Knowing this history is not trivia. It explains why GA4 looks the way it does — every odd decision is a scar from a previous limitation. Click through the eras below and watch the same pattern repeat: the web changes, the tool catches up, the old tool is retired.
Google acquires Urchin and relaunches it free as Google Analytics. The tracker, urchin.js, is page-view-centric and built for a one-device, desktop web. This is the genetic origin of the “session and pageview” worldview that everything fought against for the next two decades.
The ga.js snippet standardizes tracking across the web. Reports crystallize around sessions, pageviews, and bounce rate — the vocabulary a whole generation of marketers learned. Powerful for its time, and totally blind to mobile apps, which barely existed yet.
Universal Analytics arrives with analytics.js, the User ID feature (stitch a logged-in person across devices), custom dimensions, and the Measurement Protocol for server-side hits. It is the high-water mark of the session era — and the last version that assumed cookies would always be there.
Google launches “App + Web” properties in beta, fusing Firebase’s app analytics (already event-based) with web measurement into one event model. Almost nobody adopts it early. This beta is, structurally, GA4 before it had the name.
On October 14, 2020, Google rebrands App + Web as Google Analytics 4 and makes it the default for new properties. Event-based, cross-platform, machine-learning-driven, and built to model gaps left by missing cookies.
On July 1, 2023, standard Universal Analytics stops processing new hits (360 properties were given extra time). Overnight, GA4 is not the new option — it is the only option still collecting data. The migration everyone delayed becomes mandatory.
Claim: Standard Universal Analytics stopped processing new data on July 1, 2023. Source: Search Engine Land. Context: Universal Analytics 360 properties were granted additional processing time beyond the standard cutoff.
How much of the web runs on it
Google Analytics is the most widely deployed analytics tool on earth by a wide margin. Independent trackers put it on roughly 45–55% of all websites, and on the order of 80% of sites that use any known analytics tool — tens of millions of properties. That dominance is exactly why GA4 fluency is a career-grade skill: the odds that your next employer, client, or competitor runs on it are overwhelming.
Numbers vary by who is counting and how, so treat any single figure as a range, not gospel. The shape of the picture is what matters, and every credible source agrees on the shape: one tool, deployed almost everywhere, with no close rival.
Claim: W3Techs reports Google Analytics is used by roughly 46% of all websites and holds about an 81% share among sites that use a traffic-analysis tool. Source: W3Techs — Google Analytics usage. Context: Market-share figures differ across trackers (W3Techs, BuiltWith, Statista); the consistent finding is overwhelming market leadership, not a precise percentage.
One caveat worth saying out loud, because vendors blur it: “most popular” is not “most appropriate for every case.” Plenty of privacy-first shops run Matomo or Piwik PRO, and large enterprises layer Adobe alongside. GA4’s ubiquity is a reason to know it cold, not a reason to assume it is automatically the right and only tool for a given business. Good analysts hold both ideas at once.
The data model: everything is an event
In GA4 there is exactly one kind of data: the event. A pageview is an event. A purchase is an event. A scroll, a video play, a form submit — all events. Each event carries parameters (key–value details like page_location or value), and the user and session are attributes attached to events, not separate containers. Universal Analytics had many rigid hit types; GA4 collapsed them into one flexible primitive. That single change is the source of almost everything that feels different.
Picture the old model as a filing cabinet with fixed drawers: one drawer for pageviews, one for events, one for transactions, one for social interactions. If your data did not fit a drawer, too bad. GA4 threw out the cabinet and gave you a single, infinitely extensible note card — the event — with as many fields as you need to write on it. More freedom, and more responsibility, because nobody labels the cards for you.
Universal Analytics forced every interaction into a fixed type: pageview, event, transaction, social, timing, exception. Each had its own rules and its own reports. You could not invent a new kind of hit, and the “event” hit type was a cramped box of category / action / label / value.
GA4 has a single hit: the event. page_view, purchase, and your custom generate_lead are all the same shape — a name plus parameters. New kinds of interaction need no new infrastructure; you just send a new event name.
sign_up, not SignupBtn on one page and signup-form on another.The UA habit of cramming meaning into category / action / label does not translate. That structure was a workaround for having only one event hit type. In GA4 you attach as many named parameters as the action deserves.
A parameter is a key–value pair riding along with an event: currency: "USD", value: 49.00, method: "google". Some parameters are collected automatically; the useful business-specific ones you send yourself. To use them in reports as breakdowns, you register them as custom dimensions or metrics (Module 2).
GA4 still has sessions, but they are derived from events (a session_start event begins one) and time out differently than UA. Engaged sessions — 10+ seconds, a conversion, or 2+ pageviews — replace the old bounce rate.
“Bounce rate” as UA defined it (single-hit sessions) made no sense in an event world where a single rich page can fire dozens of events. GA4 measures engagement directly: time, conversions, depth. Bounce rate later returned as simply the inverse of engagement rate.
The single highest-leverage hour in any GA4 build is the one spent in a spreadsheet, not the tag manager. I list every event name, every parameter, its type, and an example value — the measurement plan — before a developer touches anything.
It feels slow. It is the opposite. Inconsistent names (purchase vs Purchase vs buy) are the number-one cause of GA4 data you cannot trust, and renaming after launch fractures your history permanently.
The spec is also how you hold a dev team accountable: the QA is “does the data layer match the sheet,” not “does it feel right.”
Account, property, data stream
GA4 has three nested levels. An account is the top container, usually one per company. A property is a single dataset for one product or brand — this is where reports, events, and configuration live. A data stream is a source of data feeding a property: one for your website, one for your iOS app, one for Android. One account can hold many properties, and that is exactly how you keep a multi-brand or multi-region organization’s architecture clean.
People get this wrong constantly, so be concrete. Think of the account as the building, properties as separate apartments inside it, and data streams as the doors into each apartment. A purchase from the website and a purchase from the iOS app are two doors (streams) into the same apartment (property), so they land in one combined, cross-platform dataset — which was the entire point of GA4.
For a company with three brands operating in two regions, the maintainable shape is one account, with properties split the way your reporting and access need to be split — not the way your org chart happens to look this quarter.
Account: Acme Corp → Properties: Brand A (US), Brand A (EU), Brand B, Brand C → Streams under each property: Web, iOS, Android. Each property is its own clean dataset; the account ties billing, users, and admin together.
Property = one dataset. Split properties only when audiences, access, or reporting genuinely must stay separate.
The hard rule that saves you later: a property boundary is a permanent reporting boundary. Data does not flow between properties, and you cannot retroactively merge two properties into one. So the design question is never “how is the company organized” — it is “which things must be reported together, and which must be walled apart for access or privacy reasons.” Get that judgment right at setup and you avoid the most expensive mistake in analytics: a property split you cannot undo.
New teams love to spin up a property for every country, region, and micro-brand. Then they discover they can never see the global picture in one report, because properties do not roll up for free.
My default is fewer, wider properties — use a single property with a parameter or a separate data stream to distinguish region, and only split into separate properties when law, data-residency, or hard access walls force it.
You can always filter one wide property down. You can never merge two narrow ones back together.
Free vs GA4 360
The standard version of GA4 is genuinely free and fits the vast majority of businesses. GA4 360 is the paid enterprise tier, with pricing that typically starts around $50,000 per year for roughly 25 million events per month, scaling up from there. What you actually buy with 360 is not “more analytics” — it is higher limits, unsampled large reports, longer data retention, a contractual SLA, and faster BigQuery export. If you are not hitting the free tier’s ceilings, 360 buys you very little.
Be skeptical of anyone who pushes 360 before you have a limit problem. The honest test is mechanical: are you actually bumping into the free tier’s walls? Most organizations are not, and the right answer for them is to invest that money in better implementation, not a bigger license.
Claim: GA4 360 pricing typically begins around $50,000 per year, covering up to roughly 25 million events per month, then scales with volume. Source: Cardinal Path / OptimizeSmart pricing analyses. Context: Exact 360 pricing is negotiated per contract and changes over time; treat the figure as an order-of-magnitude floor, not a quote.
- Is the free version really free, or limited junk?
- Genuinely free and fully featured for most use. The limits are about scale (events, custom dimensions, retention, sampling on huge queries), not about locking away core capability.
- When does 360 actually pay for itself?
- When you hit data thresholds (cardinality, sampling on large date ranges), need the 50-month retention, require an SLA for business-critical reporting, or need sub-daily BigQuery export at enterprise volume.
- Can I get unsampled data without paying for 360?
- Often yes — enable the free BigQuery export and query the raw events directly. That sidesteps most sampling for the price of some SQL, which is the subject of Module 6.
gtag, GTM, and the data layer
You have two mainstream ways to send data to GA4. gtag.js is Google’s tag you paste directly on the page — fast to start, painful to maintain at scale. Google Tag Manager (GTM) is a container you install once, then manage all tags inside without touching site code — the professional default. Feeding GTM is the data layer: a structured JavaScript object (window.dataLayer) where your site publishes facts (“a purchase happened, value 49.00, USD”) that tags read from. Master the data layer and you control measurement independently of marketing tags.
Here is the distinction that separates amateurs from professionals, and it is worth saying plainly. gtag hard-codes your measurement into the website. Every change — a new event, a fixed parameter — becomes a developer ticket and a deploy. GTM decouples the two: developers maintain a clean data layer once, and analysts manage tags on top of it at their own speed. The data layer is the contract between those two worlds, and a well-designed one is the most valuable artifact in the whole stack.
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: 'T-10492',
value: 49.00,
currency: 'USD',
items: [{ item_id: 'SKU-7', item_name: 'Starter Plan', price: 49.00, quantity: 1 }]
}
});The site publishes a fact. A GTM trigger fires on event: 'purchase'; a GA4 event tag reads the values and forwards them. Change the tag any time — the data layer never moves.
- Install one containerPut the GTM snippet sitewide (or use Google’s GA4 setup assistant). One install, then never touch page code for tagging again.
- Design the data layerAgree the object shape with developers from your measurement plan: event names, parameter keys, types. This is the contract; write it down.
- Build tags on triggersIn GTM, create a GA4 event tag that fires on a data-layer trigger and maps data-layer values to event parameters.
- Preview, then publishUse GTM Preview + GA4 DebugView to watch the event arrive with correct parameters before publishing. Never publish blind.
The failure pattern I see most: an agency builds a beautiful GTM setup reading from a data layer the client’s developers never agreed to own. Six months later a site redesign silently changes the data layer, every tag breaks, and nobody notices for weeks.
So I make the data layer a documented, version-controlled contract that lives in the dev team’s repo, with the analyst as a stakeholder on any change to it. Not a hidden marketing artifact — a first-class part of the codebase.
When the data layer is owned like product code, measurement stops silently rotting. When it is owned by nobody, it always does.
Client-side vs server-side
Client-side tagging runs in the visitor’s browser: the page sends data straight to Google and every other tool. It is simple and cheap, but it is exposed to ad blockers, browser privacy limits (ITP), and short cookie lifetimes — and it leaks data to whoever you put a tag for. Server-side tagging routes data through a server container you control first; the browser talks only to your domain, and your server decides what to forward where. It improves data quality, page speed, and privacy control — at the cost of running and paying for infrastructure.
The plain-language version: client-side is shouting your data across a crowded room where anyone can hear and a bouncer can mute you. Server-side is handing it to your own trusted clerk, who decides who gets a copy. For a small site the room is fine. As stakes and scale rise — more ad blockers, stricter regulators, more tools wanting the same data — the clerk starts to earn their keep.
Server-side tagging utilizes many of the concepts that are familiar to anyone who has worked with Google Tag Manager: there are tags which fire on triggers and pull in data from variables.
Do not let a vendor sell you server-side as a magic fix. It does not make tracking “cookieless” or sidestep consent — you still need a lawful basis, and dark-pattern uses of it are exactly what regulators are hunting. What it genuinely buys is control: cleaner first-party data, a lighter page, and one place to enforce what leaves your walls. That is valuable when you have the volume and the engineering to run it, and overkill when you do not.
IP-based internal filters were fine when everyone sat in one office. With a remote team on home Wi-Fi, VPNs and dynamic IPs, the list rots within weeks and your own staff quietly pollute conversions.
So I set a first-party cookie once on an internal-only page, read it into a GTM variable, and stamp every hit with a user property traffic_type=internal. The filter keys on that property, not on where someone happens to be sitting.
It follows the person, not the network — coffee shop, plane, new ISP, doesn’t matter — and it never needs maintaining.
How GA4 decides who a user is
GA4 stitches a person together across devices and sessions using an ordered list of identity spaces. It tries User-ID first (an ID you assign to logged-in users), then Google signals (data from signed-in Google users who opted in), then the device ID (the cookie/app instance), and finally modeling (machine-learning estimates that fill gaps left by missing cookies). You choose the reporting identity; getting User-ID flowing is the single biggest upgrade you can make to cross-device accuracy.
This is GA4’s direct answer to the privacy collapse that killed Universal Analytics. When cookies vanish or consent is declined, deterministic tracking simply has holes. Rather than report a confidently wrong number, GA4 layers from most-certain (a User-ID you provided) to least-certain (a modeled estimate), and is explicit that the tail is modeled. You are trading some precision for coverage that survives a consent-gated, cookie-poor web — an honest trade, as long as you know which parts are measured and which are estimated.
An ID you assign when someone logs in (never an email or anything personally identifying — a hashed internal ID). Sent as a parameter, it lets GA4 unify a person across phone, laptop, and app deterministically.
Data from users signed in to Google who turned on Ads Personalization. It enables cross-device reporting and remarketing without your own login — but it can trigger data thresholding (hidden rows) on small segments and has shrunk under privacy pressure.
The cookie on web or the app instance ID. This is the classic identifier — and the one most degraded by ITP, ad blockers, and consent declines. On its own it fragments the same person into many.
When consent is declined or cookies are missing, GA4 uses machine-learning models (behavioral and conversion modeling) to estimate the users and conversions you cannot directly observe.
- Create the property and a web data streamIn Admin, make the property, add a Web data stream for your domain, and copy the Measurement ID (G-XXXX). Don’t paste it anywhere yet.
- Install one GTM container, not the gtagPut the GTM snippet sitewide. In GTM, add a single Google Tag with your Measurement ID — this is your base/config tag, and the only place the ID lives.
- Set data retention and internal filters firstBefore collecting anything real, set retention to 14 months and create an internal-traffic filter. Doing this first keeps your baseline clean from day one.
- Turn on the free BigQuery exportLink BigQuery now (it is not retroactive). Even with no plan to query yet, you start banking raw data immediately.
- Build one event off the data layerAdd a GA4 event tag firing on a data-layer trigger; map data-layer values to parameters. Use GTM Preview to watch it.
- Verify in DebugView before publishingConfirm the event arrives with correct parameter names and values, cross-check the network
collectrequest, then publish. Never publish blind.
Order matters: retention, filters and the export come before real traffic, so your history is clean and complete from the first day.
Debugging before you trust a number
Never trust GA4 data you have not watched arrive. Three tools verify an implementation. DebugView shows events from your own device in real time, parameter by parameter. GTM Preview shows which tags fired and what they read from the data layer. The browser network tab (filter for collect) shows the raw request actually leaving the page. If an event is wrong, one of these three tells you exactly where it broke — before bad data pollutes weeks of reports.
The discipline here is the whole job. Amateurs implement a tag, glance at the realtime report, see a number move, and call it done. Professionals open DebugView and confirm the specific event arrived with the specific parameters from the measurement plan — correct currency, correct value, correct names — on the actual page, in the actual browser, before anyone makes a decision on it. Bad data is worse than no data, because no data forces caution and bad data invites confident, wrong choices.
- Open DebugViewEnable debug mode (GTM Preview does this automatically, or use the GA Debugger extension) and find your session in Admin → DebugView. You now see your own events live.
- Trigger the eventDo the real thing — submit the form, complete the test purchase. Watch the event appear in the timeline within seconds.
- Inspect every parameterClick the event. Confirm each parameter name and value matches your measurement plan exactly. Wrong currency or a misnamed key is found here, not in a report next month.
- Cross-check the network requestIn DevTools, filter network for
collect. The query string is the literal payload sent to Google — the ground truth when DebugView and your expectations disagree.
Data filters in GA4 are not a view you can toggle off later — once internal or bot traffic is filtered out of reporting, that exclusion is baked into what you can see. Useful, until the day you actually need the raw, unfiltered record.
So I treat the free BigQuery export as the unfiltered source of record and the GA4 UI as the clean working view. Filters keep the dashboards honest; the warehouse keeps everything, including what the filters removed.
When a fraud investigation or a weird traffic spike needs the unedited data, it is already sitting in BigQuery — not lost to a filter you can’t reverse.
Five mistakes that poison the data
Most untrustworthy GA4 setups fail the same five ways: inconsistent event names, no measurement plan, ignoring internal traffic, leaving data retention at the short default, and shipping without DebugView verification. None are exotic. All are cheap to prevent at setup and expensive—sometimes impossible—to fix after months of polluted history have accumulated.
purchase on one page, Purchase on another, buy_now on a third. GA4 treats them as three different events and your conversion total is silently split.
Implementing tag-by-tag with no spec guarantees drift, duplication, and parameters nobody can interpret later.
Office and developer traffic inflates engagement and fakes conversions, especially for low-volume B2B sites.
GA4’s default user-and-event retention is short. Explorations that reach further back silently return nothing, and people assume the data never existed.
Shipping a tag because the realtime card twitched is how wrong currencies and double-counted conversions reach production.
Your implementation checklist
A correct GA4 foundation is a finite, checkable list. Work down it in order: the early items make every later item trustworthy. Tick what is genuinely true of your property today — not what you intend to do.
Prove it. Earn your passcode.
Ten questions, CASE method (Context · Analysis · Strategy · Execution). Pass at 90% to unlock this module’s completion passcode — retake as many times as you like.