A Google Analytics account is the top-level container that holds everything else in GA4 — your properties, your data streams, your users, and your billing relationship with Google. You log into analytics.google.com, and the first thing you see is the account selector. Underneath each account sits one or more properties; underneath each property sit one or more data streams. Get this hierarchy right on day one and the rest of GA4 falls into place. Get it wrong, and you'll be untangling permissions and duplicate properties for years.

This guide walks through everything an owner, marketer, or in-house SEO needs to know about the account layer specifically — not the reports, not the audiences, not the conversions. Just the plumbing: how to create the account, how the four-level hierarchy works, who to add and with what role, how to set data retention so your reports don't go blank after eight weeks, and how to clean up or delete an account when a project ends. By the end, you'll have a complete google analytics account that's ready for content work, paid campaigns, and SEO measurement.

Most of the friction people hit isn't with GA4 itself. It's with structural decisions made before any reports are pulled. Do I create one account or three? Should the agency be an Editor or an Administrator? Why did I lose all my historical data? Each section below covers the question, the answer, and the click path inside the GA4 admin to apply it.

Throughout this guide we reference the GA4 admin panel — the gear icon in the bottom-left of any GA4 view. Most settings discussed live there: account creation, property creation, user management, data retention, data filters, data stream configuration, and product linking. Bookmark admin in your browser; you will return to it constantly during the first month, then maybe once a quarter forever after. Everything outside admin (the Reports section, Explorations, Advertising, Library) consumes data; admin is where you configure how that data flows in.

A note on terminology: in this article, "account" refers specifically to the GA4 account container, not your Google login. Your Google login (the gmail or workspace email you signed in with) can own or have access to many GA4 accounts. The two concepts use the same word but are unrelated. Always be explicit when discussing access — "my Google login" vs "the GA4 account" — especially in team conversations where the same word can mean two completely different things.

The mistake most people make is creating a new account for every website. Don't. One account for one business or organization is the rule. If you run three brands, create three accounts. If you run one brand with three sites — say a main domain, a blog subdomain, and a course platform — that's one account with three properties (or sometimes one property with cross-domain measurement, depending on whether you want unified user counts). Splitting one business across multiple accounts makes google analytics for seo reporting fragmented and forces you to switch accounts constantly.

The other mistake is creating one property for each subdirectory or section. A property is a website, not a section. /blog, /shop, and /support all belong in the same property. Use content groupings or filters to slice the data, not separate properties. Creating a separate property for the blog might feel cleaner during setup, but six months later you can't compare blog traffic against shop traffic in a single chart without exporting both to a spreadsheet.

A third trap is using a personal Gmail to create the account. The person who creates the account becomes the default Administrator. If that person leaves the company, you may lose access to your own analytics — Google does not have a customer-service path to transfer ownership without that account's cooperation.

Always create accounts under a company email tied to a workspace your business controls. If you've already made this mistake, fix it today: add a company Google account as a second Administrator, log in as that company account, and then remove the personal Gmail. Don't wait for the founder's departure to discover the problem.

You may also see references to "subproperties" and "roll-up properties." These are Analytics 360 features only — they let an enterprise create a property that aggregates data from multiple source properties (roll-up) or a filtered view of one parent property (subproperty). Free GA4 does not offer either. If you need aggregated reporting across multiple free GA4 properties, the only option is BigQuery — export each property to the same dataset and query them together with SQL. That is more flexible than 360 roll-ups in many ways, just more technical to set up.

Once the property exists, the property selector in the top-left of GA4 lets you switch between properties owned by the same account. Each Measurement ID is unique to its data stream — install the right one on the right site.

If you copy the G-ID from your staging property onto your production site, every visit goes into the wrong property and you'll spend a week wondering why production analytics look empty. Always create two separate properties from day one — Production and Staging — and route traffic appropriately via your tag manager. It's free, takes two minutes, and saves serious debugging headaches later.

For e-commerce or apps with iOS + Android + Web, create three data streams under one property so cross-platform user counts deduplicate correctly. GA4 stitches identity across streams using a combination of User-ID (if you set it), Google Signals (if enabled), and device-graph modeling. With three separate properties for the same business, you'd be looking at three siloed datasets that never reconcile. The unified user count is one of the biggest practical wins of GA4 over the old Universal Analytics model — but only if you set up the property correctly.

When installing the Measurement ID, three common deployment methods exist. Native Google Tag (gtag.js) pasted directly into the site header — simplest, works on any platform. Google Tag Manager — best if you'll run multiple tracking tools (Meta Pixel, LinkedIn Insight Tag, etc.) and want to manage them without code deploys. A CMS-native plugin — WordPress has a dozen, Shopify and Wix have built-in fields. Pick one method per site and stick with it. Mixing gtag.js and a plugin both firing on the same page produces double-counted pageviews, the #1 cause of inflated traffic reports the first month after setup.

Cross-domain measurement deserves its own paragraph. If your business spans multiple domains a user might cross during one session — for example, a marketing site on acme.com and a checkout flow on checkout.acme.com — you need cross-domain tracking enabled so GA4 treats the visit as one session, not two. Configure it at Admin → Data Streams → click the web stream → Configure tag settings → Configure your domains → Include domains that match. List every domain that should count as the same site. Without this, every domain transition starts a new session and the second domain inherits "Referral / acme.com" as its acquisition source — destroying your true source attribution.

Data retention is the single most-skipped setting in GA4 setup. The default of two months means that if you open a custom Exploration in March to look at user behaviour from December, the data is gone — and Google does not warn you. Change it once, immediately after creating the property, and never think about it again. For event data you want kept forever in queryable form, link BigQuery on the same admin page; the free tier covers most small business volumes. We cover the full BigQuery linking flow in the google analytics course guide.

BigQuery linking is the most important feature buried in the Admin panel. Once linked, every event GA4 collects exports to a BigQuery dataset within 24 hours (or near-real-time on the streaming export tier). The data is queryable SQL — no sampling, no aggregation, no UI limitations.

For SEO, marketing, and product teams who want to ask questions GA4's reports can't answer (cohort analysis at the user-event level, custom funnel paths, attribution modeling), BigQuery export is non-negotiable. The free GCP tier covers up to 1 GB exported per month, and even small e-commerce sites usually stay well inside that. Set it up on day one, even if you don't query it for six months — the data accumulates from the linking date forward, not retroactively.

The Google Signals toggle is another setting worth understanding. Found at Admin → Data Collection → Google Signals, it enables cross-device tracking for signed-in Google users who've opted into Ads Personalization. With it on, your user counts reflect unique humans across phones, laptops, and tablets — not session-based device counts. Without it, the same person visiting from work then home appears as two users. The trade-off: certain demographic reports become thresholded (hidden) for low-volume segments to protect user privacy, so smaller sites may see 'data not shown' in some breakdowns. For most B2C and content sites, leave it on.

While you are in the Data Settings panel, also check Data Filters. Two filters are worth setting up immediately. The Internal Traffic filter excludes your office and home IP from reporting — invaluable for small businesses where staff visits would otherwise dominate low-traffic data. Configure it as Active (not Testing) once you have verified it correctly identifies your IP. The Developer Traffic filter excludes traffic flagged with a debug parameter — useful if you use the GA Debugger Chrome extension while testing. Both filters apply only to new data going forward; they cannot retroactively scrub already-collected traffic.

The 100-account-per-Google-login limit is real but almost nobody hits it. The one that bites mid-sized businesses is the distinct event names per property cap — every uniquely named event (button_click_homepage_hero, button_click_homepage_cta, button_click_pricing_page, …) eats into the 500-event budget. Use event parameters instead of unique names. One event called button_click with a location parameter is far better than 50 events with embedded location names. Once you blow past 500, GA4 starts grouping the overflow into an (other) bucket that is essentially useless for analysis.

Conversion events used to cap at 30 per property — that limit has been relaxed in 2025/2026 but still treat it as scarce. Each conversion should be a real business outcome (purchase, lead form submitted, demo booked) not a behavioural micro-event (button clicked, scrolled 50%). Track micro-events as standard events, not conversions. The conversions report becomes useless when 40 events are flagged as conversions because every report is dominated by scroll_50 and outbound_click — the real revenue events get buried.

For enterprises hitting any of these limits, google analytics practice test 360 is the paid upgrade. Entry pricing starts around $150,000 per year and is contracted on a one-year minimum. What you get: 30 million events per month in BigQuery export (instead of 1 GB), sub-day data freshness, unsampled custom reports up to massive row limits, custom funnels with more than 10 steps, deeper integration with Display & Video 360, and a 99.9% SLA.

For most businesses, free GA4 is more than enough. For Fortune-500 e-commerce platforms, content publishers with billions of monthly events, or anyone running programmatic media buys, the 360 upgrade pays for itself in a single reporting cycle.

One non-obvious limit worth knowing: custom dimensions and metrics are capped at 50 each per property on the free tier. Custom dimensions are how you pass extra context with events — user_type, content_category, plan_tier, anything beyond GA4 defaults. Plan their use carefully. Once you create a custom dimension, you can disable or rename it but not actually delete it, and the 50-slot budget never resets. Audit them yearly. The Analytics 360 tier raises this to 125 each, which still gets tight for complex e-commerce or SaaS setups.

For 90% of small to mid-sized businesses, one account with multiple properties is the right answer. Separate accounts only make sense when the brands are legally separate entities, when there's a real chance of selling or spinning one off, or when access boundaries must be absolute. The single-account model is also much easier to inherit when a team member leaves — you transfer Administrator once, not three times. It also makes BigQuery export cheaper since you're managing one billing project instead of three.

An exception worth noting: agencies managing analytics for many unrelated clients should always use separate accounts per client, never a single agency-level account holding all client properties. Why? When a client offboards, you want to transfer their entire account to them — not extract one property from a shared account, which is messy and error-prone. The clean handoff is 'here's the entire GA account, I'm removing myself as Administrator, you're now the sole owner.'

One final point on account portability: there is no "export account" feature in GA4. The data is locked to the property where it was collected. Even if you transfer ownership of an account from one Google login to another, the data does not move — only the access does. If you want true portability (the ability to take your raw data with you), the answer is, again, BigQuery export. The export gives you a SQL-queryable copy of every event in your own Google Cloud project, which you control independently of GA4. This is also the only way to retain analytics history if you ever migrate off Google Analytics entirely.