One or Separate? GA4 Measurement Strategies for Domains & Subdomains

In Google Analytics 4 (GA4) implementation, one architectural decision often considered trivial but having a big impact is whether subdomains should have their own Measurement ID or just share with the main domain. Mistakes at this stage aren’t immediately visible — the site keeps sending data, dashboards keep filling with numbers — but the effects appear slowly later: abnormally inflated user counts, funnels breaking without clear reason, misdirected conversion attribution, and insights that end up shallow even though the data looks complete. This article dissects the mechanism behind both approaches, their concrete technical trade-offs, and how to implement the hybrid approach used by many production systems.

Understanding the Terms: Property, Data Stream, Measurement ID

Before getting into the decision, it’s important to align on terms and understand the hierarchy — because these three terms are often used interchangeably even though they represent different levels.

flowchart TD
    A[GA4 Property] --> B[Data Stream: Web]
    A --> C[Data Stream: iOS App]
    A --> D[Data Stream: Android App]
    B --> E[Measurement ID: G-XXXXXXX]
    C --> F[App ID + Stream ID]
    D --> G[App ID + Stream ID]

• GA4 Property is the main analytics data container — one property can hold data from many sources at once
• Data Stream is one specific data source inside the property, which can be web, iOS app, or Android app
• Measurement ID (G-XXXXXXX) is the unique identity for a web-type data stream — this is the ID pasted into a page’s tracking code

One property can have many measurement IDs (via many data streams), but one measurement ID only represents a single stream. The “one or separate” decision discussed in this article is actually a decision about how many web data streams are created to represent your domain and subdomains — not about the number of properties.

How GA4 Identifies Users Across Subdomains

The claim that “one measurement keeps the user journey intact across subdomains” is often mentioned without explaining its mechanism — even though understanding how this user identification works is the key to truly understanding why this approach has a big impact, not just about data tidiness.

GA4 identifies users mainly through a first-party cookie named _ga, which stores a unique client_id per browser. By default, this cookie is scoped to the main domain (eTLD+1), not to the specific subdomain where it was first created.

sequenceDiagram
    participant User
    participant Blog as blog.example.com
    participant App as app.example.com
    participant GA4
    User->>Blog: Visit blog
    Blog->>User: Set _ga cookie (scope: .example.com)
    User->>App: Move to app
    App->>User: Read the SAME _ga cookie
    Note over Blog,App: Because the cookie scope is on the main domain,<br/>both subdomains read the same client_id
    App->>GA4: Send event with the same client_id
    Note over GA4: If the measurement ID is the SAME,<br/>GA4 merges this as 1 user

This is the core mechanism: the _ga cookie can indeed be read across subdomains because its domain scope is deliberately set to the main domain. But the same cookie alone isn’t enough — GA4 only merges data as one user if those events are also sent to the same measurement ID. If blog.example.com sends to G-AAA and app.example.com sends to G-BBB, even though the client_id cookie is identical, GA4 processes them as two separate properties/streams that never know about each other’s existence.

The _ga cookie shared across subdomains is a technical prerequisite, not an automatic guarantee. A complete user journey only truly happens when this shared cookie prerequisite is paired with the same measurement ID across all involved subdomains.

Two Main Approaches

flowchart TD
    subgraph A["Approach A: One Measurement"]
        A1[example.com]
        A2[blog.example.com]
        A3[app.example.com]
        A1 --> AID[G-XXXXXXX]
        A2 --> AID
        A3 --> AID
    end
    subgraph B["Approach B: Separate Measurements"]
        B1[example.com] --> BID1[G-AAA]
        B2[blog.example.com] --> BID2[G-BBB]
        B3[app.example.com] --> BID3[G-CCC]
    end

Approach A — all domains and subdomains send events to the same Measurement ID, fully utilizing the shared cookie mechanism explained above.

Approach B — each subdomain has its own Measurement ID, each becoming a completely isolated data unit even though technically the cookies can still be shared.

Approach A: One Measurement ID

Advantages

Complete user journey. Because of the mechanism from the previous section — shared cookie + same measurement — a user going from the blog to the app is still counted as 1 user, not 2. Sessions aren’t split, and cross-subdomain funnels can be analyzed as one complete flow. This is crucial for scenarios like content marketing leading to signup, SEO optimization leading to conversion, or SaaS onboarding involving a landing page separate from the main application.

More accurate attribution. Traffic sources from the blog — organic search, referral, social media — remain fully readable when the user eventually converts on the app subdomain. This is because GA4 stores acquisition information at the same user/session level, not at a separate measurement level. If measurements are separated, this initial acquisition information is completely lost — conversions in the app will appear to come “from nowhere” instead of from the specific blog campaign that actually brought that user.

Less operational overhead. One data stream configuration, one consistent event taxonomy, one dashboard as the source of truth. Engineering-wise, this is far more sustainable to maintain long-term than managing many parallel properties.

Disadvantages

Data mixed in one dataset. Page views from the blog and from the app sit in the same raw data table. But this is a reporting problem, not an architectural one — it can be fully solved with built-in dimensions like hostname, page_path, or additional custom dimensions (discussed in more detail in the hybrid implementation section).

Team ownership is less clear. If the blog and app are managed by completely different teams, with one measurement, extra effort is needed to create per-team segmented reports — although this is also solved with consistent hostname filters.

Approach B: Separate Measurements

Advantages

Totally isolated data. KPIs have very clear boundaries, no cross-domain noise to filter, and this suits multi-product scenarios that are indeed completely independent of each other.

Suitable for truly different products. Real examples: a public blog, an internal admin tool, or a client-specific dashboard, each with completely different audiences and analytics purposes. In such cases, separating measurements is actually the right decision — because there’s indeed no realistic user journey connecting them.

Disadvantages (Critical)

Users and sessions are split technically, not just in reporting. This isn’t a configuration limitation that can be worked around — GA4 architecturally doesn’t merge data between different measurement IDs, even if the client_id cookie is identical. Each measurement processes its events as a standalone property, with an internal user_pseudo_id computed within each property’s context. As a result:

• One person moving from the blog to the app is counted as two different users on two different dashboards
• Retention metrics become fake — the system doesn’t know that a “new user” in the app is actually an old user who already interacted on the blog
• Funnels involving more than one subdomain practically can’t be analyzed as one flow, because the data is indeed never merged at any level

Conversion attribution is completely lost. A signup happening in the app can’t be linked to the campaign or traffic channel that brought that user from the blog. For businesses whose growth model is funnel-based — content to signup, SEO to conversion — this isn’t a small shortcoming, but a loss of the ability to measure what actually drives growth.

Over-engineering disguised as tidiness. Many implementations separate measurements just because it feels more “neat” structurally, without considering that prematurely separated analytics data actually makes insights harder to obtain, not easier.

Decision Matrix

Hybrid Implementation: One Measurement + hostname Segmentation

The healthiest approach in many production systems isn’t choosing one extreme, but: one Measurement ID, segmentation done at the reporting level. This approach retains all the advantages of a complete user journey, while still allowing per-subdomain analysis whenever needed.

The implementation uses a built-in GA4 dimension called hostname, which is automatically recorded on every event without any additional configuration — GA4 always records from which domain/subdomain an event was sent.

hostname = blog.example.com
hostname = app.example.com
hostname = example.com

How to use it in practice, via GA4 Explore reports:

1. Create a new exploration in the Explore menu
2. Add the Hostname dimension to the report
3. Use it as a filter (for example hostname starts with app.) to see app data only
4. Remove the filter to see cross-subdomain funnels as a whole

With this one setup, you get full flexibility:

• See blog data only — filter hostname to blog.example.com
• See app data only — filter hostname to app.example.com
• Analyze cross-subdomain funnels — remove the filter, see the entire user journey from the blog to conversion in the app, something completely impossible if measurements were separated from the start

For segmentation needs more specific than just hostname — for example distinguishing certain blog sections or app versions — add an event-scoped custom dimension in GTM or directly via gtag, then register it as a custom dimension in GA4. The principle stays the same: one measurement ID, additional details captured via dimensions, not by splitting measurements.

Anti-Patterns to Avoid

✗ Separating measurements because "it looks neater" -- without a concrete technical reason
✓ Keep one measurement, use hostname/custom dimensions for segmentation

✗ Separating measurements without first mapping the cross-subdomain user journey
✓ Map it first: is there a realistic funnel passing through these subdomains? Then decide

✗ Sacrificing funnel integrity for data isolation that "looks" cleaner
✓ Data isolation can be achieved via report filters, without sacrificing funnel analysis capability

Once measurements have been separated and running for a while, migrating to one measurement can’t merge historical data that’s already split. This decision should ideally be made at implementation time, not fixed later after production data has piled up on both sides.

Good analytics isn’t about the neatness of the configuration structure, but about the correctness of the insights that can be generated from that data.

Trade-off Summary Table

Summary

• A GA4 Property can hold many Data Streams, and each Measurement ID represents one stream — the one vs separate decision is actually about how many web data streams to create.
• The _ga cookie is scoped to the main domain so it can be read across subdomains, but a user journey is only truly complete if those events are also sent to the same Measurement ID.
• One measurement keeps the user journey, sessions, and conversion attribution intact across subdomains — crucial for content-to-signup or SEO-to-conversion funnels.
• Separate measurements suit truly independent products (admin tools, client dashboards), but split users/sessions architecturally, not just in reporting.
• Mixed data in one measurement is a reporting problem fully solvable with GA4’s built-in hostname dimension, without needing to split measurements.
• Migrating from separate measurements to one measurement can’t merge historical data that’s already split — decide this strategy at implementation time.
• A simple decision matrix: separate measurements only if the products are truly different and there’s no cross-domain funnel; otherwise, one measurement with report segmentation is the healthiest choice.