GA4 custom dimensions: event vs user scope, and the limits that bite
Scope is permanent, archiving can't be undone, and registration controls reporting, not collection. Pick event scope unless the value describes the person.
Short answer: choose event scope unless the value genuinely describes the person rather than the action, because the scope field is permanent — "You can't change this field after you save the new dimension" (Analytics Help, checked 10 August 2026), and the only way out is archiving, which "can't be undone". A standard property gets 50 event-scoped custom dimensions, 25 user-scoped and 10 item-scoped. Treat those slots as a budget you spend once. And know what registration is doing: it makes a parameter available to report on, it doesn't switch collection on, so a wrong choice costs you a reporting slot rather than the data itself.
Scope is the one field you can't take back
Most GA4 settings forgive a wrong guess. This one doesn't.
When you create a custom dimension you set a name, a scope and the parameter it reads from. Google's instructions attach the same warning to both the scope and the event parameter field: "You can't change this field after you save the new dimension" (Analytics Help, checked 10 August 2026). There is no edit. If you registered plan_type as user-scoped and needed it per event, that definition is what it is.
The escape hatch is archiving, and it's a one-way door too. Archiving frees a slot — "you can free up space to create more custom dimensions or metrics by archiving the ones you don't use" — but "archiving dimensions or metrics can't be undone and the corresponding dimensions or metrics can't be restored" (Analytics Help, checked 10 August 2026). You can reuse the name afterwards. You don't get the definition back.
Archiving is also not free elsewhere. Anything built on that dimension breaks: reports become "invalid until you remove the archived custom dimension or metric from the reports", explorations and segments using it "are invalid and will not load", and audiences go stale — historical data survives, but the audience stops accumulating new users. So the cost of an irreversible bad choice isn't just a wasted slot; it's every saved exploration somebody on your team built on top of it.
Event, user and item scope answer different questions
The choice is easier than it looks once you ask what the value is attached to.
Event scope reports on "custom event parameters, which measure details about user actions" (Analytics Help, checked 10 August 2026). The value belongs to the thing that happened — which form was submitted, which filter was applied, which video finished. If the same person could produce two different values in one session, it is event-scoped. This is the right answer far more often than people expect.
User scope reports on "custom user properties". The value describes the person and persists across their events until you change it — account tier, customer versus prospect, logged-in status. GA4 applies the most recently received value, so a user-scoped dimension rewrites how that person's whole history is reported, not just what happened after the change. That is exactly what you want for "which tier is this customer on" and exactly what you don't want for "which tier did they buy".
Item scope covers "custom data like item color or item size within the items array of an ecommerce event". It only applies inside ecommerce items, and it only works if you're populating the items array properly in the first place.
The failure mode worth naming: registering something as user-scoped because it feels like it describes the customer, when what you actually want to analyse is the moment. Traffic source, campaign, device, first purchase — those describe an event. Put them on the user and you lose the ability to ask when the value was true.
The limits are per property, and 360 doesn't remove them
| Type | Standard property | Analytics 360 |
|---|---|---|
| Event-scoped custom dimensions | 50 | 125 |
| User-scoped custom dimensions | 25 | 100 |
| Item-scoped custom dimensions | 10 | 25 |
| Custom metrics | 50 | 125 |
Those are Google's stated registration limits (Analytics Help, checked 10 August 2026). Two things about them are worth planning around.
The user-scoped allowance is the tight one. Twenty-five is not many for a business that wants to slice by account tier, lifecycle stage, subscription status, acquisition cohort, region, consent state and whatever product management asks for next quarter. And because scope is permanent and archiving is irreversible, every user-scoped dimension created on a hunch is a slot that is genuinely hard to get back.
Item scope is tighter still at ten, which is the one that catches ecommerce teams mid-project. Decide those ten before you write the schema, not after.
Registration controls reporting, not collection
This is the part that changes how you should think about the limits, and it's rarely stated plainly.
Registering a custom dimension does not turn collection on. The parameter is already arriving with the event; registration is what makes it available as a dimension in the reporting interface. Google's BigQuery export schema describes event_params as a record that "can store campaign-level and contextual event parameters as well as any user-defined event parameters", repeated "for each key that is associated with an event", with the set of parameters "unique to each implementation" (Analytics Help, checked 10 August 2026). Nothing on that page ties the export to your custom-definition registrations.
The practical read: if you have the BigQuery export running, hitting the 50-slot ceiling is a constraint on what you can put in a standard report, not a wall in front of the data. A parameter you never registered is still in the export and still queryable. Verify that against your own export before you rely on it — check whether the key is present in event_params for the events you care about — but it reframes the decision. You are rationing report slots, not measurement.
It also means the reverse is true. Registering a dimension does not fix a parameter you aren't sending. If the value isn't on the event, no amount of custom-definition configuration will produce it.
A custom dimension is still sent when analytics storage is denied
Worth knowing before you decide what goes in one.
With analytics_storage set to denied, the Google tag will "not read or write first-party analytics cookies" and sends cookieless pings instead. But the same page is explicit about what still travels: "If an advertiser sets other fields, such as user_id and custom dimensions, they will be sent normally" (Analytics Help, checked 10 August 2026).
So consent denial removes the persistent identifier. It does not act as a filter on the payload you built. Anything you put into a custom dimension or a user property goes to Google whether or not the visitor accepted analytics storage, unless you have written your own logic to stop sending it. If a dimension carries an email address, a customer reference, a postcode or anything else that identifies a person, "we have a consent banner" is not the control you thought it was — and Google's own guidance elsewhere is that you shouldn't register a user ID as a custom dimension in the first place.
The fix is upstream of GA4: decide what the dataLayer publishes at each consent state, rather than assuming the tag suppresses it for you.
Custom dimensions ride on the same tag whose consent state decides what Google is allowed to do with everything else it receives. The Consent Mode checker loads your site and reports what consent signals your tag actually sends — the default state before anyone clicks, and whether the update fires at all — which is what determines whether a denied visitor is being handled the way you think.
Give it 24 hours before you call it broken
Two different waiting periods get muddled together, and the difference matters when you're debugging.
For (not set) specifically, Google says: "For an event with custom parameters, you may notice (not set) as a parameter value during the first 24 hours after you register a custom parameter" (Analytics Help, checked 10 August 2026). After that window, expect real values.
Separately, on when the dimension becomes usable in reporting, Google's instructions say you "can add the custom dimension to any report after 24-48 hours from when the custom data was sent and the custom dimension was created" (Analytics Help, checked 10 August 2026). Note the wording — it counts from both events, the data being sent and the definition existing.
We went looking for a Google page that states whether registration backfills data collected before the dimension existed. We didn't find one that says so either way, so don't assume it does; the safest reading of "from when the custom data was sent and the custom dimension was created" is that both need to have happened. If you need history, the raw export is the place to get it.
And (not set) after the window has passed means something else entirely. It "is a placeholder name that Analytics uses when it hasn't received any information for a dimension" — so at that point you have a collection problem, not a patience problem. Check the parameter name matches exactly, including case, and check the event is actually carrying it.
What to do before you create the next one
Write down the parameter, the question it answers, and whether the value belongs to the person or to the moment. If it could differ twice in one session, it's event-scoped. If you're unsure, event scope is the cheaper mistake — you have 50 of those slots and 25 of the other, and neither choice can be edited later.
Then check what the dimension will carry. A field that identifies a person is still transmitted when a visitor has refused analytics storage, so the decision about what goes into the payload belongs in your tagging layer and your consent logic, not in the custom definitions screen. Making sure the data you collect matches what you're actually allowed to collect is the work we do.
Sources
- 1.Analytics Help — [GA4] Create event-scoped custom dimensions (the field you can't change) · Checked 2026-08-10
- 2.Analytics Help — [GA4] About custom dimensions and metrics (scopes and registration limits) · Checked 2026-08-10
- 3.Analytics Help — [GA4] Archive custom dimensions and metrics · Checked 2026-08-10
- 4.Analytics Help — [GA4] What the value (not set) means in your reports · Checked 2026-08-10
- 5.Analytics Help — Consent mode behaviour when analytics_storage is denied · Checked 2026-08-10
- 6.Analytics Help — [GA4] BigQuery Export schema (event_params) · Checked 2026-08-10