Device & Browser
A feature flag is a setting in your code that you can turn on, off, or change without a new deploy. Device and browser conditions target a specific type of device, or a specific browser. Use them on an experiment, or on a feature flag rule. A design change can work differently on mobile than on desktop. A CSS fix might only need testing in one browser. Device and browser conditions handle both cases.
Device conditions
A vs B classifies every visitor into one of three device categories:
- Desktop: traditional computers and laptops with larger screens and mouse-based interaction.
- Mobile: smartphones and small-screen touch devices.
- Tablet: tablets such as iPad and Android tablets, which sit between mobile and desktop in screen size.
In the Audience Builder, add a condition of type Device and select one or more device types. You can use the Is operator to include a device type or Is Not to exclude it.
Browser conditions
Browser conditions let you target visitors using a specific web browser. A vs B recognizes six browser values:
- Chrome: Google Chrome and Chromium-based browsers
- Firefox: Mozilla Firefox
- Safari: Apple Safari (desktop and iOS)
- Edge: Microsoft Edge
- Opera: Opera browser
- Other: any browser that is not one of the five above, such as Samsung Internet or Brave
In the Audience Builder, add a condition of type Browser and select the browser you want to target.
How detection works
Device and browser conditions are always automatic: there is nothing to configure. But how they get detected depends on where the condition runs.
On a website: the A vs B snippet
The A vs B snippet detects device and browser at load time by reading navigator.userAgent, the string every browser sends that describes itself. It checks that string against known patterns for each browser and device category, and stores the result for the rest of the session.
This happens instantly when the snippet loads, before any experiments run. So device and browser conditions are evaluated with no extra delay.
User-agent strings can be spoofed. Some desktop browsers even let a person emulate a mobile user-agent on purpose. In practice, user-agent detection is accurate enough for the vast majority of real-world traffic.
In a Feature Flag project: browser SDKs match, server SDKs never do
Feature Flag audiences offer the same Device and Browser condition types. They detect the same way: automatically, from navigator.userAgent, with nothing for you to pass in. That works when a browser-based SDK evaluates the flag. For example, @avsbhq/browser or @avsbhq/react running in a visitor's tab.
A server has no browser and no user-agent string to read. Picture a server-side SDK evaluating the flag: @avsbhq/node, or any other server SDK. A Device or Browser condition always fails to match there, no matter what you pass into the evaluation call. The Audience Builder marks this for you. When you edit a Feature Flag audience, Device, Browser, Platform, and Language sit under a sidebar group labeled "Browser Conditions (client SDK only)".
Use a Custom Attribute condition instead, on the built-in deviceType, browser, or os attribute key. Your own code has to work out the value, usually by reading the request's User-Agent header. Then pass it yourself, in the evaluation context: the bundle of facts about the visitor your code hands to the SDK. See Attributes for how.
Common use cases
Mobile-specific experiments
Testing a redesigned mobile navigation? Add a Device condition of Mobile to your audience. Desktop visitors are then never shown the mobile layout, so nobody sees a design that was not built for their screen size.
Browser-specific fixes
Say you find a layout bug that only affects Safari. Add a Browser condition of Safari to your audience. Now you can test a CSS fix on Safari visitors only, before rolling it out to everyone.
Comparing desktop and mobile results
Run a single experiment on all visitors with no device targeting at all. Then use the Segment filter on the Results page to view results broken down by device type. This shows whether your change worked differently on mobile vs desktop, without running separate experiments.
Combining device and browser conditions gives you fine-grained control. An audience of Device = Mobile AND Browser = Safari targets iPhone users. That is a useful audience when you are testing a fix for an iOS Safari-specific issue.