Event catalogue template
An event catalogue is a structured list of the events a product captures to make user behaviour observable.
It helps teams understand what each event means, which workflow it belongs to, when it should fire, what properties it includes, and which metrics depend on it.
The catalogue is not just a technical inventory. It is a shared reference for product, design, engineering, and analytics teams.
What this is
This is a copyable template for documenting event definitions. Use it to keep event names connected to behaviour, workflow steps, fire conditions, properties, metrics, and ownership.
Related concepts: event, event property, fire condition, instrumentation requirement.
When to use it
Use an event catalogue when a product has more events than people can reliably remember or explain.
It is useful when teams need to:
- understand what behaviour is already tracked
- connect events to workflows and workflow steps
- define when events should fire
- document required properties
- identify duplicate or unclear events
- understand which metrics depend on which events
- maintain event quality as the product changes
A catalogue is especially useful when events are used across multiple dashboards, reports, or product teams.
What an event catalogue should include
A useful event catalogue should explain what the event is, why it exists, and how it should be used.
At minimum, include:
- event name
- event description
- related workflow
- related workflow step
- fire condition
- required properties
- related metrics
- owner
- implementation status
- review status
These fields help teams understand whether the event captures meaningful behaviour and whether it can be trusted.
Template
Event name:
[event.name]
Description:
[Plain-language description of what happened]
Related workflow:
[Workflow name]
Workflow step:
[Meaningful step the event relates to]
Purpose:
[Why this event is captured]
Fire when:
[Exact condition that should trigger the event]
Do not fire when:
[Conditions where the event should not be captured]
Required properties:
- [property_name]: [description]
- [property_name]: [description]
Related metrics:
- [Metric name]
- [Metric name]
Owner:
[Person, role, or team]
Implementation status:
[Not implemented / planned / implemented / needs review / retired]
Review status:
[Draft / active / needs review / retired]
Notes:
[Any useful context, assumptions, or known issues]
The format can be adapted for a spreadsheet, analytics governance tool, product management system, or documentation site. The important thing is that the catalogue stays usable and maintained.
Example: registration form submitted
Event name:
registration.form_submitted
Description:
The user submitted the registration form.
Related workflow:
Register for an account
Workflow step:
Submit form
Purpose:
Show that the user attempted to submit their registration details.
Fire when:
The user submits the registration form and the submission request is sent.
Do not fire when:
The user clicks submit but client-side validation prevents submission.
Required properties:
- entry_point: where the user started registration
- device_type: device category used by the user
- workflow_version: version of the registration workflow
Related metrics:
- Form submission rate
- Drop-off before email verification
- Time to complete registration
Owner:
Account access product team
Implementation status:
Implemented
Review status:
Active
Notes:
This event should fire once per valid submission attempt.
This example shows how an event catalogue keeps the event connected to the workflow, metric logic, and implementation detail.
How to maintain it
An event catalogue should be reviewed when the product or measurement model changes.
Review an event when:
- the related workflow changes
- a workflow step is added, removed, or reordered
- the event fire condition changes
- required properties are added or removed
- a metric depends on the event
- a dashboard using the event becomes important
- confidence in the event drops
The catalogue should not become a static list of event names. It should help the team keep event data meaningful and usable.
Common mistakes
Common mistakes include:
- listing event names without explaining behaviour
- omitting fire conditions
- missing required properties
- failing to link events to workflows or steps
- keeping retired or duplicate events in active use
- using inconsistent event names
- creating a catalogue that nobody owns
- treating implementation status as the same as event quality
An event catalogue should make events easier to understand, implement, test, and maintain.
How to apply this
Start with the events that support important workflows and metrics.
For each event, define:
- what behaviour it captures
- which workflow and step it belongs to
- when it should fire
- when it should not fire
- which properties are required
- which metrics depend on it
- who owns the definition
- whether it is active, needs review, or should be retired
Then use the catalogue when writing instrumentation requirements, reviewing metric quality, or checking whether a dashboard can be trusted.
Related articles
- Events as evidence
- What makes a good event?
- Writing instrumentation requirements
Key takeaway
An event catalogue helps teams keep event definitions clear, purposeful, and maintained.
It connects event names to behaviour, workflows, properties, metrics, and ownership, so teams can trust the evidence their product captures.