Parameters sent, never registered

Symptom and cause

Symptom

A parameter DebugView shows on the event is missing from the report picker, or reads "(not set)" on every row. It is being sent; the report just can't see it.

Cause

Event parameters pushed faithfully into the dataLayer and collected by GA4, but never registered as custom dimensions or metrics in admin, or registered under a name the tag doesn't send. Collected, stored, invisible.

Where it's caught

DebugView showing the parameter on the event while reports can't offer it or show (not set); a custom-definitions list far shorter than the measurement plan.

Why GA4 collects a parameter and never reports it

GA4 splits collection from reporting. Your tag can send up to 25 parameters per event, and GA4 stores them all. DebugView, GA4's live view of your own test visits, lists every parameter on the hit. Reports work differently: a custom parameter only becomes something you can pick in a report once someone registers it as a custom dimension (text) or custom metric (a number), against the exact name the tag sends. Nothing in GTM or DebugView warns you that this step was skipped.

What you see depends on how the registration went wrong.

Never registered. The parameter is collected and invisible. It is not in the dimension list of any standard report or exploration, so most people assume it was never sent. DebugView says otherwise.

Registered against the wrong name. A custom dimension exists, but its event parameter field says deliveryOption while the tag sends delivery_option. GA4 looks for a parameter that never arrives, so the dimension reads (not set) on every row. The exhibit below is this case on record. The event parameter field cannot be edited after saving, so the fix is a new dimension, not an edit.

Wrong scope. Scope is whether GA4 reads a value per event, per product or per customer, and it is fixed at creation too. A product detail such as colour travels inside the items array (the product list inside a purchase or add_to_cart event) and needs an item-scoped dimension, which cannot be added to standard reports, only to explorations. Sent at event level instead, it can only ever report per event, never per product. A detail about the customer, such as a loyalty tier, is a user property and needs a user-scoped dimension.

Out of slots. A standard property has 50 event-scoped, 25 user-scoped and 10 item-scoped custom dimensions, and 50 custom metrics. Once they are used up, the rest of the measurement plan stays unregistered and nothing flags it.

Two things look like this fault and are not. A newly registered parameter can read (not set) for the first 24 hours, and the dimension becomes usable 24 to 48 hours after it was created. And a dimension reads (not set) on events that never carry the parameter: a purchase-only parameter is (not set) on page_view rows, which is correct. F-601 is the parameter present on the hit and still missing, or still (not set), on that same event a few days later.

Google does not document a backfill for events collected before the dimension existed, so plan as if reporting starts on the registration date. If the GA4 BigQuery export was on, the raw events hold each custom parameter as a key and value in event_params, and the earlier history can be read there.

In the hit (DebugView)	Custom definition	Report reads	Verdict
customer_type	customer_type · Event	new, returning	registered
delivery_option	deliveryOption · Event	(not set) on every purchase	wrong name
discount_source	none	not in the picker	never registered
Measurement plan	9 of 14 registered	5 parameters unseen	gap on file

sent as delivery_option, registered as deliveryOption

How to catch it

1. (Anyone with GA4 access, no tools) Open Admin → Data display → Custom definitions and count the custom dimensions and metrics. Put that next to the list of parameters your developer or agency says the site sends. Fewer rows than reporting parameters is this fault, before you open anything else.
2. (Whoever owns GTM) Prove the parameter is sent. Open the site through Tag Assistant or GTM Preview, which turns debug mode on, then go to Admin → Data display → DebugView, trigger the event and click it. Write down each custom parameter name exactly as shown. Not in the hit at all is a collection problem, a timing race (F-103) or item data never built (F-301), not this code.
3. Match the two lists. For each parameter from DebugView, find a custom dimension whose event parameter field is the same name, character for character. No row means never registered. A row with a near miss (deliveryOption against delivery_option) means registered against the wrong name.
4. Check the scope on each row. Product details must be Item scope and sit inside the items array in DebugView, not beside it. Customer details must be User scope and be sent as user properties.
5. Check the date. A dimension created less than 48 hours ago has not had its full time yet. Then set the report range to start after the creation date, since Google does not document earlier data appearing.
6. Check that (not set) is not just rows without the parameter. Add event name as a second dimension. (not set) only on events that never send it is correct. (not set) on the very event DebugView shows carrying it is F-601. On the Custom definitions page, Quota information also shows whether the property ran out of slots.

What putting it right involves

1. (GA4 Editor or above) Register each reporting parameter. Admin → Data display → Custom definitions → Create custom dimensions: a readable name, the right scope, and the event parameter typed exactly as the tag sends it. Numbers you want to add up, such as a discount amount, go in as custom metrics instead.
2. (GA4 Editor or above) Replace, don't edit, a wrong registration. Scope and event parameter are fixed once saved. Create the correct dimension, then archive the wrong one. Archiving cannot be undone. Explorations and reports that use the old dimension stop loading until it is removed from them. An audience that uses it stops collecting users for good and has to be rebuilt, so check audiences first.
3. (Whoever owns GTM) Fix the sending side where names drifted. One spelling per parameter, in every tag and in the dataLayer. Names up to 40 characters, values up to 100. Product details inside the items array, customer details as user properties.
4. (GA4 Editor or above) Make room on purpose if the quota is full. Archive dimensions nobody reads, then allow 48 hours before the freed slot can be used. Do not register a parameter that already has a predefined dimension, such as page or transaction ID: it uses a slot for nothing. Leave out values that differ on almost every hit, such as order ids and timestamps, which end up folded into (other) (R-502).
5. (Anyone with report access) Verify after 48 hours. Build a free-form exploration with the new dimension and event name. The values from DebugView should be there on that event, with (not set) only on events that never send it. Item-scoped dimensions are checked in explorations, not standard reports.
6. (Whoever owns the measurement plan) Record each registration: parameter, scope, dimension name and the date it went live, so nobody compares a month that predates it (F-501). If that history matters, read it from the BigQuery export, not the reports.