Skip to main content
Feature Flags
James Harber avatar
Written by James Harber
Updated over 11 months ago

There are two ways in which customers ask us to run their feature-flag / rollouts operation. This document describes our solutions & approach to each.

1. Full Experimentation

Some users require what they call feature-flagging, but want a full range of features including visitor segmentation, throttling, conversion tracking, etc.

We see this as no different to Server Side Testing – when users experiment through our API they’re often only returning a discrete value – 0 or 1, true or false, “control” or “variation” – to their server. This, by nature, is just a flag and so our regular server-side testing approach in this situation is more than sufficient here.

2. Rollouts – Decision Engine only

As of 2021, this approach has grown in popularity. IT teams want the ability to control straightforward things about their website – how often a feature shows, based on their internal environment – but not the full breadth of measurement and analysis that comes with this. Analytics tools can easily be fed the data and reporting done there.

For these users, we considered a novel experience – utilising our Google Sheets connector to power the Optimize Public API Service.

This works by providing our users with a Google Sheet where feature-flags can be configured with minimal effort. Changes are automatically captured by our data connector, fed into the Optimize Public API, and made available in seconds to read back. No lengthy delays, or 1-hour update cycles.

Over time, your spreadsheet will look somewhat like this:

  • Name: The name we give to your flag via. the API.

  • Dev: An on/off toggle as to whether or not this shows up in your dev/preproduction environment.

  • Prod: An on/off toggle as to whether or not this shows up in your live/production environment. This is coupled with a percentage exposure control.

  • Prod Throttle: What percentage of requests should yield an “in” response, specifically for the live/prod environment.

  • Value when enabled: If users fall in, what value should they see? Default value is “false”.

API access details will be made available to users who work with us.

Why Google Sheets?

We have been evaluating what we refer to as the “most accessible platform” for people with varied skillsets – some highly technical and experienced, some experienced but completely non-technical, and some brand-new to tech or experimentation.

Spreadsheets were identified as the key medium through which all users would feel comfortable, and as such we took the direction to “break out” of our UI, and instead allow users to control their websites from the most-accessible platform available – Google Sheets.

This should allow users to stop worrying about UI access, accidentally hurting other experiences, and focus purely on the task at hand, in an environment where it’s easy to hop in and out in under 15 seconds.

Did this answer your question?