Event Tracking
Event tracking is the practice of recording specific user interactions, such as button clicks, form submissions, or quiz completions, as discrete data points called events. Each event can carry parameters that add context like value, category, or score.
Key takeaways
- An event is an immutable fact with a name, timestamp, actor, properties and context.
- Firing on click measures intent; firing after server confirmation measures the actual outcome.
- Low-cardinality typed properties stay queryable, while free text and raw numbers do not.
- A tracking plan naming events, properties, types and owners prevents drift across teams.
- Events cannot be backfilled, so anything unmeasured today is unavailable for future analysis.
In depth
An event record is a fact with a shape: a name, a timestamp, an identifier for who did it, a set of properties describing that occurrence, and context such as page, device and campaign. It is emitted from a specific line in the code, travels to a collector, and is stored append-only. That immutability is the important part. A state field like lead_status can be overwritten and its history lost, whereas a stream of status_changed events preserves the order and timing of everything that happened.
Accuracy depends mostly on where you put the emission point. Firing on click records intent, firing after the server confirms success records outcome, and the gap between them is every failed submission counted as a conversion. Property design decides the rest: a small set of typed, low-cardinality fields stays usable for years, while free text and unbounded numbers become unqueryable. Every extra event also costs payload, storage and the attention of whoever must later explain what it means.
The practical artefact is a tracking plan: a table listing each event, when it fires, its properties, their types and allowed values, and the person who owns it. Instrument funnel milestones rather than every interaction. In a quiz funnel that is a start, one step event carrying the question index and whether it was answered or skipped, and a completion carrying the score band. Three well-specified events answer more questions than thirty improvised ones. The plan is what keeps that discipline.
Events describe behaviour, not motivation. A drop-off at question four tells you where people leave but never why, so the data sets up a hypothesis that only user research or a test can settle. Instrumentation is also not retroactive: an event you did not define last quarter cannot be recovered this quarter. And because collection depends on scripts and consent, absolute counts are always a floor, which makes ratios between steps far more dependable than totals.
Example in practice
How to measure it
Validate the instrumentation before analysing anything. For each event, walk the flow once and confirm it fires a single time with populated properties, then compare a day of collected events against the corresponding rows in your application database. Volume that exceeds the database count means duplicate firing; volume below it means loss from blockers, consent or a trigger that misses some paths through the interface.
Once trusted, read events as ratios. Step-to-step completion across a funnel isolates the weak point far better than an overall conversion rate, and the time between two events reveals hesitation that counts alone hide. Track the share of events arriving with missing or null properties as a health metric, since a rise there usually precedes a broken report by weeks and is easy to alert on.
Common mistakes
Instrumenting the button instead of the result is the failure that quietly inflates every report. The click event fires, the request then times out or validation rejects the form, and the conversion count includes people who never got through. Move the emission to the success handler, and if you need both, use separate names such as attempted and completed so the difference itself becomes a diagnosable metric rather than an invisible error.
The second is stuffing meaning into names. Teams create quiz_complete_marketing, quiz_complete_sales and quiz_complete_v2 instead of one event with a segment property, and every report then needs a maintained list of variants. Keep names stable and put variation in properties. Equally common is instrumenting everything at once: dozens of events ship, nobody defines an owner, and within a year no one can say which are still accurate.
Frequently asked questions
What is the difference between an event and a parameter?
An event is the named action, such as quiz_complete, while a parameter is extra context attached to it, like a score or category value. Parameters let you segment and analyze events more precisely.
What is a data layer in event tracking?
A data layer is a structured object on the page that exposes user actions and context, so tools like Google Tag Manager can read them and forward the events to analytics and ad platforms.
What should an event be named?
Use a consistent object and action pattern in past tense, such as quiz_started or lead_submitted, in a single casing style. The point is predictability: anyone should be able to guess the name of an event before looking it up. Avoid encoding audiences, campaigns or versions in the name, since those belong in properties where they can be filtered.
How many events should I track?
Fewer than instinct suggests. Start with the milestones that map to funnel stages, usually between five and fifteen for a marketing site, and add an event only when you can name the decision it will inform. Volume is not the constraint; maintenance is, because every event needs an owner who knows whether it still fires correctly.
Should events fire from the browser or the server?
Fire from the server whenever the event represents a confirmed outcome, since the server knows if the record was actually written. Fire from the browser for interaction detail such as steps, hesitation or abandonment, which the server never sees. Many teams do both and join them on a shared identifier, keeping the server as the authoritative source for conversions.
What is a tracking plan?
A tracking plan is the shared document defining every event, the moment it fires, its properties, their data types and allowed values, and its owner. It exists so implementation, analysis and reporting agree on meaning without reading code. Reviewing it before each release is what stops two teams from shipping different names for the same user action.
Can I change an event after launch?
You can, but the history does not change with it. Renaming an event splits your data in two, and altering what an event means without renaming it is worse, because charts stay continuous while the underlying definition shifts. If semantics change, introduce a new name, run both briefly, and document the cutover date so future analysts can interpret the seam.
Why do my event counts differ between tools?
Different tools apply different session logic, deduplication, attribution and filtering, and each loses a different share to blockers and consent. A tool receiving events from your server will normally report more than one relying on browser scripts. Pick one system as the reference for each question and compare trends across tools rather than expecting identical totals.