How do you target a feature to specific segments (region, plan tier, device) without hardcoding rules across services?

Controlling who sees what in production should be fast and precise—but never hardcoded into a dozen services you’ll regret touching later. The clean way to target by region, plan tier, or device is to centralize those rules in a runtime control layer and evaluate them via feature flags, not scatter them in if/else blocks across your codebase.

Quick Answer: Use LaunchDarkly feature flags with targeting rules and segments as your runtime control layer. You send context (region, plan tier, device, account, etc.) to LaunchDarkly via SDKs, and flags decide behavior at runtime—no redeploys required, no hardcoded logic in every service.

The Quick Overview

• What It Is: A centralized runtime control plane (via LaunchDarkly feature flags) that evaluates audience targeting rules for each request and returns the correct feature state, instead of baking those rules into application code.
• Who It Is For: Engineering, product, and experimentation teams that need to roll out features progressively, personalize behavior by segment, and stay in control when something breaks.
• Core Problem Solved: Eliminates hardcoded targeting logic and manual rollouts across services, reducing blast radius and making it trivial to change who gets what in production—instantly.

How It Works

At a high level, you define what you want to target (region, plan tier, device, account type, etc.) in LaunchDarkly, wire your app to pass those attributes via SDKs, and let LaunchDarkly evaluate flags at runtime. The rules live in one place; every service just asks, “Is this feature on for this context?” and gets an answer in milliseconds.

1. Model your targeting context once:
   Define the attributes that matter—country, plan, device, accountId, environment, or custom attributes like betaEligible—and send them to LaunchDarkly as part of your user or multi-context payload via 25+ native SDKs.

2. Centralize rules as feature flags and segments:
   In LaunchDarkly, you create flags (boolean or multivariate) and define rules like “Premium users in EU on mobile” using targeting, percent rollouts, and segments. These rules are editable in the UI, via API, or even Git—no code changes or redeploys required.

3. Evaluate at runtime in every service:
   Each service calls ldClient.variation("your-flag-key", context, defaultValue). LaunchDarkly evaluates the flag in <200ms globally and returns the correct value for that request. Update rules in LaunchDarkly, and behavior changes instantly across your stack.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Multi-dimensional targeting	Targets any cohort on any attribute (region, plan tier, device, environment, custom) with rule-based logic.	Avoids hardcoding complex if/else trees in every service; change targeting centrally instead.
Segments & percentage rollouts	Groups users into reusable segments and supports gradual percent-based rollouts.	Run safe, progressive delivery with limited blast radius and easy beta programs.
Guarded releases & kill switches	Monitors performance thresholds and lets you instantly disable features if something breaks—no redeploys required.	Recover from issues in production in seconds instead of shipping emergency hotfixes at 2am.

Ideal Use Cases

• Best for progressive rollouts by segment: Because it lets you ramp a feature from 1% to 100% for, say, “US Premium mobile users” with guardrails and rollback—without touching code.
• Best for entitlements and personalization: Because you can encode “who gets what” (plans, regions, device types, account states) as data in flags and segments instead of maintaining separate forks of logic or custom configuration systems.

How to Target by Region, Plan Tier, and Device (Without Hardcoding)

1. Send rich context, not just a user ID

Instead of just passing userId, send a full context object to LaunchDarkly via your SDK:

{
  "key": "user-123",
  "kind": "user",
  "country": "US",
  "plan": "premium",
  "device": "mobile",
  "appVersion": "5.4.0",
  "custom": {
    "betaEligible": true,
    "accountId": "acct-987"
  }
}

LaunchDarkly treats these attributes as queryable fields in your targeting rules. You can also target by non-user contexts—like account, device, or environment—using multi-contexts.

2. Define your feature flag once

Create a flag, e.g., new-checkout-experience:

• Type: Boolean (On/Off) or multivariate (e.g., variant_a, variant_b, control).
• Environments: dev, staging, prod, etc.
• Default: false in production until you’re ready to roll out.

3. Build targeting rules in LaunchDarkly (not in code)

In the LaunchDarkly UI (or via Terraform / API / Git), set up rules like:

• Region-based:

  • If country is in [US, CA, UK] → Serve true
  • Else → Serve false

• Plan tier-based:

  • If plan equals enterprise → Serve true
  • If plan equals premium → Serve true for 50% of users
  • Else (free or others) → Serve false

• Device-based:

  • If device equals mobile and appVersion ≥ 5.4.0 → Serve true
  • Else → Serve false

You can combine these into a single rule:

If country in [US, CA] AND plan in [premium, enterprise] AND device is mobile → 20% rollout

No code changes. No redeploys. You adjust the rules in LaunchDarkly, and the runtime decision changes everywhere.

4. Reuse segments instead of rewriting rules

Define segments like:

• early-access-users
• premium-mobile-eu
• high-value-accounts
• internal-staff

Segments can be:

• List-based: Explicitly include specific keys (e.g., internal emails, account IDs).
• Rule-based: “Any user where plan = premium and country = DE and betaEligible = true.”

Then your flag rules become simpler:

• If user is in segment premium-mobile-eu → 50% rollout
• If user is in segment internal-staff → 100% on (for dogfooding)
• Everyone else → Off

When segment membership changes, all flags referencing that segment automatically respect the new audience—without touching any service.

5. Evaluate flags in every service at runtime

In each service, the pattern is:

// Example in Node.js
const showNewCheckout = ldClient.variation(
  "new-checkout-experience",
  userContext,   // includes country, plan, device, etc.
  false          // default if flag not found
);

if (showNewCheckout) {
  // new behavior
} else {
  // old behavior
}

A few key properties:

• Runtime-only control: You deploy this code once. From then on, all changes are made in LaunchDarkly.
• Global speed: Flag changes propagate worldwide in under 200ms.
• Language-agnostic: Same pattern across microservices in different languages using 25+ native SDKs.

6. Progressive rollout with guardrails

Instead of a “big bang”:

1. Start with 1% of the premium-mobile-eu segment.
2. Monitor error rate, latency, or custom metrics via observability tooling.
3. Use Guarded Releases (thresholds + automated rollback) to auto-disable the flag if error rate exceeds a set threshold.
4. If stable, ramp to 5%, 25%, 50%, then 100%.

All of this happens after deploy, with no additional builds or rollouts.

Features & Benefits Breakdown (Deep Dive)

Core Feature	What It Does	Primary Benefit
Targeting & segmentation	Uses attributes like location, plan type, OS, device, or custom fields to define rules and segments.	Precisely controls who sees each feature, without littering services with targeting logic.
Progressive rollouts	Gradually ramps traffic with percentage rollouts, by segment or rule.	Limits blast radius, turns risky launches into controlled experiments.
Multi-environment controls	Different rules per environment (dev, staging, prod) with approvals and policies.	Safe testing and internal rollouts before exposing to customers.
Guarded releases & auto-rollback	Monitors error/latency thresholds and can pause or roll back automatically.	Prevents 2am fire drills by reverting bad releases without redeploys.
Audit logs & governance	Tracks who changed what, when, with policies and custom roles.	Gives SRE, security, and compliance teams confidence in runtime changes.

Limitations & Considerations

• You still need clean context modeling: LaunchDarkly can only target attributes you send. If your services don’t consistently pass plan, country, or device, you’ll need to invest a bit in standardizing context payloads.
• Flags need lifecycle management: Flags are powerful, but they can become technical debt if never cleaned up. LaunchDarkly helps with TTLs, usage tracking, and cleanup workflows, but you still need an internal practice around flag lifecycle.

Pricing & Plans

Pricing is based on the scale of your usage (MAUs, flags, environments, and capabilities like experimentation and AI Configs). Teams typically start with core feature management and grow into experimentation and AI governance as they standardize on LaunchDarkly as their runtime control plane.

• Team / Growth tiers: Best for product and engineering teams that need robust targeting, progressive rollouts, and kill switches to de-risk launches.
• Enterprise tier: Best for organizations needing advanced governance (custom roles, policies, audit logs), large-scale traffic, experimentation, and AI Configs with strict compliance requirements.

For current pricing and details, request a demo or talk to sales.

Frequently Asked Questions

How is this better than a custom “config service” I build myself?

Short Answer: LaunchDarkly gives you targeting, rollouts, governance, and global propagation out of the box—without maintaining another critical service.

Details:
A homegrown config service often starts simple (“we’ll just store a JSON with feature toggles”) but quickly hits hard edges:

• No built-in targeting language on attributes like plan, device, or country.
• No progressive rollouts or percentage-based targeting.
• No guarded releases or automatic rollback on error spikes.
• No audit logs, approvals, or policies for who can change what.
• You own uptime, scaling, SDKs, and global propagation.

LaunchDarkly is production-proven—99.99% uptime, 45T+ flag evaluations per day, <200ms global updates—so your team can focus on product, not reinventing runtime control.

Can non-developers safely change who gets a feature?

Short Answer: Yes. Product managers, growth teams, and ops can adjust targeting safely via UI or Git with guardrails.

Details:
Because targeting rules live outside the codebase, non-developers can:

• Create or update segments (e.g., “US premium paid users on iOS”).
• Adjust percent rollouts (10% → 25% → 50%).
• Turn features off using kill switches during incidents.

Approvals, custom roles, and policies ensure the right people can make changes, while audit logs track every modification. Engineering still owns the integration; business teams own the audience and timing.

Summary

If you’re still hardcoding “US-only,” “Premium-only,” or “mobile-only” logic across services, you’re carrying avoidable risk and slowing down releases. Centralizing feature targeting in LaunchDarkly gives you:

• Multi-dimensional targeting by region, plan tier, device, and any other attribute.
• Progressive rollouts and kill switches for safe, controlled releases.
• A runtime control plane that changes behavior after deploy, with <200ms propagation worldwide.

You move faster and reduce blast radius—without turning every change into another deploy.

Next Step

Get Started