• Can you schedule a flag?

    LaunchDarkly does not have a built in way to schedule a flag for a particular date, however this can be achieved with targeting rules. For example, you may want to serve true to show your feature, but only after November 19th, 2018.

    You can use the before/after operator to compare dates in your targeting rules. You'll simply need to include the current date as a custom attribute in your user object and then set up a targeting rule that evaluates to true if the date value in your user object is after the date specified in your targeting rule. Note that dates must be formatted in unix milliseconds for date comparisons. You can reference this in our documentation here

    Here's an example in JavaScript showing how to include the current date in unix milliseconds in your user object:

    var user = {
    "key": "67yx27g7fxl004483",
    "custom": {
    "current_date": new Date().getTime()

    And here's a screenshot showing how the targeting rule would look in the UI:

    This example user will evaluate to `true` because their current date attribute is after the date specified in the flag's targeting rules.

  • 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 support@launchdarkly.com 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