Product Features

  • Setting up SSO via SAML 2.0

    LaunchDarkly supports the following SAML 2.0 identity providers:

    • Okta
    • OneLogin
    • Azure Active Directory
    • Google Apps
    • Active Directory Federation Services (ADFS)
    • PingIdentity
    • Centrify

    See our documentation for complete setup instructions as well as configuration tips for specific providers.

  • User Targeting

    LaunchDarkly targeting lets you turn features on or off for individual users or groups of users. You can use the Targeting tab to roll features out for internal testing, private betas, or usability tests before performing a broader rollout. You can create your own rules to target who you want, when you want.

    Learn more about targeting users in our documentation here.

  • Custom targeting rules

    In addition to targeting individual users, LaunchDarkly allows you to target segments of users by constructing custom rules.In other words, you can create custom rules to target users based on any attributes you send us.

    Each rule has three parts: an attribute, an operator, and a user value.   You can create as many custom targeting rules as you want for each feature flag and even perform percentage rollouts for each rule.

    All users that have not been individually targeted or who are not targeted by a custom rule will be evaluated by the default rule.

    Learn more

  • Flag management dashboard

    LaunchDarkly provides you with a centralized dashboard to manage the lifecycle of your features from local development, to QA, to production. Manage multiple different software projects with their own development environments.

  • Projects and environments to manage your development process

    Projects allow you to manage multiple different software projects under one LaunchDarkly account. For example, you can create one project called Mobile App and another project called Web App. Each project will have its own unique set of environments and feature flags. By default, all team members in your LaunchDarkly account will have access to every project within that account.

    Environments allow you to manage your feature flags throughout your entire development lifecycle — from local development to QA, staging, and production.

    When you first sign up, you're provided with two environments within a project. By default, they're named Test and Production. Each environment has its own private SDK key, which is used to connect a LaunchDarkly SDK to a specific environment.

    Each feature flag that you create has its own unique set of targeting rules for each environment. This means that you can change your flag rollout rules in a development or staging environment for QA testing before rolling out to production.

  • Dev console to see real-time feature flag events

    The dev console helps you test whether you've set up LaunchDarkly correctly. From the console, you can see your users' feature flag requests and events in real-time.

    You can access the dev console from the sidebar. The filter buttons allow you to isolate specific events (like clicks or pageviews) or pinpoint errors and warnings, which represent problems with the data being sent to LaunchDarkly.

    The dev console must be the active tab in its browser window. You can have a second window open with your application, if you need to click around in your app in order to generate events.

    Please note that in high-volume environments, the events sent to the dev console may be sampled. When this happens, you will see a subset of events on the dev console, instead of every event.

    Read more about the dev console in our documentation.

See all 11 articles

Use Cases

  • Is it required to use a unique key for anonymous users?

    Anonymous users work just like regular users, except these users are not stored in your dashboard. One of the primary reasons that users are sent anonymously is to avoid having a lot of unauthenticated users polluting the user dashboard. Another reason is to avoid sending PII, but we recommend the use of private user attributes if that is the case. 

    There are some cases where you do need to generate a unique key for anonymous users. If you are targeting users individually by key, using LaunchDarkly's A/B testing feature, or the Analytics Data Stream you would want unique keys. You also want unique keys when conducting percentage rollouts. For that reason, the general documented advice is to treat the anonymous users like regular users and assign unique IDs. 

    If you do not have a need to uniquely identify your anonymous users, you could use a shared key for these users.

  • How are A/B Test Results Calculated?

    When a conversion event comes in, we try to find the 'closest' feature event. To do this, we look for the latest feature event for this user in the 24 hours preceding the conversion event. (Failing that, we will look for the earliest feature event for that user in the 5 minutes following the conversion event, to allow for clock skew). Once we find a feature event, we look at which variation that user saw, and we add the user to the set of users who saw that variation and converted.

    So, suppose the following timeline:

    t0: user X sees variation A
    t1: user X sees variation B
    t2: user X triggers a conversion event

    As long as there is less than 24 hours between t2 and t1, user X will be added to the variation B conversion set (and *not* the variation A conversion set).

    In this same timeline, but when there is more than 24 hours between t2 and t1, we will not find a feature event, so the conversion will not count at all.

    Suppose an alternate timeline:

    t0: user Y sees variation A
    t1: user Y triggers a conversion event
    t2: user Y sees variation B
    t3: user Y triggers a conversion event

    If there is less than 24 hours between t1 and t0 AND less than 24 hours between t3 and t2, then user Y will be counted in both the variation A conversion set *and* the variation B conversion set. 

    Now, suppose a third timeline:

    t0: user Z sees variation A
    t1: user Z triggers a conversion event
    t2: user Z sees variation A
    t3: user Z triggers a conversion event

    If there is less than 24 hours between t1 and t0 AND less than 24 hours between t3 and t2, then user Z will be counted *once* in the variation A conversion set.

    Keep in mind that the important time limit here is 24 hours. If someone converts 5 days (or 2 days) after (or 2 days) getting a variation, they will not be counted.

    Contact us at if you have any additional questions.

  • Feature Flag Driven Development

    Feature flags/toggles/controls harness the power of test-driven development (TDD).   This is the process of releasing and iterating features quickly, testing those features, and making improvements.  Think of it as Lean UX methodology.  You release light features to receive market feedback.  You iterate on that feedback, make improvements, and redeploy.

    Think of feature flag-driven development as a way to receive iterative market feedback on your product, rather than solely depend on isolated customer feedback.  It’s a way to test how your features perform in the real world and not just in an artificial test environment.

    Read the full article

  • Creating a feedback loop with LaunchDarkly
    Customers use LaunchDarkly to deploy a new feature to a small subset of their users. The platforms lets you easily segment users. For example, you can:


    • Rollout to a percentage of total users
    • Create a beta group of hand-picked users
    • Give early access to a single VIP customer
    • Dogfood to internal users only
    • Create an “opt-in” allowing users to self-select to see new features
    Once you’ve rolled out the feature to a group, measure it to see if the feature has impacted behavior as you expected and use that feedback to inform your path. Fix issues and make changes as necessary then continue to rollout incrementally to the entire base.
  • Empowering team collaboration and non-technical users
    LaunchDarkly allows teams to develop software in a way that’s fundamentally healthier, removing friction from the Product and Engineering relationship. The results are a dramatic savings in time and focus as well as faster delivery with greater trust.
    Empowered product development means that both technical and non-technical team members can collaborate on software releases. Because feature rollout will be decoupled from code deployment, team members outside of Engineering would be able to control the visibility of particular features without compromising the app’s integrity. Product and QA teams are empowered to make changes to feature visibility without consuming engineering resources.
    LaunchDarkly offers end to end feature flag management to allow an entire product development organization to control who gets the right feature, when.
    • Facilitate coordination between Engineering and Product, allowing you to break up larger features into smaller deployments and release features faster to select customers
    • Give control to the Product team, taking the burden of re-deploying off of engineering
    • Reduce friction between teams, cultivating a healthier and more productive relationship
  • A/B Testing with feature flags

    LaunchDarkly lets you create goals to measure the effectiveness of a feature. You can track click goals, page view goals, or create custom goals. We also provide an Optimizely integration so you can import your existing goals. We track all user events and let you see exactly how a feature is performing. Our analytics dashboard will help you see which feature variations are performing the best.

    Read more