The Five Events Every B2B SaaS Should Track from Day One
Most B2B SaaS instrumentation starts as a hundred events and ends as five useful ones. Skip the cleanup phase and start with the five that matter.
The typical B2B SaaS analytics setup goes through three phases. Phase one: instrument nothing, regret it six months later. Phase two: instrument everything, drown in 200 event types nobody can navigate. Phase three: realise you actually use about five of them and quietly stop tracking the rest.
This post is about skipping to phase three. If you’re starting from scratch, or rationalising an existing setup, these are the five events that earn their keep.
1. signup_completed
The boundary event between “visitor” and “user.” Fired the moment a user has a credential and an identity in your system, with whatever properties you have at that point — acquisition source, plan tier (even if it’s “free”), referrer.
Why it matters: this is the cohort anchor for every retention chart you’ll ever build. The cohort definition is “users who signed up in week N,” which requires this event to be unambiguous. If signup is multi-step in your product (email collected → verified → onboarded), fire signup_completed at the moment the user becomes counted, not before.
Properties to attach: utm_source, utm_campaign, referrer, signup_method (email, Google, SSO), plan_tier, country. If you can capture company_size or role from a signup form, capture those too — they’re the breakdown dimensions you’ll use most often.
2. activated
The single event that defines “this user has experienced the value of the product.” Not signup. Not login. The specific action that, statistically, correlates with retention.
What this event actually is depends on your product. For Slack, historically, it was “sent 2,000 messages.” For Dropbox, “put one file in one folder on one device.” For a typical B2B SaaS, it’s some version of “completed the first meaningful action that uses the product’s value proposition.”
Defining this event is the most important instrumentation decision you’ll make. It’s also the one most teams skip, because it requires picking. Don’t skip it. Pick a candidate definition, ship it, and revisit in a quarter when you have data on whether the chosen definition actually correlates with retention.
Properties to attach: time_to_activation (seconds from signup), activation_path (which flow they took), and whatever specific dimensions of the activating action are meaningful (e.g., for a database tool, first_table_size).
3. core_action_completed
The single event that represents the user doing what your product is for, after activation. The repeated action that defines an active user.
For a project management tool, this is task_created or task_completed. For a CRM, contact_logged. For a writing tool, document_saved. For an analytics tool, query_run.
Why this specific event and not all events: most B2B products have one or two events that are 10x more correlated with retention than any other. That’s the event you want to count, segment, and build retention charts around. Tracking 50 other events is fine; building product metrics around them is noise.
Properties to attach: the dimensions of the action that matter for segmentation — feature used, plan tier, integration involved.
4. subscription_changed
Any event that materially changes the user’s relationship with the product: free → paid, plan upgrade, plan downgrade, churn, cancel-then-reactivate.
Why one event for all of these: subscription state changes are not separate types of events — they’re the same event with different from_state and to_state properties. Tracking them as one event lets you build a single funnel for “users who went from free to paid to enterprise” and a single retention chart for paid-tier users that’s robust to plan-tier shifts.
Properties to attach: from_plan, to_plan, from_state (trial, active, cancelled), to_state, change_reason if available, mrr_delta.
This event is also the cleanest source of truth for revenue analytics. You don’t need to ingest Stripe webhooks into your analytics tool if you fire this event well — the events themselves are the source of truth for plan changes.
5. integration_connected
For most B2B SaaS, connecting an integration is the second-strongest leading indicator of retention after activation. Users who connect at least one integration retain at roughly 2-3x the rate of users who don’t, across most B2B categories. (Your numbers will vary, but the directional finding is consistent.)
Tracking integration connections lets you:
- Identify which integrations matter for retention (some matter much more than others)
- Identify the right time to prompt for integration setup in onboarding
- Identify accounts at risk (integration disconnected → churn risk spike)
Properties to attach: integration_name, integration_category, connected_by_user_role, time_since_signup.
If your product doesn’t have integrations, replace this slot with whatever your equivalent “user invested something in the product” event is — invited a teammate, set up SSO, configured a workflow. The principle is the same: track the event that represents the user making a commitment beyond pure usage.
What’s deliberately not on the list
A few omissions worth defending:
page_view. Most analytics tools autocapture page views. Don’t disable that, but don’t treat it as a strategic event either — it’s substrate, not signal.
button_clicked events for every button. Heap-style autocapture is fine; explicit instrumentation of every click is noise. If a specific click matters strategically, give it a named event.
email_sent, email_opened, etc. Email engagement belongs in your email tool, not your product analytics. Joining them later (via the same user ID) is cheap; conflating them upfront is expensive.
error_occurred. Errors belong in your error tracking tool. Cross-referencing errors with product analytics is sometimes useful, but the source of truth for errors should be Sentry or equivalent.
The instrumentation discipline
Five events is the floor, not the ceiling. As your product grows, you’ll add events for specific features, experiments, and segment-level questions. The discipline is:
- Every new event needs a question it’s there to answer.
- Every new event needs a property schema documented before it ships.
- Every quarter, audit which events are actually being queried. The ones that aren’t, deprecate.
Teams that follow this end up with 20-40 events, all of which are actively useful. Teams that don’t end up with 200 events, of which 30 are useful and 170 are confusion.
Start with the five. Earn the rest.
Truxl auto-detects event schemas and surfaces unused events in your project audit view. Get started with the five-event setup.