Event roles and tags
When you assign a Role during event setup, you’re not setting a permanent category; you’re choosing a shorthand for the event’s tags. Tags are the actual mechanism: they tell the model what an event means, which decides which starter metrics get generated and how the event participates in activity. Roles exist so the common cases are one dropdown instead of a tagging exercise.
The four roles
| Role | Meaning | What it unlocks |
|---|---|---|
| User | A user action | Counts toward activity (DAU/MAU); the default |
| Registration | The user’s first appearance | Cohorts, retention, LTV |
| Payment | Carries the transaction amount | Revenue metrics |
| System | System-triggered (push sent, server job) | Nothing; deliberately excluded from activity so it can’t inflate DAU |
Why System exists
The subtle one is System. A push notification delivery or a server-side job produces event rows, but no user did anything. If those rows counted toward activity, DAU would be inflated by infrastructure: users who received a push but never opened the game would look “active”. Tagging such events System keeps activity metrics honest, while the events remain available for analysis.
Choosing roles that matter
Two assignments carry most of the model:
- Registration anchors time. Cohort day, retention curves, and LTV all count days from the user’s first appearance, so the event you tag Registration defines when day 0 is.
- Payment anchors money. The event tagged Payment must carry the transaction amount; revenue, ARPDAU, ARPPU, and LTV read from it.
If either is missing or mis-assigned, the corresponding metric packs won’t appear during model building, and a hint card will point at the gap.
Tags after setup
Roles are a setup-time convenience; tags stay editable per event afterwards. When an event’s meaning is unusual (a registration that can repeat, a payment that needs excluding), adjust its tags on the event rather than forcing a role to fit.