A feature can ship, run for months, and still leave you unable to say who actually uses it. You do not need perfect event tracking to answer that honestly, but you do need to stop quoting a number you cannot defend.
Start with a defensible adoption claim
A feature can be live for months without a confident adoption answer. Before event tracking, product databases, audit trails, CRM, support, and account reviews still provide behavioral evidence.
The gap matters because the base rate is unforgiving. Pendo's 2019 Feature Adoption Report, analyzing usage across thousands of cloud applications, found that roughly 80% of features are rarely or never used, and tied tens of billions of dollars of cloud R&D spend to features nobody touches. An older Standish Group analysis presented at the XP2002 conference reached a similar place, with 45% of features never used and another 19% rarely used. Against numbers like those, assuming a feature is adopted because it shipped is the expensive default, and a defensible count is what tells you which side of that ratio you are on.
Do not manufacture a polished rate from incomplete records. Create an adoption proof artifact: an inspectable record of the adoption definition, eligible customers, evidence, query gaps, and confidence. It supports decisions to improve onboarding, investigate a segment, pause rollout, or fund instrumentation.
Use a narrow definition. For workflow features, adoption is rarely seeing a button or enabling a setting; it is an eligible account completing the value-bearing action and, when relevant, repeating it in the product's natural interval.
Manual adoption rate = eligible accounts with verified value behavior / eligible accounts exposed to the feature
Scrutinize the denominator as much as the numerator. Pre-launch accounts may be theoretically eligible but blocked by plan restrictions, permissions, unfinished migration, or disabled integration; counting them creates a fictional adoption problem.
Build an evidence chain from product records
Start with the strongest record nearest the action. A completed-workflow row is stronger than a CRM note that a customer “uses the feature.” Support can explain a failed attempt, not prove successful use. Layer evidence rather than blending it into a vague count.
| Evidence source | Establishes | Common distortion | Best use |
|---|---|---|---|
| Product database | Saved object, completed job, changed state | Test data, automated jobs, deleted records | Primary count |
| Audit log | Actor and time | Missing retention, system actors | Repeat use, actor validation |
| CRM | Contract scope, plan, rollout, owner context | Stale fields, optimistic notes | Eligibility, segmentation |
| Support | Friction, failures, workarounds, requests | Vocal customers are not the cohort | Diagnose non-adoption |
| Account review | Whether use produced value | Recall bias, uneven documentation | Edge cases |
Query the outcome, not an easy proxy. For collaboration, count approval records; for exports whose value requires an external destination, count completed deliveries, not “Export” clicks.
Audit trails reveal repeat behavior
This query counts accounts completing an action after eligibility. Adapt schema names and statuses, and save the exact version in the proof artifact.
WITH eligible_accounts AS (
SELECT a.id AS account_id, a.plan, a.feature_enabled_at
FROM accounts a
WHERE a.feature_enabled_at IS NOT NULL
AND a.status = 'active'
), verified_use AS (
SELECT DISTINCT al.account_id
FROM audit_log al
JOIN eligible_accounts ea ON ea.account_id = al.account_id
WHERE al.action = 'approval.completed'
AND al.actor_type = 'user'
AND al.created_at >= ea.feature_enabled_at
)
SELECT
COUNT(*) AS eligible_accounts,
COUNT(vu.account_id) AS adopted_accounts,
COUNT(vu.account_id)::decimal / NULLIF(COUNT(*), 0) AS adoption_rate
FROM eligible_accounts ea
LEFT JOIN verified_use vu ON vu.account_id = ea.account_id;
actor_type = 'user' removes non-user events only if your schema classifies them that way; check test accounts and admin repairs separately. If audit retention is only 90 days, report a 90-day view, not lifetime adoption.
For repeat value, require two completed actions on different dates or a second within the expected interval. Payroll may be monthly; a shared inbox may need weekly activity. No universal repeat window is defensible.
Match the manual method to data maturity
Settling those repeat windows still leaves an open question: which manual method the answer deserves. Manual measurement has a ceiling. Choose a method by record quality, decision consequence, and whether use is individual or account-level.
A one-off database query is the cheapest place to start, and it holds up whenever a launched feature leaves a durable object or status change behind; its weak point is identity, since a bare row rarely says which account or user it belongs to. An audit-log cohort costs a little more to assemble but earns it once the log records actor, action, timestamp, and target, with retention as the ceiling that quietly truncates history older than the window. When a feature ships to enterprise accounts, a CRM-assisted account review is worth the medium effort, on the standing condition that CRM fields drift from product reality. When the real question is failure modes, a support-tag review surfaces them at similar cost, though what you see is shaped by how support tags rather than how customers behave. For a small launch group or beta, a structured manual cohort gives the richest read for the highest effort, and its main risk is two reviewers applying different criteria unless you write them down.
A structured cohort review fits a multi-step workflow that ends outside the product, but check what each record proves first: a B2B integration can create a connection row while value depends on downstream data arriving correctly, and that row measures setup, not adoption.
Do not spend a week reconciling edge cases for a low-risk question, or use a loose CRM field to decide whether to remove a paid-tier feature. Required evidence rises with the cost of being wrong.
When account records impersonate adoption
Choosing the right method matters little if the underlying records quietly count the wrong thing. Pre-tracking metrics often mistake availability, configuration, or exposure for use. An account may enable a rules engine, create one rule, and never activate it; another may use an API with no named interface user; a third may be CRM-marked “live” after a success call although support shows the integration failed the next day.
Separate these states:
- Eligible: usable under plan, permissions, and technical setup.
- Configured: prerequisite completed, such as connecting a source or creating a rule.
- Used: value-bearing action occurred once.
- Repeated: action recurred in the expected interval.
- Validated: product and customer-facing evidence agree that the intended outcome occurred.
This prevents charts rising after onboarding because setup increased while repeat use stayed flat: activation improved, not durable adoption. It changes the next decision.
Also define the unit: account, user, workspace, project, or transaction. One administrator may mean shallow collaboration penetration but be the intended model for a finance-control workflow.
Run a two-week cohort review across product, CRM, and support
For a meaningful launch cohort, a two-week review is more reliable than one dashboard request. Freeze the cohort and record eligibility date, plan, rollout condition, owner, and segment in one sheet for every account.
Every account in the frozen cohort gets the same columns. The eligibility date is when the feature flag went live for that account, say 12 May, owned by product operations. First verified use pairs an audit event with the created object, an approval for instance, and is confirmed by a product analyst or engineer. Repeat use is a second approval about a week later, checked by the same analyst. Customer context (the CRM rollout stage and the named workflow the account actually runs) comes from customer success, and any friction signal, a tagged ticket or a call note, from the support lead. The review owner closes each row with a confidence grade of A, B, or C and the reason for it.
Product/engineering owns the query and schema assumptions. Customer success verifies scope and external blockers. Support groups failures-permissions, import errors, confusing setup, workflow mismatch. A product manager resolves ambiguity and records the definition.
Request evidence tied to a known account ID, not verbal estimates. “Team is evaluating approvals” is context, not usage. A ticket titled “approval notification delayed” can reveal a completed action missed by audit logs, but needs date, account, and ticket status before amending the cohort.
Publish verified use, repeated use, and unverified or ambiguous accounts. The ambiguous bucket identifies the instrumentation gap.
Grade confidence before reporting a rate
A manual rate is an estimate with an audit trail, not an instrumented-metric substitute. Grades prevent treating percentages as equally trustworthy.
Grade A is a durable product record with known eligibility, clear identity, and a repeat check where it matters; report it as “Verified adoption.” Grade B rests on a strong product record with one known gap, usually incomplete historical logs, and travels as a “Directional adoption estimate.” Grade C leans on CRM, support, or interview evidence with no durable product record behind it, so it is reported as “Customer-reported or manually reviewed use.”
Keep calculation and caveats together: “Cohort: active Pro accounts enabled between 1 and 31 May. Use: approval.completed by a human actor after enablement. Repeat: a second completion within 14 days. Exclusions: internal accounts, migration jobs, disabled accounts. Source: production database query dated 15 June. Grade: B because audit retention begins after the earliest enablements.”
This is more useful than a chart labeled “feature adoption”: it enables reruns, explains movement, and exposes weak evidence. Use grades to prioritize tracking. C-grade evidence for pricing, retention, compliance, or expansion makes instrumentation essential; a small beta with database-proven behavior may use manual measurement until it graduates.
Instrumentation should close known evidence gaps
Analytics makes recurring analysis cheaper, reveals sequences tables hide, and enables segmentation; it does not erase judgment. Base first tracking on manual-review blind spots, not generic button-click catalogs.
Turn unresolved questions into events or properties. If exports cannot be separated into success and abandonment, track export_started, export_completed, failure reason, destination type, and account plan. If account-level adoption hides shallow team use, add user identity and role. If value depends on an external system, record delivery confirmation where privacy and technical constraints allow.
Keep the original definition after tracking. Redefining adoption from completed workflow to button click because the event is convenient breaks trends. Run the manual query and event definition in parallel for one review cycle, reconcile differences, then retire the old artifact.
Leave the review with a metric contract
Treat available records as limited evidence, not a reason to abandon measurement or invent certainty. Start with one value-bearing action, a clearly eligible cohort, and a saved query; add CRM and support only when they change interpretation.
Before the next launch review, write the metric contract: unit, eligibility rule, value event, repeat interval, exclusions, source tables, owner, review cadence, and confidence grade. It gives analytics a precise instrumentation brief and leaders a decision-ready answer before a dashboard exists.