The Core SaaS Event Model for B2B SaaS
B2B SaaS analytics is structurally different from B2C analytics, and most founding teams discover this the hard way — after they have already instrumented their product with a user-centric event model and realised they cannot answer the questions their sales team, their board, or their customer success team are actually asking.
The fundamental difference: in B2C, the user and the customer are the same entity. In B2B, the account (the company) is the customer, and users are individuals within that account. That single distinction cascades into a completely different approach to event design, property standards, and analytics architecture.
This guide defines the core B2B SaaS event model: the right taxonomy, the 15 events every B2B product must track, the property standards that make rollups possible, and how to keep the model maintainable as your product grows.
Why B2B Needs a Different Event Model 🏗️
In B2C analytics, the primary analytical unit is the user. Metrics like DAU, retention, and funnel conversion all operate at the user level. The event model is built around tracking individual user behaviour over time.
In B2B SaaS, user-level events are necessary but insufficient. The questions that drive B2B product and business decisions are fundamentally account-level:
- → Which accounts are becoming power users versus going stale?
- → Which accounts have invited enough team members to be considered "expanded"?
- → Which accounts have reached the usage threshold that triggers an upgrade conversation?
- → Which accounts are showing pre-churn signals across all their users?
Answering these questions requires aggregating user-level events up to account level. This only works cleanly if your event model is designed with account-level rollups in mind from the beginning. Retrofitting account-level analysis onto a user-centric event model is one of the most painful data engineering projects a growing B2B SaaS team will face.
The Multi-User Account Problem
In a B2B account with ten users, any single user's activity is a noisy signal. One power user and nine dormant users looks very different from a healthy account where eight users are active regularly. Your event model needs to support both individual user analysis (which users in an account are active?) and account-level aggregation (is this account healthy overall?) without conflating the two.
The Core Event Taxonomy
Most modern product analytics platforms (Segment, Amplitude, Mixpanel, RudderStack) are built around a three-call taxonomy that maps cleanly onto B2B SaaS requirements.
identify()
The identify call associates a user ID with a set of user traits. In B2B SaaS, user traits typically include: email, name, role (if captured), signup date, and any segment or persona classification. The identify call should be fired when a user first registers, and again whenever their traits change (e.g., role promotion, plan upgrade at the user level).
Critical: identify calls must always include user_id and account_id. Associating a user with their account is not optional — it is the foundation of account-level analytics.
group()
The group call associates the current user with an account and passes account-level traits. Account traits include: account_id, account name, plan, billing status, contract value (if enterprise), industry, team size, and the date the account was created. The group call fires when a user logs in or when account traits change.
Most teams under-invest in the group call. This is a mistake. The group call is what makes account-level analytics possible. Every trait you pass in the group call becomes queryable at the account level without additional engineering.
track()
The track call records a specific user action with associated properties. This is the workhorse of your event model. Every meaningful user interaction in your product should correspond to a track call with a standardised name and a defined set of properties.
The 15 Events Every B2B SaaS Must Track
The following events form the core instrumentation baseline for any B2B SaaS product. These are the minimum set required to answer the analytical questions that matter at every stage of growth.
| # | Event Name | Trigger | Why It Matters |
|---|---|---|---|
| 1 | Account Created | New account registered | Top of funnel; cohort start point for account analysis |
| 2 | User Signed Up | First user in an account registers | Identifies account creator; persona of the initiating user |
| 3 | User Invited | Existing user invites a new user | Virality signal; expansion within account |
| 4 | User Activated | User completes the defined activation event | Core retention predictor; activation funnel denominator |
| 5 | Onboarding Completed | User or account completes the onboarding checklist | Onboarding funnel endpoint; correlates with long-term retention |
| 6 | Core Feature Used | User performs the product's primary value action | Engagement depth; habituation signal |
| 7 | Collaboration Event | User shares, assigns, or comments within an account | Multi-user engagement; stickiness indicator |
| 8 | Integration Connected | User connects a third-party integration | Strong retention predictor; switching cost creation |
| 9 | Trial Started | Account enters trial period | Trial funnel start; needed for trial-to-paid conversion analysis |
| 10 | Trial Converted | Trial account upgrades to paid plan | Primary conversion event; trial cohort endpoint |
| 11 | Plan Upgraded | Account moves to a higher-tier plan | Expansion revenue signal; product-led growth indicator |
| 12 | Plan Downgraded | Account moves to a lower-tier plan | Pre-churn warning signal; requires immediate CS follow-up |
| 13 | Billing Event | Successful charge, failed charge, or refund | Revenue health; failed billing is a top churn driver |
| 14 | Account Churned | Account cancels or does not renew | Churn cohort analysis; required for LTV calculation |
| 15 | Feature Limit Reached | User hits a usage or feature gate | Upgrade trigger identification; pricing feedback signal |
Event Property Standards
Properties are what transform an event into a queryable, filterable, joinable data point. Without consistent properties, events pile up as a log without analytical value. These four properties are required on every single track call in a B2B SaaS event model:
| Property | Type | Description |
|---|---|---|
| user_id | string | Unique identifier for the user performing the action. Must be consistent across all events and all tools. |
| account_id | string | Unique identifier for the account the user belongs to. This is what enables account-level rollups. |
| timestamp | ISO 8601 string | The exact time the event occurred, in UTC. Never use client-generated timestamps as the canonical timestamp without validation. |
| session_id | string | Identifier for the current user session. Required for sessionisation and funnel analysis. Generate a new session_id when the user has been inactive for 30 minutes. |
Recommended Additional Properties
Beyond the four required properties, the following are strongly recommended for most events:
- → plan_id: The current plan of the account at the time of the event. Enables segmentation of behaviour by pricing tier without expensive joins.
- → user_role: The user's role within the account (admin, member, viewer). Essential for understanding which user types perform which actions.
- → source: Where the action was initiated — web app, mobile app, API, or email link. Required for cross-platform analysis.
- → feature_version: If the product feature involved has multiple versions or is under experimentation, track which version the user experienced.
The Account-Level Rollup Problem
The most common gap in B2B SaaS analytics is the inability to answer account-level questions from user-level events. Even with account_id on every event, computing account-level metrics requires aggregation logic that most product analytics tools do not perform automatically.
What Account-Level Rollup Requires
To know whether an account is "active" at a given point in time, you need to aggregate all the user-level events for that account_id and apply a business rule: e.g., "an account is active if at least one user in that account performed the core feature event in the last 14 days." This requires a data warehouse query or a pre-computed table — it cannot be done in a simple event stream without additional infrastructure.
Solutions by Maturity
- → Early stage (SQL-based): Write account rollup queries in SQL against your data warehouse or analytics database. Run them on a schedule (daily or weekly) and store the results in a summary table. This is the most flexible and lowest-cost approach.
- → Mid stage (Segment Personas / Amplitude Accounts): Segment's Identify-Group model and Amplitude's Accounts feature both support account-level trait computation from user events. These are appropriate when your event volume and account complexity outgrow manual SQL.
- → Advanced (dbt + BI tooling): At scale, account health scores and rollup metrics are best computed in dbt transformation layers, materialised into a BI-accessible schema, and visualised in a tool like Metabase, Looker, or Tableau.
How to Version Your Event Model
Event models are not static. As your product changes, events need to be added, renamed, deprecated, or have their properties extended. Without a versioning strategy, your historical data becomes unreliable and your team loses confidence in the analytics.
Event Model Versioning Principles
- → Additive changes are safe: Adding a new property to an existing event, or adding a new event, does not break existing queries. Do these freely.
- → Renaming breaks history: Renaming an event or a property creates a discontinuity in your data. Old queries stop working. If you must rename, keep the old event firing alongside the new one for at least 60 days, then deprecate.
- → Deprecations need documentation: When you stop firing an event, document when it was deprecated and what replaced it. Every event in your schema should have a status: active, deprecated, or planned.
- → Maintain a tracking plan: A tracking plan is a human-readable document (or structured schema in a tool like Avo, Segment Protocols, or a simple spreadsheet) that defines every event, its trigger conditions, its required properties, and its owner. Without a tracking plan, your event model becomes undocumented tribal knowledge.