Turn behaviour into metrics

Events as evidence

Events are records of behaviour.

They show that something happened in the product: a user viewed a form, submitted details, encountered an error, verified an email, completed a step, or finished a workflow.

Events are not insight by themselves. They are evidence that product teams can use to understand behaviour, create metrics, and support decisions.

Evidence is not insight

An event can show that something happened. It does not explain what it means.

For example, registration.form_submitted shows that the user submitted the form. It does not show whether the form was easy, whether the user understood the next step, or why another user abandoned the workflow.

That interpretation comes later, by combining event evidence with metrics, dimensions, research, support feedback, operational knowledge, and product context.

Events make behaviour observable

A workflow describes what a user is trying to achieve. Events make parts of that workflow visible.

For account registration, useful events might include:

registration.form_viewed
registration.form_submitted
registration.form_error_shown
registration.email_verified
registration.completed

These events help the team see whether users are moving through the workflow, where they may be struggling, and which behaviours happened.

Without events, the team may know the intended workflow but not what users actually did.

Events are not the whole story

An event can show that something happened. It does not explain everything around it.

For example:

registration.form_submitted

This event can show that a user submitted the registration form. It does not show whether the form was easy, whether the user felt confident, whether they understood the next step, or whether they later reached the product.

Insight comes from interpreting events in context, such as:

other events in the workflow
metric definitions
user segments
research findings
support feedback
operational knowledge

Events provide evidence. Teams still need to decide what the evidence means.

Good events answer useful questions

Events should not be added only because something can be tracked.

A useful event helps answer a product question, such as:

did the user start the workflow?
did the user reach a meaningful step?
did the user encounter a problem?
did the user complete the intended outcome?
did the behaviour differ by entry point, device, or user type?

These questions help the team decide which events are worth capturing and which would only create noise.

Event design affects metric quality

Metrics are created from events, so weak events create weak metrics.

A metric may be hard to trust if the underlying events are:

missing
duplicated
inconsistently named
captured at the wrong moment
too closely tied to interface details
missing useful context
unclear in their definition

For example, a registration completion metric depends on how completion is captured. If the event fires when the form is submitted, the metric means something different from one based on email verification or first product access.

The event definition shapes the metric.

Events need context

An event name records what happened. Event properties explain more about the circumstances.

For example:

registration.form_error_shown

This event is more useful if it includes properties such as:

error type
field affected
device type
entry point
user type
workflow version

Without context, events can be technically correct but difficult to use.

How to apply this

Before defining an event, ask:

what behaviour should this event capture?
which workflow step does it relate to?
what product question does it help answer?
what metric might use it?
what context needs to be captured with it?

These questions keep event design connected to measurement purpose.

Products generate events, not metrics
What makes a good event?
Event catalogue template

Key takeaway

Events are evidence of behaviour.

They make workflows observable, but they do not create insight on their own. Good events capture meaningful behaviour, include useful context, and support the metrics and decisions the team cares about.