Event parameters: adding context safely
Event parameters are the key-value details attached to an event: which button, which product, which step. They are what turns a bare event name into something analysable. The craft is choosing a small, stable set of parameters with consistent names and values — and the discipline is keeping every one of them free of personal data, because parameters are stored and widely visible in tooling.
What this means
An event parameter is a key-value pair giving an event context: cta_id, product_category, checkout_step. GA4 distinguishes event-scoped parameters (this event), and supports user properties separately. There are platform limits — for example a cap on the number of parameters per event and on name/value lengths — so a parameter budget matters.
Choosing parameters well
Good parameters are stable, low-cardinality, and consistent: the same key means the same thing everywhere, values come from a known set, and naming follows one convention. High-cardinality or per-visitor values both blow past limits and risk identifying people. The rule that overrides all others: nothing that could identify a person — no names, emails, user ids, or free text — belongs in a parameter.
- Stable keys, consistent low-cardinality values
- Mind GA4 parameter-count and length limits
- Never encode identity or free text
How it appears in analytics and logs
Inconsistent parameter names or values fragment an event across rows. A parameter that varies per visitor (or looks like an identifier) signals a PII or high-cardinality problem.
Diagnostic use case
Attach a small, stable set of contextual parameters to events so reports can segment by them, without encoding any personal data into the values.
What WebmasterID can help detect
WebmasterID favours a small set of semantic, non-PII parameters (such as a CTA id) so events stay analysable and free of identifying data by convention.
Common mistakes
- Using high-cardinality or per-visitor parameter values.
- Inconsistent parameter naming fragmenting one event.
- Encoding personal data into a parameter value.
Privacy and accuracy notes
Parameters are stored and surfaced in reporting and exports — never put names, emails, ids, or free text in them. Keep values low-cardinality and non-identifying. This is educational, not legal advice.
Related pages
- Custom events: tracking what matters to you
Custom events capture meaningful actions a pageview cannot — a CTA click, a signup, a video play, a form submit. The value is in a consistent naming taxonomy and well-chosen properties. The risk is putting personal data into event names or properties, which turns analytics into surveillance. This page covers both.
- User properties vs event parameters
User properties are attributes that describe a user across all their events — a plan tier, a preferred language, a logged-in state — rather than a single action. They differ from event parameters, which describe one event. Used well, user properties let you segment behaviour by audience. Used badly, they become a place where people stash personal data, which is exactly what they must not hold.
- Event naming conventions
An event naming convention is the agreed rule for what events are called: the case, the separators, and the vocabulary. It sounds trivial but it is the difference between clean analytics and a fragmented mess where signup, sign_up, and SignUp count as three things. This page covers the conventions that work, reserved names to avoid, and why a documented taxonomy matters more than any single rule.
- Events reference (docs)
Parameter conventions for WebmasterID events.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.