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 client-side monthly contexts or monthly active users (MAU).

Here is an example of an anonymous context:

"context" = {
  "kind": 'user',
  "anonymous": true,
  "key": 'anon-user-key-123abc' // some SDKs will generate this for you
}
COPY

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.

Context account limits

Each environment in your account is limited to 3,000,000 contexts per 30-day period. You may hit this limit accidentally if you use too many unique keys. If you feel like you hit this limit too frequently, you may be creating more contexts than you realize, including anonymous contexts.

Here are some examples of ways you may unintentionally create unique context keys:

• By creating contexts that include request IDs. When you do this, each context generates a new context key every time it requests against the server. Contexts do not need a unique key to use a request ID. For example, an unauthenticated API might only give you a request ID, not a context key.
• By creating contexts from server-to-server communication where there are no human operators, just software components interacting.
• By using LaunchDarkly to configure log levels or tracing. When you do this, you may use a different type of ID, like a timestamp. LaunchDarkly classifies each of those IDs as unique IDs.

To learn how to delete a 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 MCI count, but there are actions you can take to manage your MCI when using anonymous contexts. To learn more about MCI, read Account usage metrics.

Store anonymous keys locally

If you provide the anonymous context key yourself, you must ensure that the context uses that same key on each subsequent visit to avoid inflating how many contexts you evaluate.

One strategy to make sure that you're using the same anonymous context key each time is to store the unique identifier in a cookie or local storage. Because this is such a common strategy, we've implemented it directly into many of our client-side SDKs. If you use a client-side SDK and want to use a unique key for your anonymous contexts, you can defer key generation onto the SDK. To do this, build a context object and omit the key completely. The SDK generates a unique identifier for the context and persists this unique identifier in local storage. Each subsequent context evaluation without a context key uses that saved unique identifier. Check your SDK's documentation to confirm whether it will generate a unique key for your anonymous contexts.

A challenge from using cookies or local storage is that they are optional. End users can turn them off. 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.

Depending on your billing model, you may be billed by contexts, or by monthly active users (MAU). For contexts-based billing, only contexts of your primary context kind are counted toward your limit. For MAU-based billing, only user contexts are counted.

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.