Why GA4 Shows '(not set)'
If you’re seeing (not set) as a value in GA4 reports or Explorations, here are the most common causes and how to fix them. (not set) is not a single bug — it’s GA4’s umbrella placeholder for “this dimension had no value for this row.” Each of the causes below requires a different fix.
1. Custom dimension not registered (or registered after the fact)
Section titled “1. Custom dimension not registered (or registered after the fact)”Verify. GA4 → Admin → Custom definitions. Find the dimension. Check:
- The event parameter name exactly matches what you’re sending (case sensitive).
- The scope is correct (Event vs. User vs. Item).
- The creation date — dimensions apply only to events collected after registration. Historical events show
(not set)forever.
Fix. Register missing dimensions. Correct scope if wrong. Understand that backfilling is impossible — the parameter was sent, GA4 stored it in the raw event, but the dimension wasn’t mapped at ingest time. Re-registering today fixes future events, never past ones.
2. Event genuinely missing the parameter on some hits
Section titled “2. Event genuinely missing the parameter on some hits”Verify. In BigQuery: SELECT event_name, COUNT(*) FROM ... WHERE (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'your_param') IS NULL GROUP BY event_name. If some events have it and others don’t, your tag isn’t consistently setting the parameter.
Fix. Audit the GTM tag. A common pattern: the parameter is mapped from a Data Layer Variable that only exists on certain pages. On pages where the push didn’t run, the variable is undefined and GA4 stores the event without the parameter, so reports show (not set) for those rows.
3. Processing lag — registered after the event was collected
Section titled “3. Processing lag — registered after the event was collected”Verify. You registered a custom dimension yesterday. Today’s events show the value. Yesterday’s and earlier events show (not set) even though the parameter was in the payload. This is working as designed: GA4 maps dimensions at ingest.
Fix. No retroactive fix in the UI. If you need the historical data, it’s in BigQuery as event_params raw data — query it directly. If you don’t have BigQuery export, enable it now for the next occurrence (it can’t backfill either, so enable it before you need it).
4. Cardinality limit — too many unique values
Section titled “4. Cardinality limit — too many unique values”Verify. GA4 enforces a per-day cardinality limit (typically 500-1000 unique values per dimension per day, varies). When exceeded, low-frequency values are bucketed into (other) in standard reports and (not set) appears when the bucket overflows. Most common on dimensions like page_location (with query strings), search_term, or any high-cardinality user-scoped ID.
Fix. Reduce cardinality at source. Strip query strings from page paths. Bucket search terms by category. For user IDs, don’t send the raw ID as an event parameter — use GA4’s User-ID feature instead. If you truly need full cardinality, use BigQuery export — the raw table has no cardinality cap.
5. Parameter unavailable on the event type
Section titled “5. Parameter unavailable on the event type”Verify. Some dimensions only populate for certain event types. page_location on a file_download event may be (not set) if Enhanced Measurement captures the download before a page_view established the context. Session-scoped dimensions are (not set) for events before session_start.
Fix. Either accept the limitation, or route around it. For page_location on events that fire pre-pageview, either fire the Google Tag earlier (Initialization trigger, not Page View trigger) or add an explicit page_location = {{Page URL}} parameter to the event tag so it’s set directly.