Anonymous contexts

Overview

This topic explains what anonymous contexts are, how their information is handled in LaunchDarkly, and how they contribute to your monthly account usage.

You can designate any context as an anonymous context. Anonymous contexts work just like other contexts, except that they don’t appear on your Contexts list in LaunchDarkly. You can’t search for anonymous contexts on your Contexts list, and you can’t search or autocomplete by anonymous context keys. Anonymous contexts still count toward your limit for monthly contexts or monthly active users (MAU).

Here is an example of an anonymous context:

1
"context" = {
2
  "kind": 'user',
3
  "anonymous": true,
4
  "key": 'example-anon-user-key' // some SDKs will generate this for you
5
}

Designating anonymous contexts prevents unauthenticated users from diluting useful data on user contexts in the Contexts list. You can set the key attribute to a unique value for each context. Alternatively, some client-side SDKs can generate a unique, random value for each anonymous context and set the key attribute for you.

Configure your SDK: Anonymous contexts and users

Consider using multi-contexts

On a sign-in page in a single-page app, you could represent the same person as an anonymous user before they log in, and a different user after they log in. You can initialize the client with an anonymous context with a context kind of “user.” After the person logs in, you can update the user context so that it’s no longer anonymous using your SDK’s identify feature.

Try it in your SDK: Identifying and changing contexts

Alternatively, you could use a multi-context, that is, a set of several different contexts that you want to evaluate together. For example, as soon as an end user visits your app, you may initialize the client with a context using a context kind of “device.” When the end user logs in, you now also have their user information. To learn more, read Associate anonymous contexts with logged-in end users.

Manage stored contexts

There is no limit to the number of contexts you can evaluate or target with LaunchDarkly. However, LaunchDarkly stores only a limited number of unique context keys per environment and per 30-day period. Stored contexts are what appear in the Contexts list and what count toward billing usage metrics such as MAU.

This means you may see higher usage counts than expected if you unintentionally create many unique context keys. For example:

• Creating contexts that include request IDs. Each request generates a new unique context key, which LaunchDarkly then stores, even if the context represents the same end user.
• Creating contexts from server-to-server communication where there are no human operators, only software components interacting.
• Using LaunchDarkly to configure log levels or tracing with an identifier such as a timestamp. Each timestamp is treated as a unique context key.

To learn how to remove a stored context instance, read Remove a context instance.

Manage anonymous contexts

LaunchDarkly identifies all contexts by their unique key, including anonymous contexts. Using unique keys for anonymous contexts allows you to observe anonymous traffic interacting with your application, target anonymous traffic with percentage rollouts, and use Experimentation.

Anonymous contexts can raise your MAU count, but there are actions you can take to manage your MAU when using anonymous contexts. To learn more about MAU, read Account usage metrics.

Avoid storing anonymous keys locally

Most LaunchDarkly client-side SDKs automatically handle context key persistence for anonymous users. When you initialize an anonymous context, build the context object but omit the key property. The SDK generates a unique identifier for the context and persists it in local storage. LaunchDarkly SDKs do not store information in cookies.

When the same user returns to your site, the SDK recognizes them and uses the stored key. This ensures that the user receives consistent flag evaluations across browser sessions.

Check your SDK’s documentation to confirm whether it will generate a unique key for your anonymous contexts.

Configure your SDK: Anonymous contexts and users

If you manually manage storage for anonymous contexts, your stored keys can conflict with the SDK’s internal key management. They can also interfere with proper context transitions when users later authenticate, and may inflate your MAU count if they are not managed correctly.

If your application requires that you manually store anonymous context keys, you must ensure that the user reuses that same key on each subsequent visit to avoid inflating how many contexts you evaluate. This can be a challenge when using cookies or local storage to persist context keys, because those persistence methods are optional. End users can turn them off, and they are also often not observed by bots and site crawlers.

Wait to initialize your SDK

If you don’t need to expose flags to anonymous contexts, don’t initialize the SDK client for anonymous contexts. Instead, wait to initialize the client until after you know who your audience is. To learn more about SDK client initialization, read the Getting started documentation for your SDK.

Use a shared key between anonymous contexts

Associate anonymous contexts with logged-in end users

Before they log in, an end user might be represented by a device context. After they log in, they might be represented by two contexts, with one context kind based on their device and the second context kind based on their user information. This one person is now represented by two unique context keys.

If you want to associate two contexts with each other, you should identify a multi-context that includes both individual contexts when you want the association to occur. Unlike the aliasing method, the association doesn’t persist between calls. You must send the contexts you want to associate in each variation or identify call and each track call.

Try it in your SDK: Identifying and changing contexts

Depending on your billing model, you may be billed by MAU. To learn more, read Calculating billing.

Anonymous users and aliasing

If you are not yet using an SDK version that supports contexts, you can associate an anonymous user with a specific, logged-in user using the alias method.

To learn more, read How to use contexts instead of alias.