Google Analytics 4: Setup and Configuration Guide

This is a setup and configuration guide for Google Analytics 4 as it exists today, not a Universal Analytics migration walkthrough. If you’re reading this in 2026, you’re almost certainly setting up GA4 as your first analytics platform, or reconfiguring an existing GA4 property, not migrating off a platform that stopped processing data years ago. The rest of this guide is structured around getting GA4 configured correctly from where you’re starting today.

A brief note on Universal Analytics

For context: Universal Analytics existed as Google’s previous analytics platform before GA4. Standard (free) UA properties stopped processing new data on July 1, 2023. UA 360 (the enterprise tier) had its sunset date extended and stopped processing data on July 1, 2024, after which UA properties and their API access were removed entirely. If you’re still referencing old UA reports or documentation, know that both are gone. That’s the entire relevant history for a 2026 setup, GA4 is simply the platform now.

Property and data-stream setup

A GA4 property is the top-level container for your data. Within it, you create data streams, one per web domain, iOS app, or Android app you’re tracking, each of which gets its own Measurement ID (for web) used to connect your site to the property.

Basic setup steps:

1. Create the property in the GA4 admin interface, setting your reporting time zone and currency correctly at creation, since changing these later doesn’t retroactively correct historical data.
2. Add a web data stream for each domain you want tracked separately.
3. Install the tracking code, either directly via gtag.js or through Google Tag Manager (more on this choice below).
4. Confirm data is flowing using the Realtime report before assuming setup is complete. This is a five-minute check that catches most installation mistakes immediately rather than days later.

If your organization operates multiple related domains or subdomains that a single user might cross during one session, for example a marketing site and a separate checkout subdomain, configure cross-domain measurement in the data stream settings so GA4 recognizes that visit as one continuous session rather than two separate ones with a fresh session and a referral entry recorded at the handoff point. Skipping this is a common cause of inflated session counts and misattributed traffic sources on sites with this kind of multi-domain structure.

Key events (conversions) setup

GA4 calls conversions “key events.” Any event you’ve collected can be marked as a key event in Admin > Events, which flags it for conversion-focused reporting and, if you’re running Google Ads, makes it available as a conversion action there.

A property can have a maximum of 30 key events per property according to Google’s current GA4 configuration limits documentation. If you need more than that, either consolidate less-critical events or evaluate whether they need to be tracked as key events at all versus just regular events available in exploration reports.

Data retention configuration

GA4’s data retention setting controls how long event-level data (used in explorations and funnel reports, not standard aggregated reports) is kept before being automatically deleted. Per Google’s data retention documentation:

• The default retention period is 2 months.
• Standard GA4 properties can be configured up to a maximum of 14 months.
• This setting only affects explorations and funnel-style reports. Standard aggregated reports in the interface are not affected by the retention window, even when comparisons are applied.

The genuinely useful detail most setup guides skip: properties that Google classifies as Large (over 25 billion billable events in the last 31 days) or, for 360 properties, XL (over 250 billion), have their event-level retention automatically reduced to 2 months regardless of what you’ve configured, and it stays there. Google does send a warning email to property administrators when a property is on pace to cross that threshold, and a second email once the reduction actually takes effect, but both arrive after the fact rather than as a setting you can proactively lock in, so the retention window still shrinks out from under whatever you’d configured. If you’re doing longer-window exploration analysis and rely on more than 2 months of event-level history, this is worth checking against your actual event volume, not just your configured setting.

Attribution model configuration

Data-driven attribution (DDA) has been GA4’s default attribution model since November 2023, replacing last-click as the out-of-the-box setting for both new and (for properties that hadn’t changed the setting) existing properties. DDA uses your property’s own conversion data to algorithmically distribute credit across the touchpoints in a conversion path, rather than crediting the entire conversion to the last click.

The genuinely useful, commonly missed detail: per Google’s current data-driven attribution documentation, there is no longer a hard minimum-conversion requirement gating DDA, all conversion actions are eligible regardless of volume, and Google does not silently fall a property back to last-click for missing a threshold. That said, volume still affects quality: Google’s own guidance is that the model works better with more data, and recommends having a healthy baseline of conversions and interactions (Google Ads cites roughly 200 conversions and 2,000 ad interactions within 30 days as a rough floor for reliable modeling) rather than a hard cutoff. For a low-volume property, particularly a newer site or one with a narrow set of conversion actions, DDA is still active, but treat its channel-credit splits with more skepticism until the property accumulates more data, since a low-data model has more room to overweight noise. Older claims of a strict 400/20,000-conversion threshold with a silent last-click fallback describe a legacy Universal Analytics mechanism, not how GA4 works today, so don’t audit for that specific failure mode.

When would you deliberately choose a different model instead of DDA? Mainly when you specifically need a simpler, more interpretable model for a particular analysis, comparing channel performance under a strict last-click view, for instance, though for general reporting, DDA remains the more accurate default when your property has the volume to support it.

Implementation method: gtag.js vs. Google Tag Manager

You can connect GA4 to your site two ways: gtag.js, Google’s tracking snippet placed directly in your page code, or through Google Tag Manager (GTM), which manages GA4 and other tags through a separate tag-management layer rather than hardcoding tracking code into your templates.

GTM is the more common choice for teams managing multiple tags (analytics, ads conversion tracking, third-party pixels) since it centralizes tag management without requiring a code deployment for every tag change. gtag.js directly is simpler for a single-tag setup with no expectation of adding more tracking tools later. Either method gets GA4 data flowing; the choice is about tag-management convenience, not a GA4 feature difference. Marketing teams that need to adjust tags without involving a developer for every change tend to prefer GTM specifically for that operational reason, not because it collects different or more complete data.

If you’re using GTM, how efficiently your container and its tags are configured has its own performance implications, container weight, tag-firing efficiency, and whether server-side tagging makes sense for your setup, that are specific enough to warrant their own treatment. That’s covered in the Google Tag Manager Performance: How Tags Slow Pages Down and How to Fix It guide rather than here.

Privacy and consent basics

If you have visitors from the European Economic Area (EEA), Google’s own Tag Manager consent mode documentation states that to keep using measurement and ad personalization features for EEA users, you need to collect and share consent signals with Google via two consent parameters, ad_user_data and ad_personalization. Enforcement of this requirement for EEA traffic began in March 2024. The mechanism is Google Consent Mode, implemented either through Google Tag Manager’s built-in consent settings or directly via the gtag consent API, which adjusts how (and whether) GA4 and other Google tags collect and send data based on the consent status you report for each visitor.

The nuance worth getting right: this isn’t a single one-time toggle you flip. Consent Mode operates on a per-signal basis (analytics storage, ad storage, ad user data, ad personalization), and GA4 behaves differently depending on which signals are granted or denied for a given visitor, including using modeled (statistically estimated) conversion data to help fill gaps when consent is denied, rather than simply collecting nothing. At a minimum, the mechanism requires two pieces before any consent banner logic: default consent state must be set (typically denied for EEA visitors until they respond) before the GA4 tag fires, and that default has to update to the visitor’s actual choice once your consent management platform (CMP) reports it, either through GTM’s built-in consent settings on each tag or a gtag('consent', 'update', ...) call. The specific wiring, which signals your CMP passes and how, differs by vendor, so verify your specific implementation against Google’s current Consent Mode documentation directly rather than a generic “just add this one snippet” description.

Linking Google Ads and BigQuery

Two links are worth setting up during initial configuration rather than as an afterthought:

Google Ads. Linking your Google Ads account to your GA4 property lets your marked key events flow into Ads as conversion actions and enables audience sharing between the two platforms. This is a straightforward Admin-panel link, but it needs to happen before you start relying on GA4 data for Ads optimization, since it doesn’t backfill historical data retroactively.

BigQuery export. Enabling raw event-level export to BigQuery is worth knowing about even if you don’t plan to use it immediately, since it’s the only way to access GA4 data at the individual-event level beyond what the retention window and standard reports expose. Contrary to older claims that this feature carries a steep annual cost, Google’s BigQuery export documentation confirms the export itself is free to enable for standard GA4 properties, there’s no platform charge from Google Analytics for turning it on. What you pay for, if anything, is the underlying Google Cloud Platform usage (data storage and query processing) once you exceed Google Cloud’s own free tier, which for a small-to-mid-size site’s worth of data commonly stays within the free allowance or amounts to a modest monthly cost rather than a large fixed fee. Standard (non-360) properties are capped at a daily batch export of 1 million events per day, worth knowing if your site has enough volume that this ceiling is a realistic constraint.

Other configuration limits worth knowing

A handful of numeric limits are worth checking directly rather than assuming, since GA4’s limits have changed before without a site-wide announcement. As of this writing:

• Event parameters: 25 per event, per Google’s current event collection limits documentation (not 50, a number that circulates in some older third-party guides).
• User properties: 25 per property, per the same event collection limits documentation.
• Audiences: 100 per property, per the configuration limits documentation.

Because these numbers are the kind Google adjusts periodically, confirm the current figures against the linked support pages directly at the time you’re configuring a property, rather than treating any number in this guide, or any other, as permanently fixed.

Checklist

• Set the correct time zone and currency at property creation.
• Confirm data flow with the Realtime report immediately after setup.
• Mark key events deliberately, staying within the 30-per-property limit.
• Set data retention up to 14 months if you rely on exploration reports beyond the 2-month default, and check whether Large/XL classification affects your actual retention window.
• DDA is active by default regardless of conversion volume, no need to audit for a silent last-click fallback; just treat credit splits on low-volume conversion actions with more skepticism until data accumulates.
• Choose gtag.js or GTM based on how many tags you’re managing, not a GA4 feature difference.
• Implement Consent Mode correctly for EEA traffic if applicable, verified against Google’s current documentation.
• Re-verify event parameter, user property, and audience limits against current support.google.com documentation before relying on them.