Customer Success
Customer success without a CS team: a playbook for small SaaS
You don't need a customer success hire to keep customers. A 30-minute weekly routine, three signals to watch, outreach templates, and when to actually hire.
Product Analytics
Feature adoption tracking for B2B SaaS: a practical guide
How to track feature adoption per account: which features to track, the first/last-use model, adoption rate vs health, and using it to onboard and expand.
Every B2B SaaS product has a few features that separate customers who stay from customers who leave. Usually the team has a hunch about which ones. Almost nobody has the data.
Feature adoption tracking turns that hunch into a per-account fact: which features has this customer adopted, when did they first use each one, when did they last use it, and how does that correlate with their health and their renewal? This guide covers how to set it up without over-engineering it.
Adoption vs usage: two different questions
“Feature usage” is what product analytics tools report: how many events, how many users, over what period. It’s useful for product decisions. It’s not very useful for customer decisions, because it’s aggregated across all users and doesn’t tell you anything about a specific account.
“Feature adoption” is an account-level state. For each customer and each feature you care about:
| Field | Meaning | Why you need it |
|---|---|---|
enabled | Has this account ever used the feature? | Discovery: did they find it? |
firstUsedAt | When did they first use it? | Time-to-adoption; onboarding stage rules |
lastUsedAt | When did they most recently use it? | Disengagement: did they stop? |
usageCount | How many times? | Depth: is it a habit or a one-off? |
Four fields per feature per account. That’s the whole model. It’s small enough to be readable on an account page and rich enough to power health scores, stage rules, and expansion targeting.
Which features to track
Not every feature. Track the ones that change how you’d treat the account. A good filter: if you learned a customer had not adopted this feature, would you do something about it? If no, don’t track it.
Typical candidates:
- Setup features that gate value: integration connected, data imported, team members invited
- Core workflow features: the thing your product is for (reports generated, invoices sent, campaigns launched)
- Stickiness features: the ones that make switching painful (API key generated, automations configured, custom fields defined)
- Expansion features: capabilities on higher tiers that predict an upgrade (bulk operations, advanced permissions, SSO)
Five to eight features is the sweet spot. You can always add more once the first set proves useful.
A quick way to choose: list every feature you shipped in the last year, then ask which three you’d be worried about if a customer hadn’t touched them by day 30. Those go on the list. Then add the two or three that only your best customers use. That’s usually the whole set, and it maps cleanly onto onboarding (the first group) and expansion (the second).
One more filter: track features at the account level, not the user level. If one person at a customer configured automations, the account has adopted automations. Per-user tracking is what product analytics is for; adoption is about whether the company got value.
Instrumenting it
Feature adoption needs one event per feature: fire it when the account uses the feature. With the LogoPulse SDK:
// Fire when the customer does the thing, not when they view the page
await lp.track('feature.enabled', accountId, { feature: 'BulkImportUsed' });Fire it on the meaningful action, not on page views. “Visited the bulk import page” is not adoption. “Completed a bulk import” is.
For features that can be turned off (an integration disconnected, an automation paused), fire a matching disable event so enabled reflects reality. A customer who disconnected Slack three weeks ago is disengaging, and you want that visible.
You can also derive adoption from entity events instead of tracking it separately: if batch.created events flow in, “BulkImportsUsed” can be set automatically the first time one arrives. LogoPulse does this through entity-to-feature mapping, so the same event updates entity velocity and feature adoption.
The metrics that come out of it
Per-account adoption status
The account page view: a list of tracked features with adopted / not adopted, first and last use, and count. This is what you look at before a renewal call. “You’ve been using bulk imports every week but you’ve never set up automations — here’s what that would save you” is a better conversation than “how’s it going?”
Adoption rate across the base
For each feature, what percentage of active accounts have adopted it?
| Feature | Adopted | Rate |
|---|---|---|
| Integration connected | 138 / 150 | 92% |
| Reports generated | 104 / 150 | 69% |
| Team members invited | 61 / 150 | 41% |
| Bulk import used | 34 / 150 | 23% |
| Automations configured | 19 / 150 | 13% |
Low adoption of a core feature is a discoverability or onboarding problem. Low adoption of an expansion feature is an upsell opportunity.
Time-to-adoption
Days from signup to first use of each feature. Long time-to-adoption on a setup feature means friction. On a stickiness feature, it means customers aren’t being shown it at the right moment.
Adoption vs health correlation
The number that justifies the whole exercise: do accounts that adopted feature X have higher health scores and better renewal rates than accounts that didn’t? If accounts with automations configured churn at a third the rate of those without, automations is your retention lever. Push it in onboarding, feature it in your emails, make it a stage rule.
You need enough accounts for this to be more than anecdote (50+), but even a rough split is more informative than guessing.
Using adoption data in three places
1. In the health score. Feature adoption is usually the second-largest component after activity frequency, at 20-30% of the score. Weight features by their correlation with retention, not equally. The customer health score guide covers weighting in detail.
2. In onboarding stages. “Setup complete” is a feature adoption rule: IntegrationConnected = true. “Active” might be IntegrationConnected AND ReportsGenerated. Stage rules built on adoption state are more meaningful than rules built on event counts alone.
3. In expansion targeting. Accounts with high health, high activity, and adoption of a feature that’s near the ceiling of their current plan are your upgrade candidates. Accounts adopting expansion features on a trial are your conversion candidates. The expansion revenue use case walks through how to build that list from adoption data.
Common mistakes
- Tracking page views as adoption. Views measure curiosity, not adoption. Track completions.
- Tracking too many features. Forty features per account is unreadable. Start with the handful that matter.
- Never marking features as disabled. Adoption that only goes up hides disengagement.
- Ignoring last-use dates. “Adopted in January, last used in February” is a churn signal in June. The count says adopted; the recency says gone.
- Not connecting it to health. Adoption data that lives in a separate tool from health scores is data nobody acts on.
Getting it running
If you already send events for the things customers create, adding feature adoption is one extra event type plus a list of features in a settings screen. LogoPulse stores the four-field adoption record per feature per account, calculates adoption rates across your base, and uses the same data in health scores and stage rules. See the feature adoption section of the features page for what it looks like, or start free with your first 20 accounts.