GA4 Subproperties and Roll-up Properties: Structuring Brands and Regions

GA4 structure questions tend to arrive at a bad moment. A client buys a second brand, or a regional team asks for its own numbers, and the property already holds a year of history that nobody wants to lose. Three options are on the table, and they are not interchangeable. You can create a separate property and start its history today. You can create a subproperty. You can create a roll-up property.

Two of the three are Google Analytics 360 features, so the first question in the meeting is not which one matches the client's reporting wish. It is which licence the client holds. Google's documentation is direct about it: subproperties and roll-up properties are available only to GA4 360 accounts linked to a Google Marketing Platform organisation with an active 360 order, and only a 360 property can be the source for either. On standard GA4 the design collapses to separate properties plus a reporting layer outside Analytics. Say that before anyone draws an org chart, because it saves a week of work on something that cannot be built.

What a subproperty actually is

A subproperty takes its data from another property, called the source property. Everything else about it is an ordinary property. You add users, mark key events, create audiences, delete data and link Google Ads from the subproperty, and those settings belong to the subproperty rather than the source.

The filter is what makes it a subproperty. Events arrive from the source, and an event-level filter decides which of them land. The filter supports AND and OR logic over predefined dimensions and the event-level custom dimensions the client has already created, so a region view, a product view or a signed-in-user view is a configuration task rather than a second implementation.

The data in a subproperty is usually a subset of the source, but the documentation is careful not to promise that, and the caveat matters when someone reconciles the two views. Google maintains its own list of reasons source and subproperty totals differ, and two of them sit in the first_visit and first_open events, where Analytics decides independently whether to include them in two circumstances regardless of the filter you set.

Attribution is calculated separately for every property in the structure. You can leave data-driven attribution on the source and a rules-based model on a subproperty, and the two will never agree on credit. Google copies event data to the subproperty before modelling and trains each model on its own property, with no dependency in either direction. When a client asks why a channel looks stronger in the regional view than in the group view, that is the first place to look, before anyone starts re-checking tags.

The cost line that never makes the kick-off notes

Subproperties and roll-ups both carry data charges on a 360 contract. Events in a subproperty cost one half of the cost of the events in the source property, and you are not charged for source events that the subproperty's filter removes. A roll-up is billed the same way against each source, one half of the source cost, which is the same as saying that two events in the roll-up cost what one event in the source costs.

Run that arithmetic before the design is agreed. A brand with four regional subproperties and a roll-up on top is asking the client to pay for the same sessions several times over. That can be a fair price for the reporting the group needs, but it should be a decision taken in a meeting, not a surprise found on an invoice in month three.

The ceilings that shape the design

Four limits decide what is buildable, and they are worth writing into the proposal:

• Up to 400 subproperties per source property, and subproperties count toward the account's 2,000 property limit.
• A subproperty holds no events of its own. It cannot add or delete data streams, import offline events, or create and modify events through the interface. Audience triggers are the exception, because events they generate are processed separately from client-side collection.
• A source property and its subproperties together can hold 400 unique links to Google Ads accounts. Past that, Analytics deactivates the most recently added links until it is back under the ceiling.
• A subproperty cannot be moved between accounts, and a source property cannot be moved until all of its subproperties are deleted: moved to Trash, then 35 days for permanent deletion. Subproperties exist only as 360 entities, so there is no downgrade path, and the source cannot be downgraded to Standard until they are gone.

Custom dimensions and the sync switch

Custom dimensions and metrics are configured per property. Subproperties have an opt-in sync to the source: once synced, a subproperty uses the dimensions and metrics defined in the source and cannot edit, remove or create its own, and later updates in the source flow through automatically. The first sync can take up to 48 hours and the status appears in the source property under Admin, then Subproperty management. Left unsynced, the subproperty keeps its own copy and stays editable, which is the option to use when one region genuinely needs a field the group does not.

The trade-off is the one that runs through all of 360: syncing removes maintenance work and removes control. Take the decision per subproperty and write down the reason, because the next person to touch the account will otherwise assume the default was deliberate.

What a roll-up property is for

A roll-up combines several source properties into a single view across products, brands or regions. It does not collect data. In an account list, roll-ups carry a Rollup label and their sources appear indented underneath.

Four restrictions decide whether the client can have one at all:

• A maximum of 200 source properties.
• A roll-up cannot be a source for another roll-up.
• A roll-up cannot take both a subproperty and that subproperty's source property as sources. It is one or the other.
• You cannot create subproperties from a roll-up.

Access does not inherit in either direction. Roll-ups do not take users from their sources, users on a source property gain nothing on the roll-up, and nobody inherits permissions from a roll-up back down. Every grant is deliberate.

Custom dimensions and metrics are not inherited either, so they get recreated. Report collections from the sources are not imported, and marking an event as a key event in the roll-up does not mark it in the property it came from.

Data starts accumulating from the date each source property is added, so a roll-up built in October has no September. Disconnect a source and its history stays in the roll-up. Once data lands, it is subject to the roll-up's own settings, which include reporting identity and attribution settings, so the same events can be counted and credited differently in the roll-up than in the property that collected them. Admin settings on one side never reach the other.

Deduplication is the rule that surprises finance teams. A roll-up counts a user once when the same reporting identity appears across multiple source properties, for example the same user ID or the same signed-in Google account, so user metrics and anything calculated from them drop accordingly. That deduplication depends on the sources being set up properly. If two domains are measured with two data streams and cross-domain measurement is not configured, the user is counted once in each stream and the roll-up total lands above what anyone expected. Cross-domain measurement works inside a single data stream.

Product links on a roll-up

A roll-up needs its own link to export anything. Marking key events and expecting them in Google Ads does nothing until the roll-up itself is linked to the Ads account.

One wrinkle is worth knowing before a client asks why a setting appears to have spread. If a roll-up has no link of its own but several source properties are linked to the same account with different configurations, Analytics applies the most permissive of those configurations to the combined data. Auto-tagging enabled on one source link is enough to turn it on across the roll-up, and cost data from every linked source is imported.

Roll-ups can currently link to Google Ads, BigQuery, Campaign Manager 360, Display & Video 360 and Search Ads 360. Firebase has to be linked to an ordinary property. For Search Console, Google recommends linking the data stream in the source property rather than the inherited stream in the roll-up.

Access, deletion and the audit trail

Property structure is an access-control decision as much as a reporting one, and inheritance runs in directions people do not expect. Removing a user from a source property also removes them from its subproperties, while removing a user from a subproperty only affects that subproperty. Roll-ups sit entirely outside that chain.

Deletion follows a one-way cascade. Data deleted from a source property is also deleted from its subproperties and from any roll-up that draws on it. Data deleted from a subproperty is deleted there and nowhere else, and the same applies to a roll-up. If a client receives an erasure request that covers one region, the property you delete in decides what actually goes.

Retention is a property-level control, so treat it as part of the design review rather than a setting somebody left at the default. Change history splits the same way: a change to a source property that affects a subproperty is also recorded in that subproperty's change history, which is what makes a post-incident review possible when the fault was made upstairs.

Choosing between the three

• Separate properties: no 360 requirement, the cleanest access boundary, no shared history, and a new measurement clock. Right when brands have separate teams, separate consent banners or separate legal entities.
• Subproperties: 360 only, shared collection, a filtered view, separate settings and separate user lists. Right when one brand needs regional or product views of the same traffic.
• Roll-ups: 360 only, read-only aggregation, deduplication across sources. Right when the group needs one number without changing how the parts are measured.

Resist building property structure around a report that a comparison, an exploration or an audience would cover. Those cost nothing extra, they can be changed next week, and they do not add a property that has to be fed, secured and reviewed for years.

A pre-flight list before you create anything

• Confirm the licence. No active 360 order means no subproperties and no roll-ups.
• Write the filter conditions for every subproperty down before creating them, and keep the list with the account documentation.
• Check the 400-link and 400-subproperty ceilings against the number of Ads accounts the client actually holds.
• Decide synced or unsynced per subproperty, and record the reason.
• Confirm the roll-up's own product links, or the export will silently not happen.
• Check reporting identity and attribution settings on every property in the structure. They apply per property, not per account.
• Check retention on every property you create.
• Verify cross-domain measurement before promising deduplicated roll-up totals.

None of this is complicated once it is written down. The difficulty is that the decisions arrive one at a time, usually mid-review, and the account ends up with whichever answer was fastest that afternoon. A structure chosen on purpose is easier to explain to a client, cheaper to run, and survives the person who built it.