How to Choose Segments for Feature Usage Analytics

Before UsageLens can tell you who uses a feature — not just how many times — each “this feature was used” record needs context attached: which kind of user, on which plan, in which version, in which region. Those dimensions are your segments, and the ones you choose up front decide which questions you can answer later. The right set isn’t universal — it depends on what kind of application you’re building and how your business is shaped. This guide walks through both.

What a segment is in feature usage analytics

A segment is a dimension of context attached to every usage record — separate from the feature identifier itself and from the identifier of the user who triggered it. Typical segments are user role, customer tier, customer/account, app version, environment, and region.

A note on terminology: in strict analytics usage, the attribute (or dimension) is the context key — subscription_tier — and a segment is the group of users who share one of its values, such as enterprise customers. This guide uses “segment” in the looser, common sense of the dimension you attach and slice by, because that is how you work with it in UsageLens. If you want the precise distinctions, see the vocabulary of feature usage analytics and terms people mix up.

Here’s why they matter. Say Feature A was used 10,000 times last month. On its own that tells you almost nothing. Segment it and the picture sharpens: 95% of the usage came from enterprise accounts, only admins ever touch it, and almost nobody on the free plan does. Same 10,000 — completely different story, and a completely different decision about whether to invest, gate it behind a tier, or leave it alone.

The principle to internalize before you instrument anything: you can only slice by what you send. If you never attach a plan tier to your usage events, no dashboard can later tell you whether enterprise customers use a feature more than free ones. And segments aren’t backfilled automatically — UsageLens only has a segment on the events collected from the moment you start sending it, not retroactively. Choosing your segments is really choosing the questions you’ll be able to answer six months from now.

Send a unique user identifier

Before the segments themselves, one attribute is worth singling out: a unique identifier for the user who triggered the event. It’s optional in UsageLens — tracking works without it — but it’s the single most valuable thing you can attach, because it’s the difference between counting events and counting people. Segments tell you which kinds of users reach a feature; a user identifier tells you how many distinct people do, and whether they come back. With it, UsageLens can report:

Unique users, not just raw event volume — so a feature leaned on by a handful of power users isn’t mistaken for one with broad reach.
Retention — whether the people who tried a feature come back to it next week or next month, or used it once and never again.
Accurate reach within every segment — distinct users per tier, role, or region, rather than invocation totals a few accounts can dominate.

Without it the analysis is much poorer — you can see that a feature is used, but not by how many people or whether usage is sticky. Adoption, reach, and retention all depend on counting people.

It should be an opaque, stable token — a hashed account ID or a random value you store against the user — and it should never contain a name, email, or anything personally identifying. A token like this is pseudonymous: it lets UsageLens recognize that two events came from the same user (which is what powers unique-user and retention counts) without telling UsageLens who that user is. Because it stays stable enough to link one user’s events, it still counts as personal data under GDPR — so keep it free of anything that identifies a real person. (More on how UsageLens handles this in the FAQ below.)

Does the right segmentation depend on your application type?

The short answer: the core segments are universal, but which matter most — and which are even available — changes with the application type. Almost every product benefits from knowing who used a feature (role), for which customer (account/tier), and when. What shifts is whether you have a notion of “customer” at all, whether version fragmentation is a first-class concern, and how much context you’re even allowed to send off the user’s machine.

Application type	Segments that matter most	Often unavailable or tricky
B2B SaaS	Customer/account, plan tier, user role	— (the easiest case)
B2C / consumer web	Plan tier, region, lifecycle stage, platform	Customer/account (there are only users)
Desktop apps	App version, release channel, OS/platform, license edition	Live plan changes; no central account
Mobile apps	App version, OS (iOS/Android), region	Forcing updates; long-tail old versions
On-premise / self-hosted	Deployment (tenant), edition/license, version	Per-user detail; privacy limits on what can leave
Open-source / dev tools	Version, environment (CI/local/prod), OS/runtime, config flags	Accounts (none); telemetry must be opt-in

B2B SaaS (multi-tenant web app)

The easiest case, and what feature usage analytics was built for. You have accounts, so customer and plan tier (free / pro / enterprise) are high-value, and your permission model gives user role (admin / editor / viewer) for free. Those three answer the questions that come up most: which segment relies on a feature you’re about to deprecate, whether a feature earns its keep among paying customers, and whether the people it was built for actually use it.

B2C / consumer web app

Consumer apps have users but rarely an account above them. Drop the customer dimension and lean on plan tier (free / premium), region/locale, acquisition cohort, and lifecycle stage (new / activated / returning). Platform (web / iOS / Android) matters more here than in B2B, because usage is split across devices.

Desktop applications

Installed apps (Electron, native) make app version and release channel (stable / beta) first-class segments — users run many versions at once, and adoption is inseparable from which build they’re on. OS/platform (Windows / macOS / Linux) matters for support and rollout, and instead of a live plan you usually have a license edition (free / pro / team) baked into the install.

Mobile applications

Mobile amplifies the version problem: store-review delays and users who never update leave a long tail of versions in the wild, so app version is essential for tracking adoption of anything new. Segment also by OS (iOS and Android often behave differently) and region (store availability and rollout). As with desktop, there’s usually no account — just a user/device token and a plan tier.

On-premise / self-hosted closed-source software

When each customer runs your software inside their own network, the deployment is the customer. Segment by a deployment/tenant ID, edition/license, and version (self-hosted customers upgrade slowly, so version skew is large). Privacy is the hard constraint — the data has to leave the customer’s network to reach you, and self-hosted buyers are sensitive about that, so keep what you send coarse and be ready to document exactly what each attribute contains.

Open-source frameworks, libraries & dev tools

No accounts, no tiers, and telemetry must be opt-in to be acceptable to the community. The useful segments are version (are people on the latest major?), environment (CI vs local dev vs production — a feature hammered in CI but idle in production tells a very different story), OS/runtime (Node or Python version, etc.), and config/integration flags (which adapters or plugins are enabled). For dev tools this is often the only way to learn which capabilities are actually reached.

Other types

Internal / line-of-business tools — segment by department/team and role; there are no external customers, but org structure is the equivalent dimension.
API-first / backend platforms — segment by calling application or service, API version, and environment. The “user” is often another system, and the API version replaces the app version.

Business properties that change your segmentation

Cutting across application type, a handful of properties about your business decide which segments are worth sending:

B2B vs B2C — do you have accounts above the individual user? If yes, customer/account and tier are your most valuable segments. If not, lean on cohort, region, and lifecycle.
Pricing model / plan tiers — any product with tiers should send the tier. It’s the cleanest way to see whether a feature justifies its place among paying customers, and whether free-tier behaviour differs from paid.
User roles / permission model — if different roles see different features, segment by role. A feature built for everyone but used only by admins is a signal worth catching.
Deployment model — cloud multi-tenant gives you accounts cheaply; single-tenant and on-premise make the deployment the unit and limit what you can collect.
Release channel & app version — essential anywhere users run versions you don’t control (desktop, mobile, self-hosted); largely irrelevant for a single always-current SaaS deployment.
Feature flags & experiments — if you roll features out behind flags or compare a feature before and after a redesign, send the variant or experiment name as a segment so you can compare adoption across versions. (UsageLens isn’t an A/B testing tool — this is just one more attribute to slice by, not an experimentation engine.)
Geography / region / locale — for staged rollouts, market analysis, and compliance.
Environment — always worth sending, if only to exclude staging, internal, and test traffic so your numbers reflect real customers.
Customer lifecycle stage — trial / onboarding / active / at-risk; useful for seeing whether a feature drives activation or only gets touched by veterans.
Privacy & regulatory constraints — these decide what you must not send. Keep every segment coarse and free of personal data (a tier, a role, a region — never a name or email).

A recommended starter set of segments

The temptation is to send every attribute you have. Resist it — start from the decision you’re trying to make and work backwards. Deciding which features deserve more investment? Send customer, tier, and role. Rolling something out gradually? Send version and release channel. Supporting self-hosted customers? Send deployment and version.

Three or four segments cover the majority of real questions. For most products this is a strong default:

Segment	Why it matters	Example values	Best for
Customer / account	Reveals whether usage is broad or concentrated in a few accounts	account ID	B2B
Plan tier	Shows whether a feature earns its place among paying customers	`free`, `pro`, `enterprise`	Any tiered product
User role	Tells you who uses a feature vs. who it was built for	`admin`, `editor`, `viewer`	Role-based products
App version / platform	Ties adoption to the build users run; essential where you don’t control the version	`3.2.0`, `ios`, `web`	Desktop, mobile, dev tools
Region	Supports staged rollouts and market/compliance analysis	`eu`, `us`, `apac`	Global products
Environment	Lets you exclude internal/test noise so numbers reflect real customers	`production`, `staging`	Everyone

Pick the rows that map to your application type and business: a B2B SaaS team starts with customer, tier, and role; a desktop app with version, platform, and license edition; an open-source tool with version and environment. Alongside whichever segments you choose, send the user identifier from earlier — it’s not a segment itself, but it’s what turns event counts into unique-user and retention numbers, so treat it as part of the starter set. And keep attribute names and values consistent — drifting between enterprise, Enterprise, and ent splits one segment into three and quietly corrupts your reports.

How segmentation is configured in UsageLens

Here’s the part that surprises people: in UsageLens there is no segment configuration screen and nothing to set up in advance. Segments are driven entirely by the attributes you attach to the usage events you already send.

Creating a new segmentation is as simple as starting to send a new attribute, with its values, on your usage events. The same one-line call that records “this feature was used” carries the (optional) user identifier and whatever context you attach — add subscriptionTier: "enterprise" or appVersion: "3.2.0", and you’ve created a segment. The moment those attributes start arriving, the new segment appears automatically in the dashboard as a dimension you can filter and compare by. No schema to define, no migration, no setup step.

In practice a usage event is just a small bundle of attributes:

{
  "feature": "report.export",
  "user": "u_7f42a91c",
  "userRole": "admin",
  "client": "acme-corp",
  "subscriptionTier": "enterprise"
}

feature is what was used and user is who used it (optional but recommended). Everything else — userRole, client, subscriptionTier — is an attribute you can segment by. Start sending one more attribute tomorrow and it becomes one more way to slice the same data.

That’s the whole workflow: pick the attributes that matter (this guide is your shortlist), attach them to your events, and slice by them in the UI. The only discipline is on your side — keep the attributes free of personal data, and keep their names and values consistent so the dashboard groups them cleanly.

Common questions

How many segments should I start with?

Three or four. Customer, tier, and role cover most B2B questions; version and environment cover most desktop, mobile, and open-source questions. Add more once you know which questions you keep asking.

Can I add a segment later?

Yes — start sending a new attribute and the segment appears immediately. But it only collects from that point forward; events recorded before you added it won’t have it. There’s no automatic backfill, so add the segments you care about as early as you can.

Should I send individual user information?

Send a unique but pseudonymous user identifier — an opaque, stable token, never an email or name. It’s optional but strongly recommended: it’s what lets UsageLens count distinct users and measure retention, and without it the analysis is much poorer. That’s different from tracking identifiable people — the token is used only to recognise the same user across events and count them, never to profile a named individual. You still segment by the kind of user (role, tier, region), not by who they are.

UsageLens is designed to work without any personally identifying information — you never need to send names or email addresses, only an opaque user token. That token is pseudonymous rather than truly anonymous: because it stays stable enough to count unique users and measure retention, it can in principle be linked back to a person, so GDPR treats it as personal data and you should too. To limit exposure, UsageLens applies a one-way hash to the user value on ingestion, so the raw value you send isn’t stored as-is. The practical upshot: keep names and emails out of the identifier, and you get unique-user and retention metrics on a pseudonymous token that’s straightforward to cover in your privacy documentation.

What if my app has no accounts (consumer, desktop, open-source)?

Skip the customer/account segment and lean on the dimensions you do have: plan tier or license edition, app version, platform/OS, environment, and region. Segmentation still works — you’re just grouping by product and context attributes rather than by account.