(other) is a single row GA4 adds to a report when there are more distinct values than the report is allowed to hold, and it groups everything beyond that limit under one label. The sessions, events and revenue inside it are real; you just cannot see which pages, campaigns or values they belong to.
How (other) works
GA4 does not build every report from raw events each time you open it. To keep reports quick, it stores pre-aggregated tables, and each table has a cap on how many unique rows it can keep for a day. When a dimension produces more unique values than the cap allows, the most common values keep their own rows and the remainder are rolled into (other). Google publishes the current limits in its Analytics help pages, and they are higher for GA4 360 properties than for standard ones.
The cause is nearly always high cardinality: a dimension with a very large number of possible values. The usual offenders are:
- Page URLs that carry unique query strings, such as session tokens, internal search terms, filter combinations or email tracking codes, so every visit seems to create a new page.
- A custom dimension filled with values that are unique to each user or event, like a timestamp, an order reference or a client ID.
- Large catalogues, where thousands of product pages and item names compete for rows in the same report.
- Explorations that combine several detailed dimensions at once, which multiplies the number of possible rows.
Why it matters
A small brochure site will rarely see (other). For a UK online shop with a deep catalogue, a property site with a page per listing, or a publisher with years of articles, it can swallow the very rows you went looking for: the long tail of product pages, the individual listings, the older posts that still bring in steady search traffic. If you are deciding which pages to improve or which campaigns to keep, a report with a large slice in (other) gives you a partial picture that looks complete.
It also starts arguments between tools. A page that earns steady clicks in Search Console may be missing from GA4’s landing page report altogether because its sessions were grouped away, which sends people hunting for a tracking fault that does not exist.
Common mistakes
- Confusing (other) with (not set). One means too many values, the other means a missing value, and the fixes have nothing in common.
- Putting identifiers into custom dimensions just in case they are useful. They add little in the interface and are the quickest way to use up a report’s row allowance.
- Leaving tracking parameters, search terms and filter strings in the page addresses GA4 records, so one page appears as hundreds.
- Expecting a shorter date range to clear the row. In standard reports the cap applies to the underlying daily tables, so a single busy day can still overflow.
- Switching on the BigQuery export only after the problem appears. The export is not backfilled, so the raw data starts from the day you link it.
How to act on it
First, check how big the (other) row is in the reports you actually use. If it is a small share of a report you glance at occasionally, leave it. If it holds a meaningful part of your landing page sessions or revenue, it is worth fixing.
Then cut the number of unique values at source. Strip query parameters you do not need from the page address before it is sent, or record a cleaned page path through Google Tag Manager and report on that. Move per-user and per-event identifiers out of custom dimensions; if you genuinely need them, analyse them in the raw export instead. On catalogue sites, a product category or page type dimension often answers the question faster than the full URL.
For detail you cannot reduce, use the BigQuery export, where every event is stored as its own row and there is no (other) grouping. The export is free to switch on, though BigQuery itself charges for storage and queries beyond its free allowance. Deciding which questions your reports must answer, and shaping the data so they can, is part of the work in a written digital marketing strategy.