• Home
  • Integrations
  • SDKs
  • Guides
  • API docs
No results for ""
EXPAND ALL

EDIT ON GITHUB

Anonymous users

Read time: 4 minutes
Last edited: Oct 26, 2021

Overview

This topic explains what anonymous users are, how their information is handled in LaunchDarkly, and how they contribute to your Monthly Active Users (MAU) count.

The most common reason to designate anonymous users is to prevent unauthenticated users from diluting useful data in the Users dashboard. Anonymous users work just like regular users, except that they don't appear on your Users page in LaunchDarkly. You can't search for anonymous users on your Features page, and you can't search or autocomplete by anonymous user keys. Anonymous users still count toward your MAU limit.

You can designate any user as an anonymous user. If you don't want anonymous users to count toward your MAU, you can assign all anonymous users the same shared user key. If you don't specify a key attribute, the SDK generates a random user key for them.

Ensuring user privacy

You can use anonymous users to hide personally identifiable information (PII), but we recommend using private user attributes instead.

To learn more, read Private user attributes.

To learn how to create anonymous users, read your SDK-specific section in User configuration.

Understanding how anonymous users contribute to MAU

Anonymous users contribute to MAU. LaunchDarkly can track anonymous users in two different ways:

  • With a shared key
  • By unique keys

If you specify a unique key for each anonymous user, LaunchDarkly tracks those users by session. If you do not specify a unique key for each anonymous user, and the user has saving to local storage disabled, LaunchDarkly creates a new user for each request. The number of real users who have disabled saving to local storage is likely small, but bots and crawlers almost never utilize local storage. One user and/or bot with local storage disabled can drastically inflate your MAU count.

To learn more about MAU, read Account usage metrics.

Tracking anonymous users with a shared key

You do not always need to uniquely identify your anonymous users. Instead, you can use a shared key. You can still target users by their attributes, but you cannot target specific user segments unless they have unique keys.

If you are targeting anonymous users in percentage rollouts, you may want to assign variations by an attribute other than the shared key. Otherwise, all anonymous users are served the same variation. To learn more about variation assignments by attribute, read Percentage rollout logic.

Using a shared user key for all anonymous users instead of unique keys helps reduce your client-side MAU usage.

To learn more about user limits, read Understanding the Users dashboard.

Tracking anonymous users with unique keys

Sometimes it is useful to generate unique keys for anonymous users. We recommend using unique keys for the following reasons:

  • You are targeting users individually by key
  • You are using Experimentation to run A/B/n tests
  • You are using the Analytics Data Stream
  • You are conducting percentage rollouts

Understanding how unique keys contribute to user count

Your account is limited to 100,000,000 users by default. 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 users than you know.

Here are some examples of ways you may be creating unique user IDs:

  • Creating users that include request IDs, so each user generates a new ID every time they request against the server. Users do not need a user ID to use a request ID. For example, an unathenticated API might only give you a request ID, not a user ID.
  • Server-to-server communication where there are no human operators, just software components interacting.
  • If you use LaunchDarkly to configure log levels or tracing, you may use a different type of ID, like a timestamp. LaunchDarkly classifies each of those IDs as unique IDs.

You can replace some of the unique IDs in the examples above with anonymous users. This decreases your maximum user count, but keep in mind that anonymous users do not appear on the Users dashboard. Assess the components interacting with LaunchDarkly and feature flags to determine which require unique IDs, user IDs, or both, or can be classified as anonymous users.

You can remove users you don't need anymore with the LaunchDarkly API, or by clicking the Delete button on their user card. To learn more, read Removing a user.

Associating anonymous users with logged in users

This feature is not available in all SDKs

This section explains aliasing users, which is an optional feature in LaunchDarkly SDKs. This feature is not available in all LaunchDarkly SDKs. For a list of SDKs that support this feature, read Aliasing users. If you have questions, you can also contact Support.

In some cases, one person can be represented by multiple users in LaunchDarkly. If LaunchDarkly registers a person as an anonymous user, and that person later logs in to the application, LaunchDarkly registers them again as a logged-in user. This one person is now represented by two unique user keys.

You can associate these two user keys by configuring your SDK to send alias events. Alias events connect two user keys and register them as one event-sending entity.

If you use Data Export or Experimentation, alias events are useful because they make the data represented in destinations and experiment results easier to understand. Alias events enable Data Export destinations to correlate the two user keys referring to the same underlying user. They also enable experiments to recognize when impressions and conversions occurred for a user, even if the user key changed between the two events.

To learn more about configuring your SDK to send alias events, read Aliasing users.

mParticle events require additional configuration

If you use mParticle as a Data Export destination, you must configure it to receive alias events in the LaunchDarkly UI. mParticle requires this additional configuration step to register events correctly.

To learn more, read mParticle.