cMAU
Client-side monthly active users, or cMAU, is the billing unit for client-side SDKs.
What cMAU is
cMAU is the number of unique monthly active contexts, typically user contexts, that your client-side SDKs evaluate. LaunchDarkly counts each unique context key once within a rolling 30-day window. Marking a context as anonymous only hides it from the dashboard, so it does not reduce cMAU. Unauthenticated visitors count just like authenticated users.
Because billing follows the count of unique context keys, the way you generate and reuse keys drives your cMAU. Unstable or duplicated keys inflate the count even when your real traffic stays flat.
Keep cMAU predictable
The following practices keep your unique context keys stable and deduplicated over time.
Stabilize keys for unauthenticated visitors
What to look for: A new key created on every visit, page load, session, or SDK initialization, or a visitor assigned a different identity as they move across your properties.
What good looks like: The same unauthenticated visitor reuses a stable persisted key across revisits and movement between properties until they authenticate.
Why it matters: Unauthenticated contexts still count toward cMAU, so unstable keys can create a large amount of artificial growth.
To learn how to persist an anonymous key, read Session.
Use a separate context kind for unauthenticated visitors
What to look for: A single context kind reused for a visitor both before and after they authenticate, where the key changes from a temporary value to a durable one.
What good looks like: Unauthenticated visitors evaluate under one context kind, such as session, and authenticated users evaluate under another, such as user.
Why it matters: LaunchDarkly bills on your primary context. Keeping unauthenticated and authenticated visitors in separate context kinds prevents both populations from collapsing into one larger bucket of unique keys.
To learn more about these kinds, read Session and User.
Move authenticated users to a durable user ID
What to look for: Users continuing to evaluate flags under unauthenticated or transient identities even after sign-up or login.
What good looks like: Once a user authenticates, the SDK switches to a durable organization user identifier so repeat activity is deduplicated correctly over time.
Why it matters: Stable authenticated keys are one of the cleanest ways to avoid unnecessary cMAU growth for repeat users.
Standardize context kind and key design across platforms
What to look for: Different teams, properties, or platforms using different context kinds, key formats, or identity rules for the same end user.
What good looks like: Web, mobile, and other platforms all follow one documented context model with consistent key and kind semantics.
Why it matters: Consistency reduces duplicate counting and makes usage much more predictable.
Document your standardized context kinds in Context Types. That section also covers contexts in general.
Review where your context keys come from
What to look for: Client flows that generate fresh keys more often than intended, or evaluations that do not always pass an explicit context key.
What good looks like: The SDK initializes with a stable context, and identity transitions happen intentionally rather than repeatedly or implicitly.
Why it matters: The number of initializations or identify calls is not a billable metric. cMAU is driven entirely by keys. Focus your review on where your context keys come from and whether you always pass one, since initialization and identify patterns are where unstable keys tend to originate.
Centralize context creation
What to look for: Multiple teams or apps each generating their own keys and attributes ad hoc.
What good looks like: A shared wrapper or library defines how contexts are created across your properties and applications.
Why it matters: Centralized identity logic reduces drift and gives your organization one place to enforce good cMAU hygiene.
Configure application metadata
What to look for: Application metadata missing from the configuration passed to the SDK.
What good looks like: Every application team sets application metadata with correct and unique id and version information.
Why it matters: Application metadata attributes cMAU usage back to individual teams and application versions. This makes it easier to trace a regression or bug that inflates cMAU back to its source.
To configure application metadata, read the SDK application metadata documentation. Mobile SDKs also cover this in the preflight checklist item Configure application identifier.
Diagnosing unexpected cMAU
When cMAU grows faster than expected, use both in-platform reporting and a review of your SDK implementation.
Use in-platform reporting
Open Organization settings and select Plan usage, then open the Client-side MAU tab. Use the reporting to narrow down the source:
- Filter the chart by project, environment, SDK name, or SDK app ID to isolate which application drives growth.
- Filter by anonymous contexts to see how much of your cMAU comes from contexts marked anonymous.
- Select Rolling 30D to view a rolling count of MAU over the billing period.
The SDK app ID reflects the application metadata you configure, so accurate metadata makes this attribution reliable.
To learn more, read the account usage metrics documentation.
Review your SDK implementation
After reporting points you at a source, trace the keys in that application:
- Confirm unauthenticated visitors reuse a persisted key rather than receiving a new one per visit.
- Confirm authenticated users evaluate under a durable key.
- Confirm every evaluation passes an explicit context key rather than generating one implicitly.