Feature flags vs A/B tests
An A/B test measures the performance of experiences. A feature flag controls who receives a new feature, in which environment and at what rollout percentage. Testvoy connects these worlds so product and engineering teams can move between safe rollout and measured experimentation.
Development, staging and production environments
Staged rollout by percentage
Fast rollback with kill switch
Approval gates and audit trail
Environment-specific SDK keys
Safe rollout checklist
A flag should not be treated as only an on/off switch. New features ship more safely when rollout plan, measurement goal, owner, rollback criteria and audit history are clear upfront.
- Is the owner and approver clear?
- Is the SDK key correct in staging?
- Did rollout start with a small audience?
- Was the kill switch tested?
- Is a decision goal or health metric connected?
Implementation example
For Feature flag guide, the safest approach is to start with a small verifiable scenario, then validate the setting in Testvoy through QA and reporting. The example fields below clarify what to enter in a real project.
- 01
Choose the project
- 02
Create the setting or rule with a clear name
- 03
Enter an example URL/event/segment value
- 04
Verify with preview or verifier
- 05
Check the result in reporting
Name: Feature flag guide
Project: storefront-production
URL: /pricing
Goal: signup_completed
Audience: all visitorsPractical scenario
A growth team changes CTA copy on the pricing page, connects signup_started and signup_completed goals, then reads Google Ads and returning visitor segments separately. If the result is promising, they share a report link with the client or leadership.
Common mistakes
Most mistakes come from wrong project keys, overly broad selectors, missing goals, staging/prod mixups, early decisions on small samples or skipping mobile QA.
Naming an experiment 'test'
Launching without a goal
Deciding on total CVR only
Sending screenshots instead of shareable reports