Event Categories
A taxonomy for organizing your tracking plan by business value.
Every B2B SaaS tracking plan should cover these categories. Not every product needs every event, but every product should consciously decide what is in and what is out.
The categories below are ordered roughly by analytical value. Lifecycle, Core Value, and Collaboration events almost always justify their cost. Configuration events usually do. Navigation events rarely do.
Events vs traits vs snapshots
Before designing your event taxonomy, understand when to use each data element:
| Data type | Use when | Answers | Set via |
|---|---|---|---|
| Events | A user performs a significant action | "What happened?" | track() |
| Traits | You need enduring attributes for segmentation | "Who is this user/account?" | identify() or group() |
| Snapshots | You need current-state counts or statuses | "What exists right now?" | group() on a schedule |
If the data describes an action, it is an event. If it describes an enduring characteristic of the user or account, it is a trait. If it describes current state that needs periodic refresh, it is a snapshot metric.
Naming patterns by category
Each category follows a predictable naming pattern. Recognizing the pattern makes it easier to name new events consistently.
| Category | Pattern | Examples |
|---|---|---|
| CRUD operations | [Object]_[CRUD Verb] | Todo_Created, Todo_Updated, Todo_Deleted |
| Feature usage | [Feature]_[Action] | Advanced_Search_Performed, Bulk_Export_Generated |
| Workflows | [Workflow]_[State] | Onboarding_Completed, Setup_Wizard_Abandoned |
| Errors | [Context]_Error_Occurred | API_Error_Occurred, Validation_Error_Occurred |
See Naming Conventions for full naming rules.
1. Lifecycle events
What it covers: The user journey from first touch to churn.
Priority: Always track these. They are the foundation of every user and account analysis.
| Event | Description | When to use |
|---|---|---|
User_Signed_Up | User creates an account | Always |
User_Invited | Existing user invites someone | If your product is multiplayer |
User_Onboarded | User completes onboarding flow | If a formal onboarding exists |
Account_Created | New organization or workspace created | Always in B2B |
Account-level equivalents like Account_Created and Account_Churned capture the organization lifecycle, which is often more important than individual user lifecycle in B2B.
Note on activation: "Activation" is a computed state, not a tracked event. Track the actions that constitute activation (core value events, integrations connected) and let your analytics tool define what combination means "activated."
2. Core value actions
What it covers: The actions that are your product. If users never do these, they are not really using you.
Priority: Always track these. They are the single most important category for measuring product health.
These are product-specific. Examples by product type:
| Product type | Core value events |
|---|---|
| Project management | Project_Created, Task_Completed, Task_Assigned |
| Analytics | Report_Created, Dashboard_Viewed, Insight_Generated |
| Communication | Message_Sent, Channel_Created, Call_Started |
| E-commerce | Order_Placed, Product_Viewed, Cart_Updated |
How to identify core value actions:
- What would a user pay for?
- What does your pricing page promise?
- If this event count went to zero, would you panic?
Core value events should be the clearest, most specific events in your plan. The object should be a business concept your users recognize, not a technical entity. Report_Created -- not DB_Row_Inserted or Create_Button_Clicked.
3. Collaboration events
What it covers: Multi-user dynamics. The actions that make your product multiplayer.
Priority: Track these if your product supports more than one user per account. Skip if genuinely single-player.
| Event | Description |
|---|---|
Teammate_Invited | User invites another user |
Teammate_Removed | User removed from account |
Comment_Added | User comments on shared object |
Mention_Created | User @mentions another user |
Share_Created | User shares content with teammate |
Permission_Changed | User modifies access controls |
Why these matter in B2B: Multiple users within an account is a strong retention signal. Accounts with active collaboration churn at lower rates. Tracking collaboration events lets you identify accounts that are building sticky multi-user habits versus those relying on a single champion.
4. Configuration events
What it covers: Setup and settings. Distinguishes "using the product" from "configuring the product."
Priority: Usually worth tracking. Configuration depth correlates with stickiness.
| Event | Description |
|---|---|
Integration_Connected | User connects external service |
Integration_Disconnected | User removes integration |
Setting_Changed | User modifies a setting |
Notification_Toggled | User changes notification preferences |
Webhook_Configured | User sets up webhook |
API_Key_Created | User generates API credentials |
Why track these:
- Integration count is often a retention signal
- Configuration depth correlates with stickiness
- Settings changes can indicate friction or power usage
Naming note: Use the specific configuration object, not a generic "settings" bucket. Integration_Connected is far more useful than Setting_Changed with a type property. Configuration events are one area where separate events per object (integration, webhook, API key) are better than a single generic event.
5. Billing-adjacent events
What it covers: Commercial signals without being billing events. Actual billing events (charges, invoices) live in your payment system.
Priority: Always track these. They are critical for revenue analysis and churn prediction.
| Event | Description |
|---|---|
Trial_Started | User begins trial |
Trial_Extended | Trial period extended |
Plan_Viewed | User views pricing or plan page |
Plan_Upgraded | User upgrades plan |
Plan_Downgraded | User downgrades plan |
Limit_Reached | User hits usage limit |
Limit_Warning | User approaching limit |
These events are leading indicators. A user viewing the pricing page is an intent signal. A user hitting a limit is a conversion opportunity or a churn risk, depending on what happens next.
6. Feature usage events
What it covers: Actions that show how deeply users engage with specific product capabilities. Distinct from Core Value events -- these are the supporting features around the core.
Priority: Track selectively. Focus on features that differentiate your product or drive retention.
| Event | Description |
|---|---|
Search_Performed | User executes a search |
Filter_Applied | User applies a filter |
Export_Generated | User generates an export |
Template_Applied | User applies a template |
Naming guidance: Use the [Feature]_[Action] pattern. The feature name can be multi-word: Advanced_Search_Performed, Bulk_Export_Generated. The action verb should describe what happened, not the UI gesture that triggered it.
When variants exist: If the same feature has variants, push the distinction to group traits or snapshot metrics rather than creating separate events. In Accoil, where track calls carry no properties, one event per feature action is the right granularity.
7. Error events
What it covers: Errors that surface to the user and affect their experience.
Priority: Track the important ones. This is product telemetry, not operational monitoring.
| Event | Description |
|---|---|
Error_Encountered | User-facing error |
Validation_Error_Occurred | Form or input validation failure |
Permission_Error_Occurred | Access denied |
The boundary: Track errors the user experiences, not internal system errors. API latency, cache misses, and database query times belong in your operational monitoring tools (Datadog, etc.), not your product analytics pipeline. Product telemetry answers "what did the user experience?" -- operational telemetry answers "how is the system performing?"
8. Navigation events
What it covers: Sparse, structural context about where users go. This is the highest-volume, lowest-value category.
Priority: Default to not tracking. Add only when there is a specific question that only this event can answer.
| Event | Description | Notes |
|---|---|---|
Feature_Accessed | User accesses a feature area | For feature adoption tracking |
Help_Accessed | User opens help or docs | Friction signal |
Page views are almost never worth tracking. They are the single largest source of event volume inflation. A user navigating your app generates dozens of page views per session, and most tell you nothing actionable. Feature engagement events (Report_Created, Dashboard_Viewed) provide stronger signal at a fraction of the volume.
If you need page-level navigation data, use a dedicated tool with auto-capture rather than your analytics event pipeline.
Exception: A handful of commercially significant pages (pricing page, upgrade page) may justify explicit tracking as intent signals. Limit to 2-3 at most.
See Cost Optimization for more on managing event volume.
Category coverage checklist
When reviewing a tracking plan, verify coverage across all categories:
- Lifecycle: Can you reconstruct a user's journey from signup to churn?
- Core Value: Do you know when users do the thing you exist for?
- Collaboration: If multiplayer, do you see team dynamics?
- Configuration: Can you distinguish setup from usage?
- Billing-Adjacent: Do you see commercial intent signals?
- Feature Usage: Do you see how deeply users engage with key capabilities?
- Errors: Do you know when users hit problems that affect their experience?
- Navigation: Do you have just enough context without noise?
- Cost check: Could any events be consolidated? Are there high-frequency events that should be removed?