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.
What this means
A user property describes the user, not the action: subscription_tier, ui_language, account_type. It applies to all subsequent events from that user, so you can segment any report by it. An event parameter, by contrast, describes a single event (which CTA, which product). Choosing the right scope keeps both clean.
Scope, limits, and the hard line
Use a user property when the attribute is durable across events and useful for audience segmentation; use a parameter when it is specific to one action. GA4 caps the number of user properties you can register, so spend them on stable, valuable dimensions. The hard line is identity: Google's policy forbids sending personally identifiable information, and precise or special-category data has no place in a user property.
- User property = describes the user across events
- Parameter = describes a single event
- No PII, precise location, or special-category data
How it appears in analytics and logs
A user property that changes per event was probably meant to be a parameter. A user property that looks like an identifier is a privacy problem and likely against platform policy.
Diagnostic use case
Segment behaviour by durable audience attributes (plan, locale) using user properties, while keeping event-specific context in parameters and identity out of both.
What WebmasterID can help detect
WebmasterID keeps segmentation to coarse, non-identifying attributes, so audience analysis never depends on storing personal data against a visitor.
Common mistakes
- Using a user property for something that varies per event.
- Storing an email or user id as a user property.
- Burning the user-property budget on low-value attributes.
Privacy and accuracy notes
User properties persist against a user and are especially sensitive — never store names, emails, precise location, or special-category data. Platform policies prohibit personally identifiable information here. This is educational, not legal advice.
Related pages
- 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.
- 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.
- GDPR and web analytics: the practical picture
The GDPR governs processing of personal data of people in the EU. For analytics that means: identifiers and IP addresses can be personal data, consent is often required for cookie-based tracking, and minimisation matters. Cookieless, first-party, anonymised measurement reduces the surface — but this is a factual overview, not legal advice.
- Privacy-first analytics
Segment by coarse attributes, never identity.
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.