Google Analytics tracks what people do on your website or app, organizes that activity into structured data, and presents it in reports you can use to understand your audience and improve your business. It works by placing a small piece of JavaScript code on every page of your site (or an SDK in your mobile app) that records each interaction a visitor takes, then sends that data to Google’s servers for processing and reporting.
How Data Gets Collected
When someone visits your website, the tracking code (called gtag.js) runs in their browser and creates a first-party cookie named _ga. This cookie stores a client ID, which is a randomly generated identifier that distinguishes one visitor from another and ties their activity together across multiple pages and return visits. No personal information like a name or email address is stored in this cookie. It simply tells Analytics, “this is the same browser that visited yesterday.”
For mobile apps, the process is similar but uses Google’s Firebase SDK instead of JavaScript. The SDK automatically generates an app-instance ID for each installation of your app. It can also collect device advertising identifiers if the user has allowed it. On Android, the SDK collects the Advertising ID by default as long as the developer has included the required permission. On iOS, the SDK can only collect Apple’s Advertising Identifier (IDFA) if the user explicitly grants permission through Apple’s App Tracking Transparency prompt, which has been required since iOS 14.5.
Once the tracking code or SDK is running, it monitors interactions and sends the data to Google’s servers. Most events are batched together in groups of up to 20 rather than sent one at a time, which reduces the load on both the visitor’s browser and Google’s servers. Key events (the interactions you’ve marked as most important, like a purchase or a form submission) are transmitted immediately. There’s a 16 KB size limit on each batch of event data sent to Google. If a batch exceeds that limit, it still gets sent but won’t be processed.
The Event-Based Data Model
Everything Google Analytics records is structured as an “event.” An event is any specific interaction or occurrence: loading a page, clicking a link, completing a purchase, scrolling down the page, watching a video, even an app crashing. Rather than thinking in terms of pageviews and sessions (the way the older Universal Analytics worked), GA4 treats every interaction as an event with its own set of descriptive details attached.
Events fall into four categories:
- Automatically collected events are recorded the moment you install the tracking code, with no extra setup. These include things like the first time a user visits your site or when a session starts.
- Enhanced measurement events are also collected automatically, but only when you toggle on the enhanced measurement setting in your property. These cover common interactions like page scrolls, outbound link clicks, site searches, video plays, and file downloads.
- Recommended events are ones you set up yourself, but using names and parameters that Google has predefined. For example, if you run an online store, Google recommends naming your purchase event “purchase” and attaching specific parameters like transaction ID, value, and currency. Following these conventions unlocks built-in reports and features designed around those event names.
- Custom events are events you define entirely on your own for interactions that don’t fit any of the above categories. You choose the event name and the parameters.
Each event can carry additional details called parameters. A “page_view” event, for instance, carries parameters like the page title and page URL. A “purchase” event carries parameters like the transaction value and items bought. These parameters are what give your reports depth beyond simple event counts.
How Analytics Identifies Users
One of the trickiest problems in web analytics is figuring out whether the person browsing on a phone this morning is the same person who browsed on a laptop last night. Google Analytics uses multiple layers of identity to solve this, checking them in order of reliability.
The most accurate method is User-ID. If your site has a login system, you can send a consistent identifier for each signed-in user to Analytics. Because this ID stays the same regardless of which device or browser they use, it gives you the clearest picture of cross-device behavior. You have to set this up yourself, and it only works for users who actually sign in.
Next is Device-ID, which on websites comes from the client ID stored in the _ga cookie, and on apps comes from the app-instance ID. This reliably identifies a single browser or a single app installation, but it can’t connect the same person across different devices or browsers.
Finally, when users decline cookies or other identifiers entirely, Analytics uses modeling. It looks at the behavior of similar users on your site who did accept cookies and uses that pattern to estimate the behavior of users who didn’t. This fills gaps in your data rather than leaving those visitors as complete blind spots, though it’s inherently less precise than direct measurement.
What Happens When Users Decline Cookies
Privacy regulations in many regions require websites to ask visitors for consent before setting cookies. Google Analytics handles this through a feature called consent mode, which adjusts how the tracking code behaves based on each visitor’s choice.
If you implement basic consent mode, Google’s tags don’t load at all until the visitor interacts with your consent banner. If they decline, no data is sent to Google whatsoever. This is the strictest option.
If you implement advanced consent mode, the tags load when the page loads, but they behave differently depending on the visitor’s consent status. Before the visitor makes a choice (or if they decline), the tags send limited “cookieless pings” instead of full tracking data. These pings contain only coarse information: a timestamp, the browser’s user agent, a referrer, whether the page URL contained ad-click parameters, the consent state itself, and a random number generated on page load. No cookies are set, and no personal identifiers are collected.
Google then uses these pings, combined with data from consenting users on the same property, to build models that estimate the metrics you would have seen if everyone had consented. The advanced implementation produces more accurate models because it has more signal to work with compared to the basic version, which has none at all from declining users.
Dimensions and Metrics in Reports
Once data arrives at Google’s servers, it gets organized into two fundamental building blocks that power every report you’ll see in the Analytics interface.
Dimensions are attributes that describe your data. Think of them as labels or categories: the city a visitor is in, the page they viewed, the device they used, or the marketing campaign that brought them to your site. Metrics are the numbers that measure what happened: how many users visited, how many sessions occurred, how long people stayed engaged, how much revenue was generated. Every report in Google Analytics is some combination of dimensions and metrics. For example, pairing the “country” dimension with the “sessions” metric shows you how many sessions came from each country.
Beyond the standard dimensions and metrics that come built in, you can create custom ones based on the event parameters you collect. If you send a parameter called “membership_tier” with your events, you can register it as a custom dimension and then break down any metric by membership tier. Each custom metric you register automatically generates three variations: a sum, an average, and a count, so you can analyze it from multiple angles without extra configuration.
From Raw Data to Actionable Reports
Google Analytics processes collected events and presents them across several report categories in its interface. Real-time reports show activity happening on your site right now, which is useful for verifying that tracking is working or monitoring the immediate impact of a campaign launch. Life cycle reports cover acquisition (how users found you), engagement (what they did), monetization (what they spent), and retention (whether they came back). User reports break down your audience by demographics and the technology they use.
Beyond these standard reports, the Explorations section lets you build custom analyses. You can drag dimensions and metrics into freeform tables, create funnel visualizations that show where users drop off in a multi-step process, or build path explorations that reveal the most common sequences of pages people visit. For organizations that need even deeper analysis, GA4 can export raw event data to BigQuery (Google’s data warehouse), giving you access to every individual event for SQL-based querying.
The entire pipeline, from the moment a visitor triggers an event to the moment that event appears in a report, typically takes 24 to 48 hours for standard reports. Real-time reports update within seconds but show only a limited snapshot. Processing delays are normal and expected, so if you don’t see today’s data in your reports yet, that’s how the system is designed to work.