GA4 limits that quietly cut a tracking plan

The tracking plan for a GA4 setup usually lives in a spreadsheet: event names, the parameters each event carries, and a short list of values to register as custom dimensions. The spreadsheet accepts anything. Google Analytics does not. A name that is too long, a parameter that collides with a reserved word, or a dimension that holds a different value for every visitor does not raise a visible error on the page. The symptom arrives weeks later, as a report that stays empty or a row labelled (other). This guide lists the published limits and rules that cause that, in the order they tend to bite, and finishes with a procedure that a plan can be put through before any developer starts.

Length limits that cut silently

The collection limits are small and exact. According to the Analytics Help page on collection limits, an event name may be 40 characters, an event parameter name may be 40 characters, and a user property label is capped lower, at 24. One event may carry 25 parameters, and a property may hold 25 user properties. Going past the event name cap also has a stated cost: such a key event is left out of key event reporting.

Two habits push plans over the 40-character line, which the same help page gives as the cap for event names. The first is descriptive naming: names such as a full feature description joined with underscores reach 40 quickly. The second is a shared list of parameters that the plan adds to every event. Ten shared parameters look harmless until each event also has its own fifteen, and the real count per event is what matters, not the count in either list. Count them per event.

The same page gives a limit for parameter values: 100 characters for most values, with larger allowances for page title, referrer and page location. A plan that stores a long free-text value, such as a search phrase or an error message, in an ordinary parameter should expect it to be cut short. This guide did not test what exactly happens to an over-long value, so the safe reading is that the tail cannot be relied on.

Names that break the format

Format rules are separate from length rules. According to the event naming rules, upper and lower case make different events, the first character must be a letter, the rest may be letters, digits or underscores, and spaces are out. Three consequences follow in practice.

A hyphen is not an underscore. A name copied from a page slug, such as one with dashes, breaks the rule even though it reads naturally.
Case creates separate events. A capitalised spelling in one developer's code and a lowercase spelling in another's give two events with split numbers, and neither is wrong as far as the platform is concerned.
A name that starts with a digit fails the letter rule.

None of these is dramatic on its own. Together they are the usual reason a report shows half of what the team expected, because the other half sits under a second spelling.

Reserved names

Some names belong to Google. The reserved names article lists event names that cannot be used for custom events; this guide read the list for web streams only, so check the article for app streams. Several are everyday words that a plan author would pick without thinking: click, error, scroll, page_view, form_submit, file_download and session_start. A custom event named click is the classic case, because it looks like the obvious label for a button press.

Parameters have their own list. The same article names parameters that are off limits for custom dimensions and metrics, among them user_id, session_id, currency, gclid and a handful of identifiers from other Google products. It also says parameter names cannot begin with an underscore, firebase_, ga_, google_ or gtag, as the help page lists them. A plan that calls its user identifier user_id for clarity is therefore not as clear as it looks: the name is reserved, and a dimension cannot be built on it.

One caution from the source itself: the lists are the ones Google published, and a name missing from them is not proof that it is safe. This guide cannot say whether Google will reserve more names later.

Custom dimensions and the (other) row

Collecting a parameter and reporting on it are different steps. A parameter can be broken out in reports only once you have set it up under custom definitions as a dimension, and registration has a ceiling. The custom dimension limits article gives, for a standard property, 25 user-scoped, 50 event-scoped and 10 item-scoped dimensions. It also says that after dimensions are deleted at the limit, a wait of 48 hours applies before new ones can be added, so a plan that wastes slots is expensive to fix on a deadline.

The more subtle cut is cardinality. The same article advises against unnecessary high-cardinality dimensions and says they can hurt reports and explorations, with data condensed under the (other) row. Its examples of what to avoid are a per-user identifier, a per-session identifier and a timestamp, and it points to the User-ID feature for the first. The practical test is to ask how many different values a dimension will hold. A plan type, a page template or a device class holds a handful. An order number, a session id or a time of day to the second holds a new value on nearly every event, and the report fills with (other).

Scope deserves a second look as well. A dimension scoped to the user that takes a different value each visit is both high-cardinality and in a small pool of 25 slots, against 50 for event scope (limits article), so it is the worst combination in the plan.

A check that can fail on purpose

Reading these rules once is easy; applying them to a hundred-row spreadsheet is not. A check that can really fail is one where known-bad entries are put in on purpose and must be found. One procedure:

List every event and count the characters of its name by tool, not by eye. Flag anything over the limit for events.
For each event, add the shared parameters to the event's own parameters and compare the total with the per-event limit.
Compare every event name with the reserved list for the stream type, and every parameter name with the reserved parameter list and the forbidden beginnings.
Check the format: first character a letter, and nothing but letters, digits and underscores after it.
For each dimension, write down how many distinct values it will hold in a month. Anything close to one per event or per visit is a candidate for removal.
Put three deliberately broken rows into a copy of the plan, such as a hyphenated name, a reserved name and a session-id dimension, and confirm that the procedure flags all three. If it does not, the procedure is not measuring anything.

The sixth step matters most. A check that nobody watched go red gives a green result for the wrong reason, and silence from it proves nothing. Consent rules also decide who gets counted at all; whether tracking without cookies still needs a banner is the subject of a separate post, which matters for how many visitors the numbers include.

When this does not apply

Most of the guidance here rests on the published limits for standard properties and web or app streams as read on 28 October 2026. It does not cover the larger allowances of paid properties, server-side tagging, exports to a data warehouse, or data collected by other tools. Google can change any figure, so the three help pages cited here are the place to confirm current values before a plan is finalised. The guide did not run a test property, did not check how each cut shows up in the interface, and did not verify what happens to values over the length allowance. Where it says what usually happens in practice, such as the case-splitting of events and the slot cost of careless dimensions, that is general experience of reviewing plans, not a figure from a source. Finally, a plan that passes every rule can still measure the wrong thing; these checks protect the data path, not the choice of what to count.

Checking a plan before it ships

For a plan that already exists as a table, our ga4-tracking-plan-limits skill takes a single plan and reports breaches only: names that are too long, events carrying too many parameters, reserved names and prefixes, malformed names, and dimensions meant for near-unique values. Each breach becomes a line giving the item, the broken rule and a fix, and a clean plan gets one plain sentence. Page tags and consent are outside what it reads.