GA4 Custom Dimensions and Metrics: What to Register and What to Leave Alone

A client asks for a report split by delivery method, or by plan tier, or by which version of a form a lead used. The data layer has been pushing that parameter for months. The report has no such field, and the standard report rows look empty where the parameter should sit. Nothing is broken. GA4 collected the parameter and never exposed it as something you can group by.

Registration is the step that turns a parameter into a reportable dimension. Standard reports only carry the dimensions Google ships with the product. Your custom parameter lives in the raw data, usable in BigQuery and in audiences, but invisible to the reporting interface until you bind it to a custom dimension or metric. That bind is a small form with three decisions in it, and one of those decisions cannot be undone.

The parameter is not the dimension

GA4 splits data collection into two layers. Events record what people do, and event parameters carry the detail: which link was clicked, how far a video played, which payment method was chosen. User properties describe the person. All of it is collected whether or not you ever register a definition.

What registration buys you is reporting. Once a parameter is bound to a custom dimension, it becomes available in standard reports, in free-form explorations, and as a condition when you build an audience. Google's own wording is that the dimension lets you analyze and advertise using the custom data you gathered. Without it, the parameter sits in the export and nowhere else.

Three scopes, and the decision you cannot undo

Every custom dimension declares a scope, and the scope decides which data it can read. Event-scoped dimensions read event parameters, so they suit details about an action: delivery option, payment type, form name, filter applied. User-scoped dimensions read user properties, so they suit stable facts about the person: plan tier, login status, account type. Item-scoped dimensions read the items array inside an ecommerce event, which is where item colour, size, or a supplier code belongs.

The scope and the underlying parameter name are locked the moment you save. Register a parameter as event-scoped and later discover you need it at user level, and the answer is to delete the definition and start again. Pick the scope against the report you intend to build, not against whichever dropdown sits closest to the cursor.

Two smaller traps sit in the same form. Dimension names cannot contain hyphens, so a name that would normally carry one needs a space instead. And the event parameter field has to match the parameter name in your tag exactly, including case, because a near miss produces a definition that never receives anything.

The quota is smaller than most teams assume

A standard property allows 25 user-scoped custom dimensions, 50 event-scoped custom dimensions, 10 item-scoped custom dimensions, 50 custom metrics, and 5 calculated metrics. A 360 property raises those to 100, 125, 25, 125, and 50. The Custom definitions page in Admin shows how many you have created, and a Quota information button in the top right gives the running count.

Deleting a definition does not free its slot straight away. Once you hit a limit you have to wait 48 hours after deleting before new definitions can be added, which turns a tidy-up into a two-day delay if you leave it late.

Two related ceilings tend to bite before the dimension quota does. A standard property takes 25 event parameters per event, or 100 on 360, which is why a single reusable parameter usually beats a new one for every form. And parameter values are capped at 100 characters, with longer allowances only for the page fields: 300 for page_title, 420 for page_referrer, and 1,000 for page_location. A value past the cap is truncated, so a long reference number can arrive as a partial string.

Registration is not instant

After you save a definition, Google says to allow 24 to 48 hours before the dimension reports. You also need Editor or above at property level to create one at all. A definition registered an hour before a client review will show nothing in that review, and the honest thing to say is that the field is coming, not that the tracking is broken.

Cardinality is what actually breaks reports

Google classifies a dimension with more than 500 unique values in a single day as high-cardinality. That is a description, not a hard limit, and it is the number worth watching when you decide whether a field deserves a slot. High-cardinality dimensions multiply the number of rows in every table that carries them, and when a table passes its own row limit Analytics keeps the most common values and folds the remainder into the (other) row. The Pages and screens report is a useful illustration: if its table limit is 100,000 rows and a property has 150,000 unique pages, the least common 50,000 pages are grouped into (other).

GA4 also caps a dimension at 50,000 values, after which cardinality control applies. In practice the (other) row shows up long before that, and it shows up fastest in reports that combine several dimensions, apply filters, or use comparisons, because those need tables with more columns.

The dimensions that cause this are easy to recognise. A unique identifier per user, a session ID, a raw timestamp, a free-text search term, an order reference, or a full URL with its query string still attached. None of them group anything useful, because every row is its own value. Google is direct about the worst case: do not build a custom dimension for a per-user identifier, use the User-ID feature instead, and do not do it for session-level IDs either.

One more habit worth dropping. Registering a parameter that already exists as a predefined dimension, such as a page or screen field or a transaction ID, does not improve cardinality and still spends a slot. Equally, if you find several definitions carrying the same parameter against different events, the older custom-parameter reporting has been retired and those duplicates now appear with the event name appended, in the form custom_dimension_name [event_name]. That is a good moment to delete the extras rather than maintain them.

Numbers do not stay text once they reach GA4

Any value in a custom dimension that looks like a number is treated as one, even when you sent it as text. A value of 9343.324234 arrives as 9343.32. A value of 94E40 is read as scientific notation and becomes 9.4e+41. Product codes, order numbers, and reference strings that happen to look numeric can come back rounded or rewritten, so if the exact string matters, keep it alphanumeric or prefix it with a letter. There is a second reason to prefer letters: in app data streams, integer event parameter values are not parsed for event-scoped custom dimensions, while web events do parse them, so an alphanumeric value behaves the same on both.

Custom metrics and calculated metrics

Use a custom metric when the parameter holds a number you want to sum or average, such as a delivery cost, an item weight, or a lead score. Categorical data belongs in a dimension. A calculated metric is different again: it combines metrics you already have into a new one, and a standard property only allows five of them, so reserve those for the ratios you actually report.

What you can leave unregistered

Registration is not compulsory for every consumer. Event parameters and user properties that were never registered are still available in BigQuery, in audiences, and in segments. If the only thing that needs the field is a warehouse query or a remarketing audience, registering it adds nothing and spends quota you may want later. Register when a standard report, an exploration, or an advertising surface needs the field. Otherwise leave the parameter flowing and query it where it lands.

A short routine before you create anything

Confirm the parameter is actually arriving, using the Realtime report or DebugView, because a definition cannot fix a tag that never fires. Check whether a predefined dimension already covers the data. Decide the scope from the report you intend to build, not from where the value happens to sit today. Register once, wait the 24 to 48 hours, then confirm the dimension shows values before you add it to a report someone else will read. Keep a short register of custom definitions with the owner and the reason for each one, so the next person who needs a slot knows what is already taken.

The UK compliance angle

Custom dimensions are a common route for personal data to end up inside Analytics. An email address copied into a form parameter, a full name in a lead source field, an account number used as an order reference. Google's terms prohibit sending personally identifiable information to Analytics, and registering the field makes the problem easier to see without making it any safer. Under UK GDPR the same rules that cover the rest of your measurement apply here, and the ICO guidance on storage and access technologies is the document to read before you add a field that holds anything about an identified person. If the parameter can carry an identifier, it belongs behind consent, and in most cases it belongs out of the property altogether.

When a report will not split the way you need, check the register of custom definitions before you check the tag. Most of the time the parameter is arriving exactly as intended and the dimension was never created.