The exception event (error tracking)
An exception event records that a client-side error occurred — a JavaScript error or a failed operation. GA4 supports an exception event for this. Tracking errors in analytics ties reliability to behaviour: you can see which pages throw and whether errors correlate with drop-off. The catch is that error messages and stack traces can leak personal data, so what you capture needs care.
What this means
GA4 provides an exception event intended to record errors and crashes, with a description and a fatal flag. On the web you typically fire it from a window error handler or a try/catch, capturing that an error happened on a given page. It brings reliability data into the same place as behaviour, so you can see breakage in context.
Capturing errors without leaking data
Errors correlate with lost visitors: a page that throws on load and shows a high exit rate is bleeding conversions silently. But error data is a privacy hazard — messages can include echoed input, URLs can carry query-string identifiers, and stack traces can expose internals. Capture a generic, categorised description and the page; do not dump raw messages, full URLs with parameters, or anything a visitor typed.
- Fire from error handlers or try/catch with a description
- Correlate exceptions with exits to find costly bugs
- Capture generic descriptions, not raw payloads or inputs
How it appears in analytics and logs
A rise in exception events on a page signals something is breaking for real visitors. Exceptions clustered with high exits suggest the error is costing you conversions.
Diagnostic use case
Record client-side errors as events to find pages that break and link reliability to behaviour, while keeping personal data out of error details.
What WebmasterID can help detect
WebmasterID can surface client-side errors as first-party events tied to pages, so reliability problems are visible alongside traffic without ingesting sensitive error payloads.
Common mistakes
- Logging raw error messages that contain user input.
- Capturing full URLs with identifying query parameters.
- Ignoring exception events instead of correlating with drop-off.
Privacy and accuracy notes
Error messages, URLs, and stack traces can embed personal data (query strings, input echoes). Capture a generic error description, not raw payloads. 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.
- 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.
- 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.
- Website observability
See client errors alongside traffic.
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.