Exploring sample data

This topic explains the sample flags, metrics, segments, and context kinds that LaunchDarkly creates for new trial accounts. It also explains how to use them to learn what LaunchDarkly can do.

LaunchDarkly automatically creates a small set of connected sample objects in the default project when you create a new trial account. A new trial account otherwise starts empty, so the samples give you something to explore. The samples cover targeting, metrics, experiments, guarded rollouts, and prerequisites, without you having to know what to look for in advance.

Because the objects are already connected to each other, you can see how flags, metrics, segments, and context kinds work together before you install an SDK. Working examples are already visible in your project, so you can open one and see a complete, real configuration instead of reading a description. You can confirm LaunchDarkly supports a capability just by looking, without building a test case yourself. The sample data is ready to use, with nothing for you to install or configure.

If your team is onboarding several people at once, sample data gives everyone a shared reference for learning how flags, metrics, and rollouts fit together. Each person doesn’t have to discover that on their own.

Locate sample data

You can find sample data in the following places:

• Flags: Navigate to the Flags list. In a new trial account, every flag in your default project is a sample flag. If you’ve already created your own flags, click the Tags filter and select the ld-example tag to display only the samples.
• Segments and metrics: Browse the Segments and Metrics lists. A new trial account contains multiple sample metrics and a single sample segment.
• Context kinds: Navigate to Project settings and click Context kinds.

Context kinds, metrics, and flags are project-scoped, so they appear in your default project regardless of environment. The ld-example-beta-users segment exists only in the “Test” environment, so switch to “Test” before looking for it.

Every sample object carries the tag ld-example and follows a consistent naming pattern. This lets you identify a sample, even after you create your own flags, metrics, or segments in the same project. The naming pattern is LD Example followed by the object type and a descriptive name, for example LD Example Metric: Error Rate.

Edit sample objects

Each sample object’s description explains the concept in plain language, maps it to a realistic use case, and links to related objects. Where LaunchDarkly can’t link directly to a related object, the description tells you where to find it instead.

You can edit, rename, or duplicate any sample object. Duplicating a sample and building on it is a typical way to start your own work. The ld-example tag is informational only and doesn’t restrict what you can do with the object.

Remove sample data

After you build your own flags, metrics, and segments, you can remove the samples so your project contains only your own work.

To remove the samples:

1. Navigate to the Flags, Segments, or Metrics list.
2. Click the Tags filter and select “ld-example.”
3. Select the sample flags you want to remove, and delete them.

Repeat these steps for each list. The ld-example-beta-users segment exists only in the Test environment, so switch to Test before looking for it there.

Sample objects

Sample data includes the following context kinds, segment, metrics, and flags, grouped by object type.

Context kinds

• Organization, key ld-example-organization: Represents a company or account, letting you target flag variations by attributes like plan tier or company size instead of individual users. Use it when a feature should depend on who someone’s employer is, not who they are. Available for experiments and guarded rollouts.
• Device, key ld-example-device: Represents a physical device, so you can target flag variations by device attributes like platform, OS version, or device type, not the user. Use it when a feature depends on what hardware or app version someone is using, not who they are. Available for experiments and guarded rollouts.

Segment

• Beta Users, key ld-example-beta-users: Matches contexts where user.beta_program equals true. Grouping contexts into a segment means you can reuse this same rule across multiple flags instead of rebuilding it each time. Exists only in the Test environment.

Metrics

• Page Load Time, key ld-example-page-load-time: A numeric metric measured in milliseconds, where lower values are better. Wired to the New Search Release flag, so you can see how a metric attaches to a guarded rollout.
• Error Rate, key ld-example-error-rate: Tracks error rate as a percentage, where lower values are better. Also wired to the New Search Release flag, alongside Page Load Time, so a guarded rollout can watch more than one signal at the same time.
• Weekly Active Users Per Account, key ld-example-weekly-active-users-per-account: A numeric metric measured in users, where higher values are better. A common primary metric when you care about account-level engagement instead of individual clicks. This metric is often used as a primary metric in experiments testing account-level engagement changes.
• Support Tickets Per Account, key ld-example-support-tickets-per-account: A numeric metric measured in tickets, where lower values are better. A common guardrail metric. Pair it with an engagement metric like Weekly Active Users Per Account, to catch a change that boosts engagement but spikes support load.

Flags

• New Search Release, key ld-example-release-new-search: Ships configured for a guarded release, which gradually rolls out a feature to increasing percentages of users while monitoring for regressions. That way, a bad release only affects a small group before you catch it. Rolls out to 20% of contexts in Production and 100% of contexts in Test. The ld-example-page-load-time and ld-example-error-rate metrics are wired and ready to attach if you start a guarded rollout on this flag.
• Dashboard Layout, key ld-example-experiment-dashboard-layout: A multivariate flag that serves one of two dashboard layouts, classic or streamlined, so you can compare which performs better. Multivariate flags let you serve more than two variations, and are the foundation for experiments. Has a targeting rule based on the organization context kind, serving accounts on the enterprise plan.
• Premium Dashboard Access, key ld-example-feature-premium-dashboard: Demonstrates targeting rules, so you can restrict a feature to specific customers without shipping separate code paths for them. Serves the on variation to enterprise organizations and to users in the Beta Users segment. Everyone else sees the off variation.
• Third-Party Chat Kill Switch, key ld-example-kill-switch-third-party-chat: A boolean flag you flip off instantly when an issue occurs, so you can disable a failing integration within milliseconds, no deploy needed. On by default, which is the point of a kill switch.
• Maintenance Banner, key ld-example-ops-maintenance-banner: A multivariate flag with the variations None, Scheduled, and Active. Has a prerequisite on the Third-Party Chat Kill Switch flag, so the banner only evaluates while its dependency is healthy. If you turn that flag off, this banner flag stops evaluating.

Next steps

After you explore the sample data, install a LaunchDarkly SDK to start evaluating flags in your own application. To learn how, read Setting up an SDK.

The sample flags demonstrate concepts you can apply to your own flags:

• To learn more about guarded rollouts, read Guarded rollouts.
• To learn more about experiments, read Experimentation.