A Practical Guide to Google Analytics
How Google Analytics is built, from Urchin's original tracking code to GA4's event model, and what that architecture means for your numbers.
Google Analytics began life as a company called Urchin Software, which Google acquired in 2005 and rebuilt into a free tool that would eventually become the default analytics platform for a huge share of the web. That lineage matters less than what Google has done to the product since, because the tool most people use today, GA4, works on fundamentally different principles than the version that dominated the 2010s.
From sessions to events
For most of its history, Google Analytics organized data around sessions: a visit made of a sequence of pageviews, with metrics like bounce rate and session duration built on top of that structure. GA4, which Google introduced in 2020 and made the default property type after retiring the older Universal Analytics in mid-2023, replaced that with an event-based model. Every interaction, a pageview, a scroll, a click or a purchase, is recorded as an event carrying its own set of parameters. Sessions still exist as a derived concept, but the underlying data is events first.
This shift isn’t cosmetic. It means GA4 can natively track things Universal Analytics needed custom workarounds for, like scroll depth or video engagement, and it means the same event structure works whether the data comes from a website or a mobile app, which is why GA4 properties can combine both into one dataset.
How data reaches Google’s servers
A GA4 property is fed by a tracking snippet, usually deployed through Google Tag Manager rather than pasted directly into a site’s code, which fires events to Google’s collection endpoints. Each event can carry custom parameters, what was clicked or purchased and how much it cost, and user properties describing the visitor. Google Signals, an optional setting, lets GA4 link this activity to signed-in Google accounts across devices, which is how it can report cross-device behavior instead of treating a phone and a laptop as two unrelated visitors.
Where sampling and thresholds come from
Two quirks confuse a lot of people new to GA4. High-volume properties can be subject to sampling in ad hoc exploration reports, where Google analyzes a subset of the data and extrapolates, which is disclosed in the report but easy to miss. Separately, GA4 applies data thresholds that suppress rows in reports involving Google Signals when the underlying group of users is small enough that individuals could plausibly be identified. Neither is a bug. Both exist because the architecture is built to balance useful reporting against exposing individual-level behavior.
Getting the raw data out
Because GA4’s standard reports summarize and round data for privacy reasons, anyone doing serious analysis eventually wants the underlying event-level data, which GA4 makes available through a free BigQuery export. That export contains every event with its full parameters, unsampled, and it’s the layer most agencies and analytics teams build custom reporting on top of, using tools like Looker Studio rather than the native GA4 interface.
What this means in practice
Treat GA4 as an events database with a reporting layer on top, not as a session counter with a new coat of paint. Define the key events, GA4’s term for conversions, that matter to your business early, since almost every useful report depends on them being configured correctly. Use Google Tag Manager rather than hand-editing tracking code, since it’s how most parameter-level tracking gets maintained over time. And if you need precise, unsampled numbers for a real decision, go to the BigQuery export rather than trusting a summarized report at face value.
