The GA4 custom dimensions checker

This is the most common invisible failure in GA4 implementations, and it produces no warning anywhere in either product. Your GTM tag sends plan_type with every event. GA4 receives it. GA4 accepts it. And then, unless someone registered plan_type as a custom dimension, GA4 discards it for reporting purposes.

Nothing errors. The tag reports success, the hit shows a 200 response, the parameter is right there in the payload if you decode it. It simply never appears in any report, exploration, or audience — and the person who asked for that segmentation is told it is not available, months after it was implemented.

Why GA4 works this way

GA4 has a fixed budget of custom dimensions per property — 50 event-scoped and 25 user-scoped on the standard tier. Registration is how you spend that budget. Google will not auto-register every parameter it receives, because you would exhaust the allocation within a week of any real implementation.

The consequence is that collection and reporting are two separate decisions, usually made by two different people at two different times. The developer or tag manager decides what to send. Somebody in the GA4 interface decides what to keep. When those two steps are not reconciled, you get exactly this gap.

One more thing worth knowing: registering a dimension is not retroactive. Data collected before registration is gone for reporting, permanently. The cost of this gap is measured in however many months it went unnoticed.

The two directions of drift

Sent but not registered

The expensive direction. You are collecting data, paying the implementation cost, and getting nothing back. Every day it continues is another day of history you cannot recover. Fix by registering the dimension in GA4 — Admin, then Custom definitions — using the exact parameter name.

Registered but never populated

The wasteful direction. A dimension exists, occupies one of your 50 slots, and shows (not set) in every report. Usually it was registered ahead of an implementation that never shipped, or a parameter was renamed on the GTM side and nobody updated GA4. Fix by archiving it or correcting the name mismatch.

The five mismatches this catches most

1. 01

   A typo or case difference

   GA4 parameter matching is exact. plan_Type and plan_type are two different parameters, and the registered one will simply never fill. This accounts for a surprising share of "the dimension does not work" tickets.

2. 02

   A parameter renamed in GTM after registration

   A developer standardises the taxonomy from userType to user_type. GTM ships. GA4 still has userType registered, which now goes empty, while user_type is discarded. Both gap lists light up on the same underlying change.

3. 03

   Parameters added without anyone telling the analyst

   A new tag ships with three new parameters. Nobody registers them, because nobody outside the tagging work knew they existed. This is the default outcome without a periodic diff.

4. 04

   Hitting the 50-dimension ceiling

   Once you are at the limit, every new parameter is silently discarded no matter what you do. The checker shows remaining slots, which turns "why can I not add this?" into a capacity decision about which unused dimensions to archive.

5. 05

   Scope confusion

   A property-wide attribute like account tier registered as event-scoped, or a per-event attribute registered as user-scoped. Both technically work and both produce reports that are subtly wrong in ways that take a long time to notice.

Where this fits in an audit

The GA4 audit checks the property. The GTM audit checks the container. Both can pass cleanly while this gap is wide open, because neither one on its own can see both sides at once. Reconciling the two is a separate step, and it is the one most audit checklists never get to.