What Is a Feature Flag?

A feature flag turns a change on for a share of your visitors, and widens that share step by step. Turn off takes it back at once. Flags are for releasing things safely: a new checkout, a redesigned menu, a seasonal banner, a fix that has to go live now and be easy to take down.

A flag is not an experiment. It has no winner, no statistics page and no debrief. An experiment asks which of several variants does best. A flag asks whether a change is safe to give to everyone, and lets you get there in steps.

The two sides

Every flag has exactly two sides. Off is your site or your code as it is today. On is the change. The share of visitors who get On is the rollout, from 0% to 100%. Everyone outside the rollout gets Off.

Two kinds of flag

You choose how a flag runs when you create it, under How it runs, and the choice is fixed afterwards.

• Editor: "Change the site with the visual editor." On carries changes you make in the Pertento visual editor, applied to the visitors who get On. Use it for quick fixes, banners and seasonal changes: things that should go live now and be easy to take down. See Quick Fixes with Editor Flags.
• Code: "Your code asks for it, through the SDK, the browser or HTTP." Your own code reads the flag and branches on it. Use it to release features your developers built. See Reading a Feature Flag in the Browser and Reading a Feature Flag on Your Server.

The two kinds differ in a few ways that matter:

• Publishing without a rollout plan takes an editor flag live for everyone, at 100%, unless you set a rollout first. A code flag goes live at the rollout you gave it, which is 0% by default, so it ships dark until you widen it.
• A code flag can carry an optional JSON payload on each side, and can bucket visitors on a Visitor ID or a Customer ID. An editor flag has neither.
• A code flag can have server rules, which your server SDK checks. An editor flag cannot.
• A code flag always needs the website's visitor ID turned on. An editor flag needs it only when its plan has a guardrail step. See Anonymous Visitor ID.
• An editor flag that has been on for everyone for 30 days gets a reminder to build the change into the site. A code flag does not.

When to use a flag, and when an experiment

Use a flag when you already know what you want to ship and the question is how safely to ship it. A rollout plan with guardrail steps gives you a staged release that pauses itself if the change does worse than the page as it was.

Use an experiment when you do not know which version is better. An experiment splits traffic, runs statistics and ends with a winner. A flag never ends with a winner. It ends with everyone on On, or with the flag turned off.

If you want both, run the experiment first and release the winner behind a flag.

The words you will meet

The console uses one word for each thing, and the guides in this section use the same ones.

• Off and On: the two sides. Off is the site or the code as it is today. On is the change.
• Rollout: the share of visitors who get On, from 0% to 100%.
• Turn off: sends everyone to Off at once. It is the main action on a live flag.
• Plan: the list of steps the rollout moves through on its own. A step is one of them.
• Guardrail: the check that On does no worse than Off on the flag's primary goal.
• Ring: a group that always gets one side, decided before the rollout.
• Holdback: a share kept Off at every step, even at 100%.
• Flag key: the name your code asks for the flag by.
• Payload: optional JSON that comes with a side of a code flag.

Where to find flags

Feature flags have their own section in the sidebar, Feature flags, next to Experiments and Surveys. Its Library lists the website's flags with their status, a Search flags box that matches on name or key, and the Create flag button. Each flag has its own page with five tabs:

• Rollout: the rollout, the rollout plan with its holdback and guardrail margin, the guardrail card for a step that waits on it, and the schedule.
• Brief: the description and notes, and for editor flags the previews of Off and On from the visual editor.
• Targeting: targeting and conditions, server rules for code flags, and rings.
• Setup: for editor flags, the changes made in the editor. For code flags, the code snippets filled in with the flag's key and website, and the payloads. Both kinds set their primary goal here.
• Activity: every publish, rollout change, plan step and turn off, with who made it.

Each tab has its own product tour, which walks through the cards on it.

Who can do what

Flags use the same permissions as experiments. Creating a flag and editing its plan, rules and rings needs the permission to create experiments. Anything that changes what visitors see, which means publishing, changing the rollout, starting or pausing a plan, turning off and archiving, needs the permission to start experiments. In the default roles, Admins and Owners have both, and Members can look but not change. Deleting a draft is for Admins and Owners. See Roles and Permissions in Pertento.

What a flag costs

Flags count toward your plan's sessions in the same way experiments do. Visitors who get Off on a page the flag targets count too, because they are the comparison group, and a flag at 0% still counts the visitors on its pages. A website whose billing is inactive or capped serves no flags: everyone gets Off. See Plans, Sessions and Your Monthly Allowance.

Next

Creating and Publishing a Feature Flag walks through the dialog and what happens when you publish.