Active, Light, Passive, Dropped, and At-Risk Users: Practical Definitions

Define the four current engagement states

For a daily analyst, Active may require work on several days and completed analysis actions. For a monthly billing administrator, one successful review may be enough. Passive dashboard consumption can be valuable for an executive. A weekly project manager should not become Dropped after five quiet days, but several missed expected cycles may justify the state.

Keep invited-but-never-activated and new/onboarding users separate. Dropped implies a prior qualifying baseline.

Keep the reason visible

Light and Passive are useful only when their reasons remain visible. “Light because the user is new and has completed two of five onboarding workflows” differs from “Light after breadth fell from four areas to one.” “Passive monthly viewer with a successful review outcome” differs from “Passive operator whose completions fell to zero.”

Separate current state from momentum

Current state answers “What level of role-appropriate engagement exists now?” Momentum answers “How is that evidence changing?” Use labels such as gaining, stable, declining, insufficient history, or a specific risk flag.

An At-risk overlay should name the evidence: meaningful actions down materially, role-relevant area use stopped, expected cycles were missed, workflow completion fell, or activity became unusually concentrated. It is not a claim about future churn.

Momentum rules need a baseline that is meaningful for the role. Compare complete like-for-like periods and use both absolute and relative change. A drop from two actions to one is 50% but only one action; a daily operator falling from 80 to 40 meaningful actions may warrant different urgency. Preserve the counts behind the label.

Choose role-appropriate evidence

Make evidence inspectable: qualifying action names, active days, used areas, last qualifying date, comparison period, rule version, exclusions, and confidence. Exclude or label bots, integrations, staff, support impersonation, sandboxes, duplicated identities, and invalid events.

No single signal should silently dominate every role. Active days can show recurrence but not progress; Visits can expose frequency but also repeated friction; observed engaged time excludes idle periods but is not attention; breadth can be healthy or irrelevant; completion can be missed by imperfect instrumentation. Use a small role-specific rule and preserve the underlying dimensions.

Version each role rule

A role rule record should name the eligible population, qualifying actions or outcomes, expected cadence, current period, comparison period, Active and Light thresholds, Passive conditions, Drop window, risk overlays, exclusions, minimum history, rule version, and owner. Store the explanation produced by the rule alongside the label.

Apply eligibility, role, and lifecycle first

Before classification, establish that the user belongs to the account, had access and permission, was expected to perform the workflow, and had a realistic opportunity during the period. Segment rules by role and cadence rather than ranking everyone against a daily-operator threshold.

• Stable user and company IDs
• Role at the time of activity
• Relevant product areas and permissions
• Expected daily, weekly, monthly, quarterly, or event-driven cadence
• Lifecycle state: invited, onboarding, established, reactivated, or leaving
• Complete and comparable periods
• Human versus automation/support activity
• Known leave, role change, workspace move, or account migration where available

Worked B2B example

The users, accounts, and thresholds are fictional. They teach the method, not recommended defaults.

Priya's absence supports Dropped only because she was previously active and missed several weekly cycles. Jordan's sparse behavior may be appropriate for monthly consumption. Chris shows why login and page views can conceal lost workflow progress. Each label routes a different investigation.

Alex is the key two-axis case. He still crosses the Active rule with nine days and 21 meaningful actions, yet actions fell 45% and Reporting stopped. Replacing Active with At risk would erase current behavior; omitting the decline would erase direction. “Active + declining” preserves both facts.

Build a transparent and stable classification process

1. Define eligible role groups and expected cadence.
2. Name qualifying actions, progress, or consumption outcomes.
3. Select complete current and comparison periods.
4. Apply state rules to valid human behavior.
5. Calculate momentum separately from state.
6. Add rule-specific At-risk reasons and confidence.
7. Preserve evidence and alternative explanations.
8. Review the user's Company and selected Visits before action.
9. Version rules and monitor distribution changes.

Prevent status flapping with hysteresis: use different entry and exit thresholds where appropriate, require a minimum duration or multi-period confirmation, and preserve the previous state when history is insufficient. Do not invent a stable trend for a new user or compare partial onboarding periods as if they were mature baselines.

For example, a weekly user might enter Dropped only after three missed expected cycles but exit after one verified meaningful return. A declining flag might require two completed periods below the baseline, unless an abrupt stop in a critical workflow warrants earlier review. Document these choices; they are operating rules, not universal truths.

Monitor classification drift

Monitor label distributions when rules, instrumentation, roles, or product taxonomy change. A sudden portfolio-wide movement may be a data issue rather than real behavior. Keep the previous rule version and effective date so historical analysis remains interpretable.

Recalibrate only with evidence. Compare classifications with known workflows and customer context, inspect false positives and false negatives, and review whether roles or product behavior changed. Avoid tuning thresholds simply to create a preferred percentage of Active users.

Interpret users inside their company

A user status is incomplete without account context. One Dropped specialist may be offset by a successful role transition, or may expose a serious champion dependency. Several Light users may represent healthy occasional participation. Review company adoption, eligible roles, product-area distribution, concentration, ownership, and relevant Visits.

Ask whether another user took over the workflow, whether outputs continue, whether the account changed teams or workspaces, and whether the role is still eligible. A user-level signal becomes operational only when the account-level consequences and appropriate next action are understood.

Choose the next account action

Possible next actions include no action, instrumentation repair, role or identity correction, onboarding support, workflow research, backup-owner enablement, product investigation, or a customer question. Do not automatically message a user from a status change; review purpose, context, and privacy first.

At the company level, summarize the distribution of states by eligible role rather than counting every user record. A healthy account might contain one Active administrator, several Active operators, and Passive executive viewers. The same mix is concerning only if the intended workflow requires broader participation or continuity is fragile.

Inspect the supporting evidence

Hymetry connects Users to Companies, grouped Pages and product areas, and Visits. Teams can inspect why a state was assigned and whether the account pattern supports action. The product does not turn behavioral labels into deterministic health or retention outcomes.

Sources