Custom dimensions in GA4: audit and governance guide

How custom dimensions actually work

In GA4, every interaction is an event, and events carry parameters as key-value pairs. When you send a purchase event with a payment_method parameter, that data is collected and stored. But it is invisible in the GA4 reporting interface until you register payment_method as a custom dimension in Admin > Custom Definitions.

Registration does two things: it makes the dimension available in reports from that point forward, and it locks in the scope. The registration is not retroactive. If you send a parameter for six months and only register it in month seven, you have six months of collected data that will never appear in your standard reports. The data exists in BigQuery, but not in the GA4 interface. Pair this work with a broaderGA4 custom events auditso the events sending these parameters are themselves consistent.

Three scopes and why getting them wrong is costly

Item scope

Item-scoped dimensions are part of the items array in ecommerce events. They describe individual products: item_colour, item_size, item_rating. You get 10 item-scoped custom dimension slots. These are used for product-level reporting and only surface in ecommerce reports.

Conducting a custom dimension audit

Step 1: map current registrations against active usage

Go to Admin > Custom Definitions. Export or document every registered dimension. For each one, note the parameter name, the scope, when it was registered, and the last data it received. You can check recent data in Explorations by adding the dimension and checking if it returns values for the past 30 days. Any dimension with no recent data is either obsolete or broken.

Step 2: check for unregistered parameters that need reporting

Review your GTM container or tracking implementation documentation. List every event parameter being sent to GA4. Compare this list against your registered custom dimensions. Parameters on that list that are not registered are invisible in reports even though the data is being collected. Prioritise registration based on which parameters are needed for active reporting requirements, and cross-reference the broaderGA4 property configuration checksto confirm the property itself is set up to surface them.

Step 3: identify scope mismatches

Any parameter that describes a user attribute but is registered as event-scoped is a scope mismatch. Common examples: logged_in_status, customer_segment, subscription_plan, A/B test variant. These should be user-scoped dimensions set via user properties, not event parameters. Misscoped dimensions mean you lose the context on every event where that property was not explicitly sent, which is one of the leading causes of(not set) values appearing in GA4 reports. Note that you cannot change the scope of a registered custom dimension — you must delete the existing registration and recreate it with the correct scope.

Step 4: check for PII in dimension values

Navigate to an Exploration and add your custom dimensions one by one. Look at the values they are returning. Any dimension that contains email addresses, names, phone numbers, or any other personally identifiable information is a serious compliance issue. GA4's terms of service prohibit sending PII to the platform. Remove these registrations and modify your implementation to exclude the offending parameters.

Step 5: cardinality review

High-cardinality dimensions cause the (other) row problem in GA4 reports. Specific product SKUs, individual page URLs, session IDs, and order IDs are classic examples. In Explorations, high-cardinality dimensions can trigger row limits quickly and make reports unreliable, similar to the issues described inincompatible dimensions and metrics combinations. Consider whether the parameter can be redesigned as a category that is more useful for reporting.

Governance practices to keep custom definitions healthy

• Registration as a change management step: Before any new event parameter enters production, it must go through a review that includes: does a native dimension already cover this, what is the scope, will it ever have high cardinality, does it need to appear in standard reports or is BigQuery sufficient?
• Quarterly cleanup: Audit dimensions that are no longer active or no longer needed. Archive or delete those that are clearly obsolete so quota is available for new reporting requirements.
• Documentation: Maintain a tracking plan that maps every custom dimension to the event that sends it, the expected value range, the business owner, and the date it was registered. This prevents duplicate registrations and scope errors.