The vocabulary of feature usage analytics

Feature usage analytics has its own vocabulary: event, attribute, segment, cohort, adoption, retention, and a dozen more. The words are used a little differently by every tool, which is why they cause confusion. This article defines the terms you meet most often. It builds them up in the order they depend on each other, rather than alphabetically, because most of them only make sense once the earlier ones do. If you just want a definition, skip to the reference table at the end.

The data model: what the numbers are made of

Everything starts with a record of something that happened. The terms in this section describe the raw material.

Event — one recorded action. A user exported a report, opened a panel, ran a search. An event is the atomic unit: the smallest thing you measure. Each event carries a timestamp (when it happened) and an identifier (which user or account it belongs to), so those two are not separate concepts to track — they are parts of an event. One note for later: in general event-analytics tools an event is a raw action like a single click, but in UsageLens the event your app sends is a usage event — its signal that a whole feature was used. The Feature entry below explains the difference.

Event property (also called an attribute) — a piece of information attached to an event. plan = enterprise, role = admin, region = eu. Properties are what let you ask which kind of event happened, not just how many. The words “property” and “attribute” mean the same thing; tools pick one or the other.

User — one person. The unit you count when you want to know how many people did something, as opposed to how many times it was done.

Account (also called customer) — the organization a user belongs to. In business software this layer sits above the user: many users belong to one account. The split matters more than it looks. “80% adoption” measured across users can mean something completely different from 80% measured across accounts — a feature every admin uses looks widely adopted by users but might touch only a few accounts. Keep the two apart from the start.

Feature — a capability of your product: export, sharing, search, a specific report. An event is one simple action; a feature is a grouping of those actions. Both concepts are standard, but where the grouping happens differs by tool. General event-analytics tools log each action as its own event and reconstruct the feature from a combination of them after the fact. UsageLens works the other way around: your application decides when a feature has actually been used — when the required steps or conditions are met — and emits a single usage event carrying a stable feature identifier. The grouping happens in your app, at the moment of use, so one emitted event means one feature use.

Session — a bounded stretch of activity by one user, usually ended by a gap of inactivity. Useful for measuring how long people stay and what they do in one sitting. It matters less in feature usage analytics than in general web analytics, so treat it as a supporting term rather than a central one.

Slicing the data: attributes, dimensions, and segments

Once you have events with attributes, you start cutting the data into groups. This is where the word “segment” causes the most trouble, so the terms below are worth reading in order. For a closer look at the pairs people mix up, see Segment, cohort, dimension: terms people mix up.

Attribute / property — covered above: the piece of information itself, such as subscription_tier. On its own it is just data attached to events.

Dimension — an attribute used to break data down. It is the same data in a different role. subscription_tier is an attribute when it sits on an event; it becomes a dimension the moment you split a usage number by it. “Dimension” describes what you are doing with the attribute, not a separate field.

Segment — a group of users who share an attribute value. “Enterprise customers”, “admin users”, “EU users” are segments. The key point: a segment is a group of users, not the attribute and not the value. This is the precise meaning used by Amplitude, Mixpanel, and Heap. Many people (and some product UIs) loosely call the attribute itself a “segment” — that is common, but it is not the strict definition.

Segment value — the specific value that defines the segment: enterprise, acme, admin. Some tools call this an attribute value or property value instead. So the attribute is subscription_tier, the segment value is enterprise, and the segment is the group of users on the enterprise tier.

Filter — narrowing the data to a subset and hiding the rest. “Show only enterprise accounts” is a filter. You end up with one group.

Breakdown (also group by) — splitting one number into several, one per value of a dimension. “Break usage down by plan tier” turns a single total into free, pro, and enterprise side by side. A filter keeps one slice; a breakdown shows all the slices at once.

Measuring usage

These are the metrics. The companion article on measuring feature usage covers them in depth; here are the one-line definitions.

Adoption — did users start using a feature. Usually expressed as the share of a population (all users, or a segment) that has used the feature at least once in a period. For example, “56% of users used this feature at least once.”

Active users — the count of distinct users active in a time window. Reported as DAU, WAU, and MAU: daily, weekly, and monthly active users.

Unique users — the count of distinct people, as opposed to the raw number of actions. One person who exports ten reports is one unique user and ten events.

Usage count — the total number of actions, ignoring who performed them. The counterpart to unique users.

Frequency — how intensely one user uses a feature while they are active: many times a day, once a week, once and never again. It is a per-user rate within a period, not a measure of whether they stay. Example: a user who exports a report every morning has high frequency.

Retention — whether users stay over time: of the people who used a feature this month, how many come back next month. It is measured across periods against a starting group, and it is the core measure of whether something sticks. Example: 40% of the users who first tried a feature in January were still using it in March.

The two are independent. A user can hammer a feature ten times a day for one week and then quit — high frequency, poor retention. Another can use it once a month for a year — low frequency, high retention. Frequency is how much; retention is how long.

Churn — the opposite of retention: users who stop coming back. Applied to a product (“customer churn”) or to a single feature (“they tried it once and left”).

Time

Cohort — a group of users tied together by a shared event in time, most often when they joined or first did something. “Users who signed up in January” is a cohort. Cohorts are the basis of retention analysis: you follow the January cohort week by week and compare it to February. A cohort is defined by when; a segment is defined by what attribute. That distinction is the one people mix up most, and different tools blur it in different ways.

Time window — the period a metric covers. It can be fixed (calendar month) or rolling (the last 30 days, recomputed each day). The same metric gives different numbers depending on the window, so the window is part of the definition, not a detail.

Trend — the direction a metric moves over successive periods. Adoption rising month over month is a trend; a single month’s number is not.

Product decisions

These terms come up when usage data turns into a decision. They are the ones most specific to feature-centric analytics.

Feature adoption — adoption (above) applied to a specific feature: did users take it up.

Feature engagement — how much users keep using a feature after adopting it. Adoption asks did they start; engagement asks how much do they use it now. It combines the two metrics above: frequency (how much) and retention ( how long). A feature can have high adoption and low engagement — everyone tried it once, few came back.

Feature discovery — whether users can find a feature at all. Low adoption can mean the feature is unwanted, or simply that nobody found it; discovery separates the two.

Power user — a user in the top band of frequency or breadth of use. Power users often drive most of a feature’s usage count, which is why unique-user counts matter: a high usage count can come from a handful of power users rather than broad reach.

Deprecation — marking a feature as no longer recommended, usually as a step before removing it. Usage data tells you whether a feature is safe to deprecate.

Sunset — retiring a feature for good. The end state after deprecation.

Feature bloat — the accumulation of features that few people use but the team still has to maintain. Usage data is how you find it. See the cost of adding a feature has fallen, maintaining it hasn’t for why this matters more as features get cheaper to build.

Reference table

Term	In one line	Also called
Event	One recorded action ¹	—
Attribute	Data attached to an event	Property
User	One person	—
Account	The organization a user belongs to	Customer
Feature	A product capability; in UsageLens the app emits one usage event per use ¹	—
Session	A bounded stretch of one user’s activity	—
Dimension	An attribute used to break data down	—
Segment	A group of users sharing an attribute value	—
Segment value	The value that defines a segment	Attribute/property value
Filter	Narrowing to one subset	—
Breakdown	Splitting one number by a dimension	Group by
Adoption	Did users start using it	—
Active users	Distinct users in a window (DAU/WAU/MAU)	—
DAU / WAU / MAU	Daily / weekly / monthly active users	—
Unique users	Distinct people, not actions	—
Usage count	Total actions, ignoring who	—
Frequency	How intensely one user uses it (how much)	—
Retention	Whether users stay across periods (how long)	—
Churn	Users who stop coming back	—
Cohort	Users grouped by a shared event in time	—
Time window	The period a metric covers (fixed or rolling)	—
Trend	Direction of a metric over periods	—
Power user	A top-band user by frequency or breadth	—
Deprecation	Marking a feature as no longer recommended	—
Feature bloat	Unused features you still maintain	—