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.
What this means
A custom event is any action you choose to record beyond a pageview: cta_click, form_submit, signup, purchase, video_play. Each can carry properties (which CTA, which form) that give the action context.
Naming and safety
Pick one naming convention — lowercase, underscore- or hyphen-separated — and document the allowed event names so different people produce the same ones. Keep properties generic and non-identifying: a CTA id, not a user id. Anything that could identify a person does not belong in an event.
- One naming taxonomy, documented
- Properties give context (which CTA/form), never identity
- No names, emails, or user ids in events
How it appears in analytics and logs
A custom event tells you a specific action happened. Inconsistent names (signup vs sign_up) fragment the same action across rows; PII in properties is a compliance problem.
Diagnostic use case
Design a small, consistent set of custom events with stable names and non-identifying properties, so reports stay clean and privacy-safe.
What WebmasterID can help detect
WebmasterID supports tagged CTA and form events (data-wmid-cta, data-wmid-form) with stable, semantic ids — no PII — so custom events stay useful and safe.
Common mistakes
- Inconsistent event names fragmenting one action.
- Putting PII in event names or properties.
- Tracking everything instead of the events that matter.
Privacy and accuracy notes
Custom event names and properties are stored and often visible in tooling — never encode names, emails, or IDs. WebmasterID rejects PII-shaped event attributes by convention.
Related pages
- The page_view event: the base of web analytics
page_view is the event fired when a page loads. It is the base of almost every web-analytics model: sessions, pageviews, and most reports build on it. In classic sites the tracker fires it automatically on load; in single-page apps you fire it on each route change. Its properties (path, title, referrer) drive most downstream reports.
- Conversion rate: definition and denominators
Conversion rate is the share of some base that converted. The trap is the denominator: conversions per session, per user, and per unique visitor give different numbers and mean different things. Without stating the base, a conversion rate is ambiguous — and comparing rates with different bases is meaningless.
- 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.
- CTA tracking (docs)
Tag CTAs and forms with stable, non-PII ids.
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.