Tag: EN

Article

Mar 4, 2021

15min read

Feature Toggles: Types & Best Practices

Anthony Brebion

Feature toggles are among the most powerful methods to support continuous integration and continuous delivery (CI/CD). Feature toggles —sometimes called feature flags— are a method for modifying features at runtime without modifying code.

Developers can create feature toggles by coding a “decision point” where the system runs a given feature depending on whether specified conditions are met. In other words, feature toggles allow you to quickly and efficiently deliver context-sensitive software.

Feature toggles have a wide range of possible applications for everything from supporting agile development, to market testing, to streamlining ongoing operations. However, with this power comes the potential for introducing unnecessary complexity into your code. You need to properly manage feature toggles to get the most from them.

In this article, we’ll give you an overview of precisely what feature toggles can do, how you can implement them in your development and production environments, and share some of our own recommended best practices for using them.

[toc]

What exactly is a feature toggle?

In the simplest possible case, a feature toggle is a powerful “if” statement, from which at least one of two different codepaths is followed at runtime depending on a condition or conditions provided. Here is a straightforward example:


normalFeature = {
  'id': 1,
  'description': 'basic service',
  'newstuff': False
}
testFeature = {
  'id': 2,
  'description': 'much better service',
  'newstuff': True
}
@app.route('/ourapp/api/v1.1/storefront', methods=['GET'])
def get_tasks():
if internalTester == True:
return jsonify({'feature': testFeature})
else:
return jsonify({'feature': normalFeature})

In this Python code sample, we have defined two different, generic features: normalFeature and testFeature. At runtime, the application checks in configuration to see whether an internal test user is loading it. If so, the application loads the test feature under development. If not, the regular customer sees the current feature.

To see how to code flags in specific programming languages, read for instance: “How to set up feature flags in a React js app”.

Feature toggles testing — Example of a feature toggle controlling two codepaths (Source)

Feature toggles can be anything from a simple “if” statement to complex decision trees, which act upon many different variables. A wide variety of conditions, including fitness test results from other features in the codebase, a setting in feature management software, or a variable provided by a config file, can be used to determine which way a toggle flips.

Different feature toggles for different tasks

You should manage feature toggles differently depending on how you deploy them. One useful way to think about toggles is to break them down into categories across two dimensions: their longevity in your development and operational processes and how dynamic their function is. Considered this way, we can break feature toggles out into four different categories:

Release toggles
Experimental toggles
Operational toggles
Permission toggles

Chart four feature toggle categories — A chart of the four feature toggle categories (Source)

Release toggles

These toggles support dev teams as they write new features. Instead of creating a branch where the team will write the new feature, they generate a release toggle in the master codebase that leaves their code inactive while they work on it. They can still push that trunk code to production to meet delivery targets.

Release toggles usually aren’t meant to be permanent fixtures in your codebase. You should remove them once their associated feature is complete. In practice, this usually means they have a lifecycle of a few days to a few weeks, which puts them lower on the longevity scale. Release toggles also tend not to be very dynamic. Either the feature is ready for release, or it isn’t.

Release toggle example

An e-commerce company has a new configurator tool in development at the request of one high-profile customer. The configurator monitors items the customer has already selected for a built-out and suggests item sets to complete their order.

The company eventually wants to roll out that feature to all customers, but for now, the configurator only works within that one customer’s specifications. The configurator’s dev team enables a release toggle for this new feature that keeps it inactive.

Experiment toggles

These toggles are used to facilitate A/B testing or multivariable testing. You create a toggle point beyond which the different features you want to test are down two or more different code paths. At runtime, the system —or the toggle itself— splits users into different cohorts and exposes them to the different features.

Tracking aggregate experience data for each cohort will allow you to compare these different features’ effects. Experiment toggles are popular methods for optimizing marketing efforts, user experiences, and other user-facing features.

Usually, experiment toggles should only exist as long as data needs to be gathered for feature testing. The exact timeframe will depend on traffic volume to that feature, but typically that means on the order of several weeks to several months. This constraint is more about the test itself than the toggle. The value of the data collected will diminish over time as other feature and code updates invalidate comparisons to earlier gathered user data.

Experiment toggle example

Our e-commerce company has finished debugging its new configurator, but there is some debate over which of the two suggestion algorithms provides the best experience. They decide to set up an A/B test to get some real-world data.

They add an experiment toggle to the production configurator with the two different suggestion algorithms behind it. The toggle splits users into two cohorts with a modulo when they try loading the configurator. After three weeks, the team feels they have conclusive data showing more users complete their orders using the B algorithm. The e-commerce company removes the experiment toggle, and that algorithm goes live for all users.

Operational toggles

Operational (Ops) toggles are used to turn features off —like a “kill switch“— or otherwise adjust their performance. For example, if certain conditions are not met, such as KPI targets dipping below a threshold, the toggle turns that feature off until conditions improve. Operational toggles are useful to code in front of new features just out of testing or in front of resource-intensive features.

The longevity of ops toggles varies depending on their specific use case. If you’re using one to regulate a new feature just out of development, you probably only need the toggle in place for a couple of months. On the other hand, a kill switch toggle is usually designed to be a permanent code fixture. Ops toggles usually are as static or dynamic as the conditions under which the feature they control will operate. For example, ops toggles tied to just one performance metric tend to be relatively static.

Operational toggle example

Our e-commerce company is preparing for a spike in traffic ahead of their popular annual sale. This will be the first such sale with the configurator in production. During testing, devs noticed the user-preferred B algorithm was a little greedy with system resources.

The operators ask for a kill switch to be coded for the configurator before the sale goes live. They just want a single toggle they need to click in their release management software should performance degrade. Lo and behold, on the first day of the sale, the configurator begins to degrade performance, and ops staff quickly kill it before too many users notice.

Permission toggles

Permission toggles are intended to be longer-lived or even permanent fixtures in your code. They are used as a method to make features available to specific subsets of users. For example, you might use a permission toggle to show premium content only to premium users logged into your site. Permission toggles tend to be the most dynamic of the four categories defined here, as they usually trigger on a per-user basis.

Permission toggle example

The simple example at the beginning of this article is close to what a permission toggle might look like. After the annual sale is complete, our e-commerce company decides algorithm B is too resource-intensive to make it available to their entire user population. Instead, they decide to make it a premium feature.

Feature toggles vs. feature flags

As a brief aside, there is some debate over the name feature toggle as opposed to feature flag. “Toggle” is a more appropriate name when code is turned on or off for a few major code branches. “Flag” is a more appropriate term if a decision point is followed by a very multi-conditional or broad set of codepaths.

Including feature toggles in your roadmap supports agile workflows

Applying feature toggles to your development process supports newer agile approaches. You can release software even while code sprints on new features are still in progress. Those features just need to be hidden behind toggles until they’re ready for release, market testing, or whatever the next stage in their development is.

You would usually write the user’s newly requested features on code branches under more traditional waterfall development models. Those features would then go through a lengthy testing and QA process before your team could integrate them back into trunk code. Using feature toggles, you can perform the entire development and testing process right on trunk code.

Our best practices for using feature toggles

As we’ve discussed, feature toggles are a powerful and flexible development method. If you don’t carefully implement and manage your toggles, they can quickly lead to a messy codebase or increased technical debt.

Many different best practices for coding feature toggles have been proposed, but we wanted to offer some of our own. Once one messy decision point is written into your codebase, many more seem to follow. Applying these best practices from the start will help keep problems like that in check.

Use feature toggles to gradually transition to agile development

If your team wants to try out agile development and testing methodologies without jumping entirely into a new development methodology, then introducing feature toggles into your roadmap is an excellent place to start. The cost to try them out is low. You could just have one team try using an experimental toggle for a single canary deployment they’re working on, for example.

If the trial goes well, you can replace that experimental toggle with an ops toggle when the feature goes into production. Then expand toggle use to other teams or other processes from there. Introduce them earlier in development cycles as release toggles. Then, slowly but surely, you’ll be on your way to full agile development.

Use toggles for both internal and external features

As should be clear by now, feature toggles have uses throughout the development and production lifecycle of your software. Don’t limit your toggle usage to just customer-visible features. You can use release and operational toggles to manage backend features too. They give DevOps teams a very granular level of control and risk management over code, which can be important when modifying backend features that have a wide-ranging impact on how your system performs.

Include toggle planning in your design phase

Everything from toggle naming, configuration settings, removal processes, and access control trickles down from how you first feature design new features. Build that toggle planning into your design process, and feature management six months from now will be greatly simplified.

Have a standardized toggle naming scheme

Many organizations use a style guide to regulate how developers write and organize code. For example, how they employ everything from spacing, ordering, and parentheses, to naming. If you’re going to use feature toggles, you should also standardize your naming style early in your toggle adoption process.

Brevity is essential in other aspects of coding, but when it comes to toggle names, be verbose. Detail means clarity. Verbose toggle names help devs and ops staff outside your core understand what they’re looking at when their only reference is the toggle name you chose on a whim six months ago.

Some other toggle naming conventions we suggest adopting include:

Include the team or the project name.
Include the toggle’s creation date.
Identify the flag’s category.
Be descriptive of the toggle’s actual behavior.

Here is an example: algteam_10-12-2021_Ops_configurator-killswitch

This name gives some useful information someone on any team can use to understand what they’re looking at when a toggle is called in an error message. They know who wrote the toggle, how long it has been sitting in the codebase, and what the toggle does.

Keep reading: Best practices to name your feature flags.

Manage different toggles differently

This practice sounds self-evident, but it is an important point to underline. As we discussed above, feature toggles can be divided into four general categories. You should manage each of those four categories differently.

Think about our configurator example from earlier as it moved from development to market testing to operational management. The configurator code sat behind a feature toggle of one kind or another the entire time. But the way the development and product teams interact with that toggle needs to change at every stage.

During early development, the toggle might just be configured in source control. Then while the e-commerce company is doing A/B testing, the toggle might be in a feature management platform. When the ops team adds a kill switch, they may decide they want it in the same feature management platform but on a different dashboard.

Always expose feature toggle configurations

As with any other code object, it is beneficial to document feature toggle configurations as metadata, so other developers, testers, and production staff have a “paper trail” they can follow to understand precisely how your feature toggle runs in a given environment. Ideally, store your toggle configurations in a human-readable format so that it is easy for people outside your team to understand what a toggle does.

This best practice is beneficial for features you expect to be toggled for a long time. Think about our configurator example again. A brand new product operator trying to understand a sudden, unexpected performance slowdown will be very grateful to have a human-readable file explaining that the B algorithm was surprisingly resource-intensive in testing a year earlier.

Keep the holding costs of feature toggles in check

When first using feature toggles, try to resist the temptation to use them everywhere in your code all at once. While feature toggles are easy to create, their use requires proper management and testing to realize any benefit. Scale up your feature toggle usage slowly, or consider integrating a feature management platform into your development and testing environments.

Deploy feature toggles strategically and keep your inventory of toggles as low as possible. Use them wherever necessary, but make sure there is a process for vetting whether toggles are the appropriate method for solving a particular problem.

Don’t let old toggles hang around in your code. Prune them as soon as their lifecycle has run its course. The more idle toggles your code has, the greater the management overhead that falls on your team. You can manage toggle removal by adding code cleanup tasks to your team’s backlog or building the process into your management platform.

Keep toggle scope as small as possible

Since toggling can be so powerful, it is often tempting to put large swaths of code under the control of a complex series of toggles. Resist this urge and keep feature toggling within as small a scope as possible to complete any given task.

If a toggle overlaps more than one feature at a time, it can be confusing for the rest of your team and a nightmare to debug weeks or months down the road when it begins to impact other teams’ work.

Consider our configurator example again. Our dev team is building four separate widgets that users will manipulate within the configurator tool. In this scenario, we would recommend setting up five toggles: one for the configurator itself and one for each widget. Code the widget toggles with a dependency on the configurator toggle. In this framework, if one of the widgets fails to load correctly, the others will still be served to the user.

Feature toggles can transform your entire development process

Feature toggles are powerful methods for developing, testing, and operating code features within a continuous integration and continuous delivery framework. They are a simple method that helps your team deliver higher quality, more stable code according to agile principles.

In this article, we walked through how feature toggles work, what types of toggles you can create, and how you can employ them in your agile process — or try them out in any development process. We also shared some of our recommended best practices for making sure your company gets the most from using feature toggles.

Start small and scale up

There is no reason you can’t start using feature toggles today. Start small and scale up your usage as your team gets comfortable with how they work. If you’re starting to code a brand new feature from your backlog, consider setting up a release toggle in trunk code, so you don’t have to branch. If you’re beginning market testing, consider setting up an experiment toggle for some split testing.

Once your team has a good handle on how they want to use feature toggles, consider whether a feature management platform can streamline their administration. Streamlining development and testing was what we had in mind when we developed our release and feature management platform.

AB Tasty allows your team to use a single tool to streamline toggle workflows and communication. Regardless of a team’s tasks or focus, our feature management product has everything it takes to deliver the right features in the right way.

You might also like...

See all

Article

6min read

A New Era for Product Recommendations: AB Tasty’s Semantic Proximity Algorithm

Emily Healy

Sep 15, 2025

Article

5min read

Why AB Tasty is the Best Digital Optimization Partner for Your Team

Emily Healy

Sep 10, 2025

Article

5min read

Luxury’s Secret Weapon | Anaïs Levy

Maddie Ostrander

Sep 8, 2025

Subscribe to
our Newsletter

Article

Feb 23, 2021

8min read

What Does Feature Rollback Mean and How To Do It

AB Tasty

When it comes to feature testing, you’re in a bind.

On the one hand, you need real-world data and feedback from real-world users. You know that every new feature you develop is, at best, an educated guess about what your real-world users want from you. No matter how educated that guess might be, and no matter much internal validation you perform, you can only generate meaningful data and feedback on each new feature you develop by releasing it to real-world users to test out in their real-world environments.

On the other hand, it’s risky to give real-world users an unproven feature. You know that every new feature you release might have something wrong with it. Maybe there’s a technical issue you missed during development. Maybe it just doesn’t align to user expectations as closely as you hoped. No matter the issue, releasing an unproven feature can cause real harm to your brand’s user relationships.

This is a tricky problem and one that is never going to be fully solved. But, thankfully, there are methods you can follow to minimize the problem, and collect real-world data and feedback while mitigating the impact when something (inevitably) goes wrong.

In this piece, we’ll explore one of these methods— rollbacks.

What is a Feature Rollback?

It’s a simple practice, with powerful implications.

When you perform a rollback, you take some code out of a live environment. Back in the day rollbacks could be truly massive. Software products used to be updated in giant new releases that could include a wide range of changes— including multiple new features and significant changes to existing features. If one of these huge releases had some fatal bugs in it, or just wasn’t well-received by users, then the entire thing might need to be rolled back (even if the issues were contained within just a few elements of the release).

All of this has changed with the adoption of Agile methodology. Releases keep getting smaller and more incremental, and so do rollbacks. Most modern Product Managers have adopted phased release plans, where they only release a single new or upgraded feature at a time— and often only to individual segments. And when modern Product Managers do release multiple new or upgraded features at once, the different features are separate from each other.

This evolution has changed the way rollbacks happen. After a new release, Product Managers can now isolate the individual feature(s) that have proven unfit for live usage and perform a targeted rollback on them, and them alone. The whole rollback process is now much faster, much nimbler, much more precise— and delivers much greater benefits.

Why Should Product Managers Perform Rollbacks?

When a Product Manager properly structures and deploys rollbacks, they improve their ability to test new features in a real-world environment with real-world users with a minimal level of risk. An imperfect feature is no longer the end of the world. If a feature has development issues or poor alignment with user requirements, you can perform a rollback and remove it from a live environment in real-time with just one click.

For Product Managers, this changes the game. The more mature your rollback capability, the more you can afford to make mistakes. Your risk shrinks, giving you the freedom to test more features with more users earlier in the development cycle, ultimately leading you to iterate your products faster and faster.

Now, rollbacks are not a silver bullet. They don’t absolve you from doing everything you can to develop the highest-quality features possible before you test them. But rollbacks allow you to test new features with greater confidence and reduced concerns about creating problems for your users.

When Should You Perform a Rollback? Two Common Use Cases

For most Product Managers, there are two common use cases why you might need to perform a rollback.

Rollback Use Case 1: Your Feature has a Bug

This first use case is pretty self-explanatory.

You might have the most robust and thorough QA and testing processes in the world. It’s still highly likely your new features will still have one or more bugs in them when you release them into a live environment. Maybe they’re issues you just didn’t think to search for or didn’t know how to search. Maybe they’re issues that only show up in live environment after hundreds of real-world users tool around with the feature.

Regardless of the reason, if significant technical issues pop up in your new feature, then you’ll likely want to perform a rollback on that feature to fix it. With the right rollback process, you can react to these errors in near-real-time and remove the feature—and maybe even fix it—in minutes before it impacts too many users.

Rollback Use Case 2: Your Feature is Poorly Received

This second use case is a little more sophisticated.

Essentially, after you release a new feature you monitor how users respond to it, and how well it’s hitting your business KPIs. If your new feature is not performing as expected, and is generating negative usage data and user feedback, then you can perform a rollback to remove it from its live environment. If it isn’t hitting—or at least tracking towards—its business goals, then it might not be worth keeping live.

After you roll back your feature, you can either utilize the data and feedback you collected to fix the feature and help it better align to user expectations and business requirements, or you can decide that the feature was fundamentally misguided and just needs to be retired.

With the right rollback process, you can also review and respond to the usage data and user feedback you receive in near-real-time, and prevent too many users from getting too disgruntled about receiving a feature that misses the mark.

What Do These Two Use Cases Have in Common?

In one word: speed.

In both use cases, rollbacks are most effective—and mitigate the most risk—when you are able to first monitor feature performance in real-time, to then translate that performance into a quick “yes/no” decision to rollback (or not), and finally to execute on that rollback decision as rapidly as possible.

The faster you can go through this entire process, the lower the chance that you will create a prolonged negative user experience. In some scenarios, the decision to perform a rollback and the execution of that rollback need to happen in minutes.

It’s a daunting mandate, but here are a few tips to help you meet it.

How to Make Faster Rollback Decisions

It’s challenging to decide—in the moment—whether or not to rollback a feature. Even the best feature release can be complex and chaotic.

There are multiple moving parts to monitor…

There are many different data and feedback points to take into consideration…

And there’s a lot of emotion at play…

You and your team just spent weeks, maybe even months, pouring your blood, sweat, and tears into designing and developing the new feature that you’re testing. If your users love it, then you get that sugar high of knowing you just completed a job well done, and you can just sit back and watch the good data and feedback roll in. But if your users don’t immediately respond as positively as you hoped, then it’s easy to experience an emotional crash and to want to rollback the feature before you even know if the bad response is consistent, let alone what you should do to fix your errors in the next iteration.

For these reasons, and many more, it’s hard to make the right rollback decision in the moment during a feature release test. Instead, it’s better to make your rollback decisions before you release your new features into the wild.

Here’s what we mean.

Basically, before you release any new features to any real-world users, you first decide what success and failure looks like for this feature in objective, data-driven terms.

Then, you decide how much data your release will need to generate before you can make an accurate call about whether the feature is a success or a failure.

Finally, you use these parameters during your release to make objective “yes/no” decisions about whether or not you should rollback your feature at any point. Instead of getting caught up in the moment, you just monitor the performance metrics that you decided were most important, and once they hit the thresholds you set prior to release you simply follow the plan and you either rollback the feature or you don’t— no real-time agonizing required.

How to Execute Rollbacks Faster

In the past, it was near-impossible to perform a rollback quickly from a technical perspective. You needed to have a technical team standing by, waiting to dig into the code to turn off live features, or to revert to a prior state of the entire platform. The entire process was slow, it was labor-intensive, and it took your technical teams away from their valuable development work.

Software has solved all of these problems. With our own feature management platform, you can rollback a feature in real-time by just toggling a single field with just one click. You don’t need any technical expertise to do so. You don’t need to develop and test a complex rollback process prior to feature release. You don’t even need to think about the technical details— you can save all of that thinking to create the right strategic decision trees that we outlined in the prior section.

AB Tasty also gives you—or any non-technical user—the ability to perform sophisticated feature releases and rollbacks. You can release multiple features at once, monitor how each feature is performing individually, and only rollback the features that aren’t delivering. You can roll out a feature to multiple user segments and only rollback that feature to the individual segments that aren’t responding well to it. We designed our server-side solution to make the execution of rollbacks faster, easier, and far more intuitive than they ever were before.

You might also like...

See all

Article

6min read

A New Era for Product Recommendations: AB Tasty’s Semantic Proximity Algorithm

Emily Healy

Sep 15, 2025

Article

5min read

Why AB Tasty is the Best Digital Optimization Partner for Your Team

Emily Healy

Sep 10, 2025

Article

5min read

Luxury’s Secret Weapon | Anaïs Levy

Maddie Ostrander

Sep 8, 2025

Subscribe to
our Newsletter

Article

Feb 12, 2021

5min read

How Continuous Development Turns Product Managers into Experimenters

AB Tasty

20 years ago, tech companies were hit with the ‘Agile Revolution’. The idea? Shipping working software every week or two would help teams deliver better products, even if this method implied more risk. In other words, the ‘move fast and break things’ mentality reigned.

But that was two decades ago. Today, agile is mainstream, and new philosophies, building on the agile movement, have come to the fore; namely, Continuous Integration, Delivery and Deployment, largely geared towards DevOps teams. Their big draw is that these processes and tools automate quality assessment, assuring that when code is merged in piecemeal fashion – and not on one big bang release day – it works. Even better, software can be deployed to the product environment at any time, by anyone. Now, your product manager can take the reins.

Today, the market is ready to go a step further. From Agile to Continuous Integration, Delivery and Deployment comes a thirst for Continuous Development. Continuous Development – we could even call it Continuous Activation – encompasses all of these ideas, but takes the logical next step. It puts even more control and autonomy in the hands of Product Managers. It allows them to not only deploy software themselves, (with mitigated risk), but also to pick and choose according to their own prerogatives which audiences are exposed to a given feature. In other words, they can run experiments, personalize the user experience, and exercise complete rollback control based on real-time data.

Continuous Development platforms and processes transform the Product Manager into a Chief Experimentation Officer, and there are many reasons to embrace this new paradigm shift:

Move Fast, Risk Less

‘Move fast and break things’ only works if you’re willing to accept the consequences of what you’ve broken. Most software developers would still like to move fast, but without the risk.

Continuous Development and the tools that support it factor in risk assessment. By avoiding code merges on one big release day, and by enabling progressive rollout techniques (canary deployment, ring deployment), developers can avoid putting all of their metaphorical eggs in one basket. If your system has a feature flagging or rollback KPI embedded in the platform, switching off a defective or negative feature can be done instantaneously and painlessly.

Your Customers, Not Your HIPPOs, Decide

How do decisions get made in your tech company? Chances are, HIPPOs, new bosses, vocal salespeople, consulting groups or the noisiest Product Manager in the room dominate that discussion, letting their personal experience, gut feeling or intuition determine the road map.

With Continuous Development platforms, the focus shifts from subjective ideas to customer feedback and data. Early adopter programs, beta testing, progressive deployment, A/B tests… all of these methods, enabled by feature flagging and other Continuous Development techniques, make your main measurement of success the behavior and opinions of your customers.

In a B2B context, this might look like extensive interviews with early adopters. In B2C, it’s likely your support teams or community manager who will pick up on positive or negative feedback around a new feature launch. Either way, Product Managers get direct access to the Voice of the Customer and can form data-driven arguments for why to rollback, stick with or modify a new feature.

Get off the Ford Line

If your team is project-driven, chances are your Product Managers and developers feel they need to keep their heads down and noses to the grindstone, working on their piece of the software production puzzle. They might be productive, they might be agile, but they might also not really feel the business impact of what they’re working on 40+ hours of the week.

When you can experiment with and test the features you’re developing; when you can get direct user feedback and adjust your work accordingly; when you have clear, measurable KPIs that determine success, your work all of a sudden feels a lot more meaningful. This keeps teams motivated, fresh and loyal.

Marketing and Product Manager Alignment

When you give your Product Managers more control, it’s easier for them to align with the teams around them, especially the Marketing and Communication departments. A new feature release, especially depending on the size and importance of your company, can mean a big web of marketing and communications campaigns. Emailings, press releases, articles, social network posting, corporate website updates…retroplannings and shifting deadlines are much easier to manage when your Product Managers are in the driver’s seat and not beholden to developer teams that have other priorities and are even more far removed from your marketing and communications personnel.

Developers Focus on Core Business Objectives

If you have a robust developer team, there’s a chance you could set up these types of feature management systems in-house, without the need for a dedicated platform. But this is time-consuming, and one could argue that it diverts skills and resources away from your core business objectives.

I believe that the time is now for Continuous Development. By turning our Product Managers into Experimenters, we’re able to build a better product and bring it to market faster, with less risk; we continue in the vein of ‘customer obsession’; we keep our teams creative and motivated; and we generally build up what, at AB Tasty, we’ve been advocating for since our founding – a test and learn, experimentation culture.

You might also like...

See all

Article

6min read

A New Era for Product Recommendations: AB Tasty’s Semantic Proximity Algorithm

Emily Healy

Sep 15, 2025

Article

5min read

Why AB Tasty is the Best Digital Optimization Partner for Your Team

Emily Healy

Sep 10, 2025

Article

5min read

Luxury’s Secret Weapon | Anaïs Levy

Maddie Ostrander

Sep 8, 2025

Subscribe to
our Newsletter

Article

Feb 9, 2021

10min read

Use Case User Onboarding: What Impact Do Release Teams Have on UX?

AB Tasty

According to a PWC survey, one in three customers would leave a brand after just one bad experience. Hence, your company may invest a lot of time and money optimizing your digital product to stay relevant in today’s often crammed markets.

A critical part of the overall product experience is user onboarding: get it right and win loyal customers, but get it wrong and lose those users forever.

So it makes sense to continuously tweak the user onboarding process – the perfect job for a product team. Such a team often consists of 5 to 8 people, including product managers, designers, and developers. Different companies work with various product team sizes and configurations – whatever is best for their use case. However, we rarely see DevOps engineers in these teams because many view DevOps as just a vehicle for successful feature releases.

Ultimately, however, these DevOps engineers have to get up at night to fix a newly deployed feature that crashes the app every time a user navigates through the onboarding process.

We want to ask you: Can an app whose onboarding process doesn’t work technically be successful, and do release teams significantly impact UX after all? Let’s find out.

In this article, we’ll be exploring how to:
[toc content=”.entry-content”]

Make users feel right at home with a great onboarding experience

Most apps require an onboarding process to show new users how to achieve their goals as efficiently and conveniently as possible.

For this, we need to keep in mind that the onboarding experience can affect your relationship with prospects – both positively and negatively.

No matter how good your app actually is, the first impression counts!

Large companies like Slack or Dropbox also frequently overhaul their user onboarding to ensure users have a comfortable, fun, and productive start to their product. But see for yourself. The following images show an excerpt from Slack’s onboarding process from 2014 and 2021. Of course, the design has changed drastically, but you can also see that instead of reading where the team name comes up in the Slack interface, we actually see the user interface and our team name on it. These improvements are certainly not the results of guesswork but of meticulously coordinated optimization workflows.

Slack Team Name

–

Slack Company Name — The evolution of Slack’s onboarding process (Source)

As even big enterprises invest in optimizing their onboarding processes, we realize that we should do the same and not rest on our laurels. The question remains, how do you make sure you are building the right onboarding experience in the right way?

And this is where cross-functional product teams and Flagship come into play!

Leverage Flagship to unite product teams and ensure great UX

At AB Tasty, when we work towards a great user experience, we focus on two main themes:

Release the right feature: We step into our users’ shoes and conduct experiments and tests to ensure that the feature delivers value and looks and feels good.
Deploy the feature right: It’s not just about functionality and looks. We utilize feature management to ensure that what we’ve created works flawlessly at all times and on different platforms.
–

Flagship chart — Flagship provides a shared environment for experimentation and feature management

–

Flagship gives you the means to get the most out of both: data-driven experimentation and feature management to create and release features for great customer experiences. So we see release teams as an integral part of creating value for our users. This may not be the most popular opinion. Still, now we’d like to tell you more about why we think DevOps should be more closely integrated with product teams.

It’s no secret that teams that work toward a common goal are more likely to reach their true potential than those that don’t. By isolating DevOps from product teams, you probably can’t count on the positive effects of unity and passion necessary to create and release great products. For this reason, we encourage product teams to work more closely with DevOps. Release teams also care about delivering value and great experiences to users. And they bring the skills required to do so to the table.

Flagship provides product managers, developers, and DevOps engineers with a shared environment for experimentation and feature management. You get easy access to all the data and tools needed to have a productive conversation about the product optimization process in a common data-driven language. Simultaneously, instead of isolating specific roles and responsibilities in silos, each member of the product team can focus on doing their job while continuing to work as a collective force.

Now, let’s take a look at how Flagship’s experimentation and feature management capabilities enable product teams to deliver outstanding user experiences.

Deploy the feature right with feature management

First, let’s talk about a few examples of how feature management and releasing a feature right can positively impact your users’ onboarding experience.

Suppose you want to add tooltips to your onboarding process to help users navigate your product’s dashboard confidently. The product team prepares the new feature accordingly and thoroughly tests the functionality on the test servers. After everything seems to be working, they roll out the new feature for all users in one fell swoop. Hopefully, it’s not Friday afternoon, as the changeover could cause unforeseen problems on the production server, like:

Your user is stuck in an infinite loop that they can’t exit
User input isn’t saved, e.g., in a form
The app crashes repeatedly
The user is sent back to the start for no apparent reason

Just imagine what such behavior means for users going through your onboarding process and looking forward to finally using your product when it suddenly stops working. Poof, the magic moment has passed. The user has most likely lost confidence in your app due to bad UX.

Flagship makes code deployments stress-free

With Flagship’s feature management capabilities, your product teams can publish new features with ease – even on Friday afternoons.

Feature management enables release teams to provide the new tooltips feature to a selected target group before continually rolling it out to everyone. This way, you can be sure that the new feature works under realistic conditions, i.e., on production servers with real users.

Through controlled and monitored rollouts, DevOps teams immediately know whether something isn’t working correctly. This enables them to react on time and be glad that only a few users have noticed the error.

For example, suppose the developers wrapped the tooltip feature in a feature flag (which they really should be doing). In that case, they can quickly deactivate it via the flagship dashboard if a problem occurs. Of course, they can also configure automatic code rollbacks based on KPIs to react even faster.

Proper feature management can de-stress your release teams: Gone are the sleepless nights spent dealing with damage control! If you want to learn more about the benefits of feature management for tech teams, we recommend our blog post here.

Release the right feature with experimentation

Perhaps you have great empaths on your product teams and feel like you know your users pretty well. Still, it is wise to experiment and test to create an onboarding process that your users will love.

Let’s look at the tooltip example from before again. Suppose that after your product team successfully integrated the tooltips into user onboarding, your analytics data shows that something must be wrong. Many users still don’t know how to use your app and abandon the process midway through. If you can’t identify and resolve the problem right away, you need to leverage other means to improve the tooltip’s user experience.

First, make sure that everything is fine from a technical point of view. Next, your product team should start working on possible variants to improve the tooltips’ presentation and functionality. You can then experiment and test with Flagship to determine which of these variants and ideas offer the best user experience.

For example, you could utilize A/B tests to see if showing a how-to video before displaying the tooltips helps users get started with your product. Or experiment with different tooltips sequences – perhaps the process is easier to understand if you change the tooltips’ order.

You’re also free to experiment with different colors, copy, UI elements, call to action, and so on. To make your experiments as meaningful as possible, you can define which users see which feature variant and track user acceptance, test results, and KPIs in the Flagship dashboard.

Another advantage of Flagship is that you can utilize 1-to-1 personalization based on audience segments to provide users with unique experiences. For example, after a user registered for a paid subscription, show them a customized welcome message and add more value to their onboarding experience.

… What about client-side tools for experimentation?

Many client-side experience optimization tools, such as our AB Tasty, can also perform most of these experiments – without code deployments. However, the advantage of coding your experiments for a critical process such as user onboarding is that you don’t potentially slow it down with automatically generated UI overlays. Instead, tests and experiments with Flagship are fast, secure, and flicker-free, as they come directly from the server and don’t have to be calculated in the user’s browser. Of course, client-side tools still have their justification and unique uses – Flagship is a great tool to complement your client-side strategy.

Wrapping up

If you want to provide users with the best possible onboarding experience, you need cross-functional teams who know how to release the right feature and how to release a feature right. One of our goals is to advocate the importance of release teams to great UX – whether a product technically works is as important as how it looks and behaves.

Using Flagship’s experimentation and feature management capabilities, product teams can benefit from a shared platform to collaborate on improving the onboarding experience in a productive and data-driven way.

Would you like to try Flagship for your product teams? Book a demo and see how experimentation and feature management can transform your users’ onboarding experience from okay to Yay.

You might also like...

See all

Article

6min read

A New Era for Product Recommendations: AB Tasty’s Semantic Proximity Algorithm

Emily Healy

Sep 15, 2025

Article

5min read

Why AB Tasty is the Best Digital Optimization Partner for Your Team

Emily Healy

Sep 10, 2025

Article

5min read

Luxury’s Secret Weapon | Anaïs Levy

Maddie Ostrander

Sep 8, 2025

Subscribe to
our Newsletter

Article

Jan 22, 2021

8min read

Why You Should be Testing in Production

AB Tasty

In a perfect world, you release a product that is bug-free and works exactly as it should and so there is no need for further testing.

However, both product managers and developers know that it’s not as simple as that. They need a way to make sure that there is a process in place that reveals any issues in code in a live production environment.

This is where testing in production comes in.

But it’s also one of the highly debated topics out there with those who say you should always test in production, and those who are more wary of the concept and say you never should.

In this article, we’ll look into these two different perspectives and share our own point of view on this controversial topic and we’ll guide you through the best ways to reap the benefits of this type of testing.

What is testing in production?

To keep it short and simple, testing in production is a software development practice of running different tests on your product when it’s in a live environment in real time.

It allows you to test new code changes on live users rather than a test or staging environment.

This type of testing is not meant to be a replacement for your QA team or eliminating a unit test or integration test. In other words, it is not supposed to replace testing before production but to complement these tests.

To do or not to do: That is the real question

These are big benefits, and they are enough to create consensus among many developers and product managers who say “Yes, always!” to the practice.

But there’s also another group of developers and product managers who say “No, never!” to testing in production.

On the one hand, they admit all of the great benefits that testing in production can deliver. On the other hand, they also believe that the practice carries too many potential downsides and that its benefits just aren’t worth taking on the risks the practice can bring.

Which side are we on?

We believe testing in production is a cornerstone practice for anyone in the software development world. And we believe it is particularly important for Product Managers, as it gives them a powerful method to generate real-world feedback and performance data they need to make sure they are always building a viable pipeline of products.

You can also check out our memes and gifs for test in production.

But even though we are great advocates of this practice, we still want to consider the point of view of those who are “No, never!” when it comes to this type of testing.

Once we acknowledge these issues, we can start to map out some ways to mitigate the practice’s potential downsides and focus on its benefits instead.

What are the big risks of testing in production?

To be blunt: a lot of things can go wrong when you test in production.

You risk deploying bad code
You may accidentally leak sensitive data
It can possibly cause system overload
You can mess up your tracking and analytics
You risk releasing a poorly designed product or feature

The list goes on and on. Anything that can go wrong, could go wrong.

Worst of all— if something does go wrong when you are testing in production, your mistake will have real-world consequences. Your product might crash at a critical moment of real-time usage.

You might also end up collecting inaccurate KPIs and creating issues with your business stakeholders.

Worse case scenario: your poorly designed product or feature might result in multiple paying customers leaving your product for a competitor instead.

Those who say “No, never!” to testing in production are correct to consider the practice highly risky, and we understand why they stay away from it.

And yet, while we acknowledge these concerns, when it comes down to it, we believe that this form of testing is an essential aspect of modern software development.

Why should you still test in production?

When done properly, testing in production gives you some great benefits that you just can’t get through any other method.

Collect real-world data and feedback

Testing in production allows you to collect user data in terms of users’ engagement with your new features. This enables the collection of valuable feedback from the customers that matters the most, which in turn would allow you to optimize the user experience based on this feedback.

This will also allow you to brainstorm ideas for features that you may not have considered before.

Uncover bugs

Since you’re testing on live users, you would be able to discover any bugs or issues that you may have otherwise missed in the development stage. Thus, you can ensure your new products and features are stable and capable of handling a high volume of real-world usage.

It is worth noting that there are certain technical issues that will never show up until you put your product or feature in front of real-world users.

Therefore, you can monitor the performance of your releases in real life so that developers can analyze performance and optimize the releases accordingly.

Higher quality releases

Because you’re receiving continuous feedback from your users, developers can improve the products resulting in high quality releases that meet your customers’ needs and expectations.

Additionally, you can verify the scalability of your product or feature through load testing in production.

Support a larger strategy of incremental release

Testing in production helps facilitate an environment of continuous delivery.

This is especially true when you roll out your releases to a certain percentage of users so that they may no longer have to wait long periods of time before they have access to your brand new features.

This way, you can limit the blast radius as with incremental releases, you would not have affected all of your users.

Perhaps, most importantly: you already are testing in production, even if you didn’t know it!

Most of Agile development and product management’s best practices are forms of testing in development. We’re talking about very common practices like:

CI/CD
A/B Testing
Phased Rollouts
Canary Deployments
Blue/green deployments
Usability Testing
Smoke & Sanity Testing

If you are following any of these practices—and many more like them—then you are already running tests with real-world users in a live production environment.

You are already testing in production, whether you call it that or not, even if you thought you were in the “No, never!” camp this whole time.

Testing in production done right

If testing in development is inevitable these days, then you should spend less time debating its pros and cons, and more time finding the most effective and responsible way to follow the practice.

We believe in this perspective so strongly that we’ve built an entire product suite around helping product developers gain all of the benefits of the practice while minimizing their risks.

Feature flags – a software development practice that allows you to enable or disable functionality without deploying code – are at the core of this new platform.

By wrapping your features in a flag and deploying them into production without making them visible to all users, you can safely perform all of the testing in production that you need.

With feature flags—combined with the rest of AB Tasty— you can:

Deploy smaller releases that minimize the impact of failure.
Only test your new features on your most loyal and understanding users.
Personalize their tests so they know to expect a few hiccups with the release.
Immediately toggle off underperforming features with a single click.

Read The Many Uses of Feature Flags to Control Your Releases for more use cases and examples.

With feature flags and a little planning, you can dramatically reduce the risk and increase the sophistication of the testing in production you are already performing.

This means more real-world user data, more reliable products & features, and less worry about seeing how your hard work performs outside of the safe confines of development and staging environments.

You might also like...

See all

Article

6min read

A New Era for Product Recommendations: AB Tasty’s Semantic Proximity Algorithm

Emily Healy

Sep 15, 2025

Article

5min read

Why AB Tasty is the Best Digital Optimization Partner for Your Team

Emily Healy

Sep 10, 2025

Article

5min read

Luxury’s Secret Weapon | Anaïs Levy

Maddie Ostrander

Sep 8, 2025

Subscribe to
our Newsletter

Article

Jan 7, 2021

3min read

Digital Experience: A Chat with REO

AB Tasty

Our UK partner series continues with Andrew Furlong, Managing Director at REO.
In this interview, we asked him the following 3 questions:

REO agency

At REO, you “believe digital experiences can always be better” – what does that mean?

Like with most things, there is always room for improvement. The growth of AB testing and Personalization is because brands and consumers believe and demand a better experience. So, what we mean is: no matter how good you think your digital experience is, it can always be improved. And we are here to help if you are not sure how!

What are you most proud of at REO?

This one is easy… the team! They are great to work with, they are challenging and speak their mind to help REO be the very best it can be. Having such a brilliant team pays off as shown with our latest client satisfaction score of 8.5/10.

Which ultimate tip for experience optimization do you have for our readers?

It is important to always have multiple streams of optimization running, I am not talking about concurrent tests, although where feasible that should be done. I mean having a fallback strategy so that if a test is delayed for reasons beyond your control, you can quickly pivot to a different part of the site for example.

About REO

REO is a digital experience agency. We are an eclectic mix of bright and creative thinkers, embracing the best of research, strategy, design and experimentation to solve our clients’ toughest challenges. We work across a variety of sectors, with companies such as Amazon, M&S, Tesco and Samsung. To fearlessly transform our clients’ businesses and reputations by evolving the Digital Experience for their customers. We achieve this through:

Our curious and relentless drive to gather insights that matter.
Our proactive mindset and forward thinking to deliver lasting value.
Our adventurous approach to adapt and learn quickly.

Want to learn more about REO? You can reach out via info@reodigital.com, call on +44 (0) 203 827 7539 or visit their website https://www.reodigital.com.

You might also like...

See all

Article

6min read

A New Era for Product Recommendations: AB Tasty’s Semantic Proximity Algorithm

Emily Healy

Sep 15, 2025

Article

5min read

Why AB Tasty is the Best Digital Optimization Partner for Your Team

Emily Healy

Sep 10, 2025

Article

5min read

Luxury’s Secret Weapon | Anaïs Levy

Maddie Ostrander

Sep 8, 2025

Subscribe to
our Newsletter

Article

Jan 5, 2021

14min read

What is Eye Tracking & Why You Should Use it For Your Business

AB Tasty

In an increasingly cutthroat digital age, standing out in your niche while meeting the exact needs of your consumers is essential to business growth and longevity.

By getting under the skin of your customers, you can tailor your messaging, applications, and touchpoints to meet their exact needs —that’s where eye tracking enters the mix.

Consider this for a moment:

You’re running a usability test on a product landing page for a new range of gym shoes. Your test subject, Nancy, browses the page and chooses a shiny new pair of gym shoes with ease. But, on the next page, there is a snag. She hesitates and eventually abandons her cart because the journey was confusing.

You take notes based on Nancy’s feedback and think about how you can improve your checkout journey. But, if you could view her movements— or see what she sees—you would have the power to make informed improvements that will ultimately increase conversions and drive more sales.

With eye tracking, you can. But while this widely-used sensor-based technology offers a deep glimpse into user browsing behavior, some industry experts believe that eye tracking is an unnecessary expense.

Like many platforms and digital innovations, with the right approach, eye tracking will give you the tools to offer your customers a seamless level of user experience (UX)—the kind that will increase loyalty while helping you boost your bottom line.

Here we explore the dynamics of eye tracking and explain why it could make an excellent investment for your business.

So, what is eye tracking?

Eye tracking is a type of sensor technology that gives a computer or mobile device the tools to understand and trace where a person is looking.

An eye tracker can detect the presence, attention and focus of a user while engaging with a specific app, touchpoint or website.

From a marketing perspective, eye tracking dates back to the 1980s, where it was used to test and measure the value of ads in print papers or magazines.

An effective alternative to lie detection-style techniques such as voice stress analysis and galvanic skin response (neither of which offer truly reliable results or data), eye tracking gave the advertisers of the day essential insights into which elements of a page people read as well as how long they spend engaging with specific pieces of content.

The popularity of the eye tracker rose over the years and the rapid evolution of digital technology paved the way for a wealth of innovative developments.

Now, eye tracking technology is able to offer deep-dive insights into user behavior and dynamic page as well as app design as well as offering intuitive tools that enhance the user journey for disabled people.

In the modern age, one of the most prominent features of eye tracking is a little something called Facial Expression Analysis (FEA).

Based on ‘points of fixation’—times during the user journey when someone stops and focuses long enough to process the content before them (commonly known as a ‘saccade’)—FEA technology helps marketers gauge the effectiveness of their page design and messaging.

But, how does this apply to business and why is it so useful? Let’s find out.

Eye tracking and consumer research — Source

Why is eye tracking useful in the digital age?

As a marketer or business owner, the more you understand your target audience, the more chance you have of creating a fluent and engaging customer journey across platforms.

As eye tracking provides a visual map of how your users engage with your website, landing pages, and mobile applications, you can identify strengths and weaknesses related to user experience (UX) and content placement.

An essential part of the consumer research process, eye tracking is a powerful medium as it taps into the fact that 95% of human decision-making (particularly online) is carried out sub-consciously.

By using eye tracker tools to trace navigational patterns, you can adopt your customers’ vision, uncovering information that will help you to make improvements that boost engagement, improve your customer experience (CX) offerings, and ultimately, accelerate the growth of your business.

From heat mapping to task-based usability tools, there are a wealth of eye tracking innovations available to businesses in today’s digital world.

Invest in the right eye tracking tool for your business and you will:

Understand what your target audience is looking at and for how long
Identify redundant or disruptive visuals or design elements
Document how users scan and interact with your web pages or apps
Gain a practical understanding of what works and what doesn’t
Prove the value of certain marketing strategies, techniques or campaigns
Continually improve and evolve your efforts in a landscape that is ever-changing

Eye tracking is an effective means of seeing through the lens of your customers. But, as powerful as it is, eye trackers alone are unlikely to give you a complete insight into the content that really sticks in the users’ mind.

To gain additional context on how to use your data to improve usability and drive engagement, eye tracking should be a pivotal part of your consumer research strategy rather than a sole means of information.

That said, if you use it the right way, eye tracking can help you understand your customers in ways that can give you an all-important edge on the competition.

How eye tracking can help you understand your customers

Using eye tracking to understand your customers on a deeper level boils down to adopting a cohesive mix of the right tools and techniques.

Eye tracking tools and software provide a visual representation of your users’ focus points—returning data based on:

Fixation points or saccades: information that can tell you how engaging or eye-catching particular elements or pieces of content on a webpage are to your customers.
Navigational patterns: by understanding common navigational patterns, you can see how people scan or interact with your page. This level of knowledge will give you the data you need to optimize your content and design for increased engagement and conversions.
Problematic elements As mentioned, an eye tracking test will return invaluable data based on any images, graphics, calls to action (CTA) or command buttons, informational content or design elements that hinder the user experience and prevent customers from either getting what they need from your page or carrying out a desired action (clicking through to a specific product page or signing up to an email newsletter, etc).

Automotive repair and wreckage company, Truckers Assist, conducted eye tracking tests to track the performance of its homepage.

This test showed that while the ‘NO FEES’ graphic (the red point on the image) was gaining a lot of attention, it wasn’t clickable. As a result, many users were focusing their attention in the wrong place, steering them away from more valuable information as a result.

To fix this glaring issue, Trucker Assist improved its homepage design, removing the ‘NO FEES’ banner and placing focus on its contact information and service search bar.

Conducting successful eye tracking testing takes consistency as well as a clear cut goal. Do you want to improve the user journey of your new mobile app? Are you looking to drive more revenue through a specific product page? Perhaps you’re trying to understand if your general messaging and branding is performing the way it should?

There are many actionable insights you can gain from eye tracking—and outlining your specific goals will give your tests or studies direction.

This hand-picked video offers practical advice and information to help you get started with eye tracking:

How eye tracking benefits UX optimization

88% of consumers are less likely to return to a website after a poor user experience. Today’s consumers expect a seamless level of UX from brands and businesses—anything less and you could see customer loyalty as well as sales drop through the floor.

Eye tracking and UX go hand in hand. Through eye tracking, you will gain access to objective and unbiased insights that will show you where improvements are necessary.

With eye trackers, you can drill down into a specific UI element (is it facilitating the right interactions or are your consumers missing it altogether?) to test whether it fits into the user journey while getting to the very root of any distracting, problematic or misleading page elements.

This perfect storm of on-page information will empower you to make very specific improvements to any app, web or landing page—enhancing its usability and performance significantly.

How eye tracking works in a nutshell

As a concept, a significant part of eye tracking is based in Fitts’ Law. Essentially, every visual object or element carries a certain amount of ‘weight’ and this determines the amount of attention as well as clicks it ultimately earns.

Concerning eye tracking and UX, Fitts’s Law is important because it can help you predict the amount of time taken to move the eyes or cursor to a specific target.

Armed with this information, you can establish a visual hierarchy and optimize your webpages or applications to ensure consumers can connect with the right functions or information at the right times within their journey.

To get your eye tracking tests off to the best possible start, giving you users clearcut instructions while ensuring good lighting and consistent positioning is essential. Doing so will give you reliable data, as detailed in this infographic from IMOTIONS:

Essential eye tracking methods & techniques

There are thousands of eye tracking tools and countless ways of approaching this most powerful approach to user testing.

To guide you along the right path, here we’re going to explore the most essential eye tracking methods and techniques.

Heat maps

A branch of eye tracking, a heat map is a dynamic tool that offers a definitive visual representation of where users focus their attention and how they navigate your website based on their on-page interactions.

Heat mapping platforms provide color-coded data to give an indication of the areas of a website or mobile page users are interacting with the most.

As you can see from the image above, the red spots show the areas where users focus their attention most while the lighter colors are the areas with the lowest engagements.

Heat mapping technology also serves concrete data based on how much particular buttons or links are clicked by users on a page while offering navigational information such as scroll rates to show how far people move down the page before bouncing off.

To gain a full working insight into this effective optimization tool, read our full guide on using heat mapping to uncover areas of improvement on your website.

Focus mapping

Essentially an inversion of heat mapping, focus mapping provides digestible visual insights on the main fixation points on a specific page.

With focus maps, the page is blanked out except for the spots that receive the most attention or fixation.

A visual technique to complement additional eye tracking tests and consumer research strategies, with focus mapping you will get a panoramic view of which elements are working as well as the content you need to improve to encourage focus and engagement.

Gaze path plots

As sensory-based technology, eye tracking can provide a wealth of valuable insight in a single browsing session.

By adding metrics related to time as part of your eye tracking strategy, you can follow the path a user takes on a webpage and the time they spent on each element.

As you can see from the ‘Where’s Wally’ video, gaze plots make an effective eye tracking technique as they offer a dynamic interpretation of how users interact with your site or mobile app.

If you follow these paths, it’s possible to get a real-time insight into the eyes of your audience. This wealth of visual eye tracking data will empower you to drill down into specific areas of a web or app page, making design or content tweaks to optimize the overall user experience.

Eye tracking metrics

In addition to diversifying your approach to eye tracking and working with a mix tool or platforms, focusing on the right metrics will improve your chances of success exponentially.

Here are the main eye tracking metrics you should work with during your user research tests and studies:

Areas of Interest (AOIs): Before running an eye tracking test or study, you should determine your AOIs. Mapping out your main areas of interest on a particular web or mobile page will give your test definitive direction while ensuring you only collect or concentrate data to provide answers to the right questions.
Dwell time: This metric is focused on the actual amount of time a user or test subject spends interacting with a predetermined AOI. You can, for instance run A/B testing to compare two versions of a webpage to see which one returns the healthiest AOI dwell times and thus, offer the best return on investment (ROI).
Fixation count: Like dwell time, fixation count can offer interaction data based on your AOIs. But, rather than quantifying time, fixation count records up how many fixations your AOIs receive during a test or time period. As such, you can compare fixation and dwell time data to identify a correlation while painting a panoramic picture that will make your optimization efforts more successful.
Ratio: In an eye tracking context, ratio will tell you how many users or test subjects have guided their gaze to a particular AOI. Tracking ratio will give you an insight into whether you need to alter a specific piece of content or design element to capture the attention of more users and streamline your site navigation.
Revisits: Based on your AOIs, revisits determine how many times a user returns their gaze to a specific point during a test or browsing session. This metric is beneficial for understanding whether your design and layout make it easy for people to navigate a page or not. If you find that a particular AOI is showing a high rate of revisit rates, it might be that your content is a little confusing or that there is a design element causing distraction.

Getting started with eye tracking: best practices

Now that you understand how eye tracking works and you’re acquainted with essential techniques, we’re going to look at some top tips to help you get the most from your eye tracking test efforts:

Once you’ve established the aims and criteria of your test, allow your users to complete the process uninterrupted. Asking questions during the test itself is likely to distract your test subjects, skewing your results in the process.
Make sure that your participants remain within the monitoring range from start to finish. If a subject falls out of position, halt the test to ensure they are back in the monitoring range. Doing so will ensure the best quality data.
For qualitative testing and manual eye tracking, around five test subjects will typically offer the level of insight you need for the job. For heat maps and broader eye tracking studies, it’s recommended to use at least 39 test subjects for well-rounded and actionable results.
For mobile optimization tests, you should focus on the performance and value of your functional icons across devices; the precision of your error messaging; and the consistency as well as responsibility of your mobile design and layout.
To maximize your eye tracking efforts, working with customer experience optimization experts will help you run successful eye tracking-type tests that will return data that is aligned with your specific strategies and goals.

Final thoughts

“You can’t solve a problem on the same level that it was created. You have to rise above it to the next level.”

—Albert Einstein

Niche or sector aside, without knowing your audience and understanding how they interact with your business, you are merely shooting in the dark.

In an ever-evolving digital age, a data-driven approach to consumer research and UX optimization will help you meet your users’ needs head on while empowering you to adapt to constant change.

Eye tracking may not be the answer to all of your consumer-centric needs but this most innovative of sensor technology could easily play an important role in your ongoing marketing and development strategy.

There is no one-size-fits-all way to approach eye tracking—success will depend on your goals and needs as a business. But, by embracing the methods and techniques we’ve discussed, you will open yourself up to a treasure trove of data-driven insights that will accelerate the growth of your business.

We hope our guide to eye tracking has helped you on your way and for more business-boosting pearls of wisdom!

You might also like...

See all

Article

6min read

A New Era for Product Recommendations: AB Tasty’s Semantic Proximity Algorithm

Emily Healy

Sep 15, 2025

Article

5min read

Why AB Tasty is the Best Digital Optimization Partner for Your Team

Emily Healy

Sep 10, 2025

Article

5min read

Luxury’s Secret Weapon | Anaïs Levy

Maddie Ostrander

Sep 8, 2025

Subscribe to
our Newsletter

Article

Dec 30, 2020

7min read

How AB Tasty’s Feature Experimentation and Rollouts Enrich the Lives of Our Tech Teams

AB Tasty

We developed our feature management too l to provide tech teams with the capabilities to deliver frictionless customer experiences more effectively. Naturally, we also use this tool at AB Tasty, but in the past, we also had to master our development cycles without the tool.

In this article, I’d like to give you insight into how our tech teams’ work has changed thanks to our Feature Experimentation and Rollouts solution. How did we work before? What has changed, and why do we appreciate the tool? Without further ado, let’s find out!

What a typical development cycle without our feature management platform looks like

The beginning of a typical development cycle is marked by a problem, or user need that we want to solve. We start with a discovery phase, during which we work towards a deep understanding of the situation and issues. This allows us to ideate possible solutions, which we then validate with a Proof of Concept (POC). For this, we usually implement a quick and dirty variant – the Minimum Viable Product (MVP) – which we then test with a canary deployment on one or two clients.

When the solution seems to be responding to customer needs as intended, we start iterating the MVP. We’re allocating more resources to the project to get it into a robust, secure, and user-friendly state. During this process, we alternate between developing, deploying, and testing until we feel confident enough to share the solution with our entire user base. This is when we usually learn how most of our users react to the solution and how it performs in a realistic environment.

The pitfalls of this approach, or: Why we developed a server-side solution

Let’s see why we weren’t happy with this strategy and decided to improve it. Here are some of the main weaknesses we discovered:

Unconvincing test results.

A canary release with one or two clients is great for getting first impressions but doesn’t provide a good representation of the solution’s impact on a larger user base. We lacked qualitative and quantitative test data and the ability to use it simply and purposefully. Manual trial and error slowed us down, and our iterations didn’t always produce satisfactory results that we could rely on.

Shaky feature management.

Developers were often nervous about new releases because they didn’t know how the feature would behave under a higher workload. When something went wrong in production, it was always incredibly stressful to go through our entire deployment cycle to disable the buggy code. And that’s just one example of why we needed a proper feature management solution.

We see tech teams around the world know and fear the same difficulties. That’s why we created a server-side and feature flagging solution to help them – and us – innovate and deliver faster than ever before while reducing risks and headaches.

I spoke to some of my tech teammates to determine how their work lives have changed since we started using our new tool. I noticed some major themes that I’d like to share with you now.

We know the impact of a new feature

Our product teams need to make a clear connection between a business KPI and a feature under test. In the past, we’ve fiddled with Google Analytics for a rough idea, but without distinct control and test groups for our experiments, we couldn’t know if our changes made a difference.

With our feature management platform, we no longer have to guess and can follow a scientific approach. We now know for sure whether a business KPI is positively impacted by the feature in question.

Suppose we publish a new feature while the marketing team starts a campaign without us knowing about it. We may get abnormal test results such as increased traffic, engagement, and clicks because of this. The problem: how can we measure the real impact of our feature?

The platform lets us define control groups to reduce this risk. And thanks to statistical modeling (Bayesian statistics), we get accurate data from which we can make a reliable interpretation.

The discovery phase lives and dies with qualitative information – but how can you get reliable data? Our answer is to conduct controlled experimentation and progressive deployments.

One time, we worked on a new version of one of our APIs and used our server-side solution for load testing. Fortunately, we found that the service crashed at some point as we gradually increased the number of users (the load). The problem wasn’t necessarily the feature itself. It had to do with changes in the environment, which can be easy to miss with traditional web testing strategies. However, we could stop the deployment immediately and prevent end-users or our SLAs with customers from being harmed by the API changes. Instead, we had the opportunity to further stabilize the API and then make it available to all users with confidence.

We iterate faster by decoupling code releases from feature deployments

We often deploy half-finished features into production – obviously, we wrap them in feature flags to manage their status and visibility. This technique allows us to iterate so much faster than before. We no longer have to wait for the feature to be presentable to do our first experiments and tests. Instead, we enjoy full flexibility and can define exactly when and with whom to test.

Additionally, we no longer have to laboriously find out who can see what in production during feature development, as we don’t have to integrate these things into our code anymore. Instead, we use the Decision API to connect features with the admin interface through which we define and change the target groups at any time.

What’s more, everyone in the team can theoretically use this interface and see how the new feature performs without involving us developers. This is a huge time saver and lets us focus on our actual tasks.

“Our Feature Experimentation and Rollouts solution helps me take back control of my own features. In my old job, I was asked to justify what I was doing in real-time, and I sometimes had trouble getting my own data in terms of CDP MOA, now I can get it.”

Julien Madiot, Technical Support Engineer

We can rely on secure deployments

Proper feature management has definitely changed how we work and how we feel about our work. And by managing our feature flags with our feature flagging platform, the whole process has become much easier for our large and diverse teams.

EVERY feature has to be wrapped in a feature flag – this is possibly one of our most essential rules in development. But it pays off:

They’re ON/OFF switches. Let’s not lie: we still make mistakes or overlook problems. But that’s not the end of the world. Especially not if our code is enclosed in a feature flag so that we can “turn it off” when things get hairy! With our feature flagging platform as our main base for feature management, we can do this instantly, without code deployments.
They help us to conduct controlled experiments. We use feature flags to securely perform tests and experiments in real-world conditions, aka in production. A developer or even a non-tech team member can easily define, change, and expand the test target groups in the dashboard. Thanks to this, we don’t have to code these changes or touch our codebase in any way!

They cut the stress of deployments. Sometimes we want to push code into production, but not yet for it to work its magic. This comes in handy when a feature is ready, but we’re waiting for the product owner’s final “Go!”. When the time comes, we can activate the feature in our dashboard hassle-free.

DevOps engineers have many responsibilities when it comes to software delivery. Managing our feature flags with our server-side solution is an effective way to lift the burden off their shoulders:

I honestly sleep better since we started using our server-side solution 🙂 Because I’m the one that puts things in production on Thursdays. When people say ‘Whoops, we accidentally pushed that into production,’ now I can say, ‘Yeah, but it’s flagged!’

Guillaume Jacquart, Technical Team Leader

Wrapping up

I hope you found the behind-the-scenes look at AB Tasty both interesting and informative. And yes, if there was any doubt, we actually use AB Tasty’s Feature Experimentation for all AB Tasty feature development! This helps us improve the product and ensure that it serves its purpose as a valuable addition to modern tech teams.

You might also like...

See all

Article

6min read

A New Era for Product Recommendations: AB Tasty’s Semantic Proximity Algorithm

Emily Healy

Sep 15, 2025

Article

5min read

Why AB Tasty is the Best Digital Optimization Partner for Your Team

Emily Healy

Sep 10, 2025

Article

5min read

Luxury’s Secret Weapon | Anaïs Levy

Maddie Ostrander

Sep 8, 2025

Subscribe to
our Newsletter

Article

Nov 23, 2020

7min read

The Step-by-Step Guide to Progressive Rollout

AB Tasty

You’ve heard all about the surface-level benefits of rapid product releases. They let you explore, experiment with, and test features faster. They create a more collaborative development process. And they let you run an efficient high-output team.

All of these benefits are true, but the biggest benefits you’ll enjoy from driving rapid releases lie even deeper than is commonly acknowledged…

Rapid releases do create better products. Rapid releases create a short feedback loop between you and your users. You learn very quickly what’s working and what isn’t, and you can quickly adjust.

But even more important, rapid releases get you and your team out of your own heads. Rapid releases force you to get your product and feature ideas out of the lab and into the real world. This constant contact with reality leads you to create products that simply and directly deliver the actual functions your users need most, while leaving the nice-to-have fluff on the whiteboard.

Rapid releases do create happier users. Rapid releases let you provide new features, and fix bugs, as quickly as possible. You constantly give your users a better and better product.

But on an even deeper level, rapid releases demonstrate that you care about your users. It shows them that you are listening to their feedback, and that you are taking it seriously. It tells your users that you care about them so much that you have structured the heart of your product management strategy around doing whatever it takes to make them happy and loyal.

Rapid releases do create better businesses. Rapid releases—when properly executed—can create a lot of excitement and enthusiasm throughout your entire organization. They create a culture of progress and forward momentum, where everyone feels that they are contributing to real outcomes and not just spinning their wheels.

But rapid releases also improve your organization’s culture through an even subtler mechanism. Each release can act as a touchpoint that connects the product team with everyone else in the organization. It gives you a common reason to celebrate, to collaborate, and to realign groups that are too often siloed.

Now, we don’t want to oversell rapid releases here. They are not a cure-all, and they are not even appropriate for every single situation. But if you are operating in a context where you can accelerate your product and feature release cycle, you’ll experience a whole lot of upside with little-to-no downside.

To help you drive rapid releases in your organization, we’ll use this piece to explore why rapid releases can be challenging to pull off (even in an agile product development framework), what is the key ingredient you can adopt to overcome all of these challenges, and how to bring that ingredient to life in your organization.

The Biggest Challenges to Driving Rapid Releases

Let’s be clear about one thing— not every organization is well set up to deliver rapid releases. Product managers at big, legacy corporations tend to have a hard time getting anything out in a timely manner. This is almost never their fault. They just have so many layers of review and approval for everything they do that it can take months to push out a small feature that a smaller, nimbler organization could release in weeks or days.

If this is your context, then the best thing you can do is attempt to establish the core principles of lean product development in your organization. This will represent a huge win, and speed things up significantly for you, all by itself.

Now for the rest of you— Let’s assume you are working at one of those smaller, nimbler organizations. And you are already following an agile product development process. And you still are not releasing new products and features as quickly as you’d like. Chances are, you’re being bottlenecked by one or more of these subtle challenges:

You are completing sprint after sprint but you never seem to get any closer to having something to release. Your entire development process feels like it’s focused on completing code, and not completing products and features.
You are getting products and features close to release, but they get trapped in the testing and QA process. This delays their release significantly—sometimes indefinitely.
You are able to complete new features and products, but release gets delayed because it’s such a miserable process. It’s always a big, chaotic scramble. And everyone—from your product team to your business stakeholders—gets stressed and worried about what’s going to happen when you publish the changes and delay the process.

None of these issues are solved by the fundamentals of agile product development. It’s easy to focus agile workflows on development and never give much thought to release. It’s easy to put off testing and QA until the last minute for the sake of velocity, and wind up with a huge backlog to deal with at the end. And agile products and features have developed a reputation (deserved or not) for being buggy, broken, and more aligned with what the product team thinks is right, and not what the customer actually wants.

It’s clear that agile in and of itself will not solve these problems, nor ensure rapid releases. But a small tweak to agile will.

How Progressive Rollouts Unlock Rapid Releases in Agile Product Development

You’ve heard of progressive rollouts before. They are considered an optional subset of agile methodology that restructure the entire release process.

Traditionally, a product manager would release a new product or feature in its full form, to every user, at the exact same time. But a product manager that follows progressive rollouts would release that same new product or feature in smaller forms, to a few user groups at a time, and in staged intervals.

Essentially, progressive rollouts let you break up “big bang” releases into smaller chunks. And along the way, you end up solving a lot of the challenges that prevent rapid releases. For example:

Progressive rollouts shift the product team’s focus off developing new code, and onto driving releases.
Progressive rollouts force you to focus on code quality, and readiness to deploy, instead of code volume.
Progressive rollouts remove most of the risks—and resulting stress—from releases by shrinking them into smaller, easier-to-control stages.

Progressive rollouts are the key ingredient that takes the solid foundation of lean product management, and ensures it’s properly lined up to deliver rapid releases. Here’s how you can bring it to life in your organization.

7 Steps to Ensuring Rapid Releases with Progressive Rollouts

Structure Your Release Phases: Don’t let them be hurried, disorganized dashes at the end of a development cycle. Give them the same time, attention, and care as you give every other element of your product management framework. Create formalized processes, and adopt the tools you need to make those processes automatic habits.
Decide Which Products and Features to Release. Review your current queue. Identify the highest impact products and features that you can drive to completion soonest. Employ feature flags to hide features in products that aren’t ready yet, and focus your users on one small subset of new functionality at a time.
Establish Your Personas and User Groups. Identify your highest-value users, and the opportunities they represent. Leverage these groups to test the new products and features they will love most. Personalize and customize their experience to let them know they’re getting early access because of just how valuable they are to you.
Plan Your Progressive Rollouts: Define the features and products you are going to release. Define who they are going to be released to. Define when they are going to be released, and what the stages look like. And then organize your sprints to deliver to these requirements.
Define the Impact of Each Rollout. Establish the exact, measurable, accountable business metrics you plan to improve with each of your rollouts. Define the hard and soft impact each release will have on every function in your business— and tell each function about the release before it happens.
Communicate Your Release. Loop your business stakeholders in on each element of your release plans that might give them pause or concern. Show them how progressive rollouts mitigate their risk around product and feature quality and alignment. And update them on the progress of each release at each stage of your rollout.
Automate as Much of Your Rollout as Possible. Remove yourself and your team as the bottleneck. Automate your QA and testing. Set your deployment intervals and parameters, and then let your software execute it for you. Monitor your release’s performance at each stage. A/B test as much as possible. And intervene ASAP when an issue is identified. But otherwise, let the right tools make rapid releases through progressive rollouts a smooth element of your agile product development process.

With a little bit of intentional planning, with a shift in the focus of your agile product development, and with the right tools, you can easily bring progressive rollouts to your organization, and rapidly increase the rate of your releases.

You might also like...

See all

Article

6min read

A New Era for Product Recommendations: AB Tasty’s Semantic Proximity Algorithm

Emily Healy

Sep 15, 2025

Article

5min read

Why AB Tasty is the Best Digital Optimization Partner for Your Team

Emily Healy

Sep 10, 2025

Article

5min read

Luxury’s Secret Weapon | Anaïs Levy

Maddie Ostrander

Sep 8, 2025

Subscribe to
our Newsletter

Article

Nov 16, 2020

8min read

Call to Action: A Simple Guide to More Conversions

AB Tasty

A Call to Action, also known as a CTA, refers, in marketing, to any item that will, using imperative wording, encourage an immediate action or response from the user.

Calls to Action are essential in marketing campaigns. They’re a way to lead customers to a specific action. They generally come as a button, but they also exist in many other forms. In this guide, we’ll tell you everything you need to know about CTAs, how they work and how to use them on your website.

What is a Call to Action?

Behind this mysterious name hides a very simple marketing concept you’ve all seen before. Calls to Action (CTAs) refer to any device conceived to persuade users to do a specific action.

E-commerce companies usually use them in the form of buttons to encourage buyers to add an item to their shopping cart or to complete a transaction. It is a key element to integrate playful interaction with your users and an effective means to increase conversions.

The goal of a CTA is to use a word or a sentence (most of the time containing action verbs) to push your users toward a specific action like “click here”, “subscribe”, “check out” and many others. These action words can also be used with a “now” creating a sense of urgency. Calls to Action were proven to be very effective and to optimize conversion rates.

CTAs can be used to push users down the purchase funnel, but they can also be used for any kind of action like registering, subscribing to a newsletter or adding to cart.

What makes an effective CTA? When creating a CTA for your website, every detail counts. Here are some aspects you need to pay attention to for your CTA button:

Visual aspect
Wording
Action word
Placement
Form
Color
Size

Do not underestimate the impact your CTA button can have on your conversion rate. A well-written Call to Action needs to be adapted to your audience, their age, their gender or their nationality. Remember that a CTA isn’t just a command or an invitation for your users, it is part of the full purchasing process. That’s why it needs to be discreetly integrated but obvious enough to be noticed by users.

Why do you need a clear Call to Action in your CRO strategy?

Always remember the importance of CTAs in your purchase funnel. Your customer’s path to completing a transaction is paved with CTA buttons. They are a key element in your CRO (Conversion Rate Optimization) strategy, they need to be quite obvious since they are meant to lead users to the action you want them to complete.

A good and clear Call to Action comes with a nice visual, adapted to your target audience, with a clear and straightforward message. That way, and only that way, you will get the best out of your CTA and note effective results in your conversion rate AND your CTR (Click Through Rates).

An efficient CTA is nothing but a perfect compromise between your e-commerce site’s goal, which is to increase sales or to sell a specific product, and users’ needs, i.e. a smooth navigation experience while purchasing a product. That’s why your CTA needs to be neat and easy to find, and user experience always needs to be taken into account.

Best Call to Action examples of 2020

CTAs come in many forms. To help you with your CTA A/B testing, we listed the 5 best forms of CTAs in 2020:

1. Direct Calls to Action

Let’s say your goal is to push your customers down the purchase funnel. Then, you might opt for a direct CTA, such as:

Shop now
Buy now
Add to shopping cart

This is an Amazon product page showing CTA An Amazon product page containing an add to shopping cart and buying button CTA (Image Source).

2. “Get for Free” Calls to Action

With these CTAs, you can highlight an opportunity for the users. Generally, these come with a “subscribe” box. You can collect your users’ email addresses in exchange for a sample of a document or a free trial. These CTAs usually appear as:

Download for free
Free 30 day trial
Start free trial

This is a screen shot of Tidal's free trial

Tidal homepage enticing users to register with a free trial (Image Source).

3. Basic Calls to Action examples

CTAs can be a mere invitation. For instance, on a social media’s ad or as a shortcut to a long text. This kind of CTA is often used in blog posts or Facebooks Ads. Awakening the user’s curiosity, it is supposed to make users want to go further and learn more about a topic with messages like:

Check it out
Start here
Find out more
Learn more

This is a screen shot of Philips CTA for their newsletter Philips USA homepage with multiple CTAs (Image Source).

4. Registering Calls to Action

This kind of CTA is often found on social media or e-commerce sites. The goal is simple: encourage your visitors to create an account and register with messages such as:

Create your account
Sign up
Join us

This is a screen shot of Bose's sign up CTA Bose homepage with sign up CTA (Image Source).

5. Email Calls to Action

All of the above have one thing in common: they allow you to connect with your users by collecting their emails, which will be useful for your email marketing campaigns. According to what you are proposing, users can fill in their email to get something like a discount, a coupon or a free PDF. For these, you can use wordings such as:

Subscribe
Get coupon
Download free PDF
Sign up

This is a screen shot of Anastasia's CTA to join the emailing list

For more, read our article about “14 Examples of CTAs You Can’t Resist”.

A/B Test your CTA for better results

A/B testing

A/B testing is the most accurate technique for CRO. This digital marketing strategy consists of making changes on your website and observing the impact of this change on a segment of users.

This is the best method to improve your conversion rate, because you can try out any feature and choose the one whose results are best. It is more reliable since users are the ones determining which feature works best. With this method, you can test your idea with your target users or potential customers.

A/B testing your CTA buttons is the best way to improve your website’s UX and your conversion rate at the same time. At AB Tasty, we offer a super quick and easy way to run these kinds of tests – our drag and drop visual editor.

How to run an A/B test for your CTA?

Here are the different steps you need to follow to A/B test your Call to Action button:

Define your test’s goal and the KPIs you want to improve

Changing your button’s feature must serve a goal. It wouldn’t make sense to change your CTA’s color, to run your test and wait for random results. Your goal can be to increase the number of users that subscribe to your newsletter, for instance.

Define the original and alternative version (A and B version)

Choose the CTA you want to run your A/B test on, let’s say the red “subscribe to newsletter” button. This red button will be your A version.

What do you want to change about it? Maybe users will be more likely to click on this button if it were blue? Then, change your button’s color. (If you’re using AB Tasty, this takes two seconds with our drag and drop editor). The blue version of the CTA button will be your B version.

Run your A/B test

Worried about exposing 50% of your website visitors to this new change? If you have enough traffic, you can run your test on a smaller percentage of your entire website audience to mitigate the risk of any potential lost conversions.

Collect data and check your analytics

Usually, A/B tests take several weeks before you get reliable results. During that period, observe your A/B testing tool reporting. Did your conversion rate increase? Did it decrease?

Hard code changes (or not)

Figures don’t lie. Based on the test’s results, change what needs to be changed and keep what needs to be kept. Step by step you will find the best combination of features for the perfect CTA.

Conclusion

CTAs are essential in your conversion rate optimization strategy, but they can’t appear randomly or look like any old button. They need to be wisely thought out, otherwise they might not have the expected effect.

Thanks to A/B testing, you will be able to find the right features in order to get the best performance out of them. Remember that visual aspects (like form, color, or size), wording, the chosen action word, and placement matter in your CTA’s performance.

So, what’s the takeaway? An effective Call to Action can boost your website KPIs, and you can A/B test any of your website’s pages – the sky’s the limit.

You might also like...

See all

Article

6min read

A New Era for Product Recommendations: AB Tasty’s Semantic Proximity Algorithm

Emily Healy

Sep 15, 2025

Article

5min read

Why AB Tasty is the Best Digital Optimization Partner for Your Team

Emily Healy

Sep 10, 2025

Article

5min read

Luxury’s Secret Weapon | Anaïs Levy

Maddie Ostrander

Sep 8, 2025

What exactly is a feature toggle?

Different feature toggles for different tasks

Release toggles

Experiment toggles

Operational toggles

Permission toggles

Feature toggles vs. feature flags

Including feature toggles in your roadmap supports agile workflows

Our best practices for using feature toggles

Use feature toggles to gradually transition to agile development

Use toggles for both internal and external features

Include toggle planning in your design phase

Have a standardized toggle naming scheme

Manage different toggles differently

Always expose feature toggle configurations

Keep the holding costs of feature toggles in check

Keep toggle scope as small as possible

Feature toggles can transform your entire development process

Start small and scale up

You might also like...

What is a Feature Rollback?

Why Should Product Managers Perform Rollbacks?

When Should You Perform a Rollback? Two Common Use Cases

Rollback Use Case 1: Your Feature has a Bug

Rollback Use Case 2: Your Feature is Poorly Received

What Do These Two Use Cases Have in Common?

How to Make Faster Rollback Decisions

How to Execute Rollbacks Faster

You might also like...

Move Fast, Risk Less

Your Customers, Not Your HIPPOs, Decide

Get off the Ford Line

Marketing and Product Manager Alignment

Developers Focus on Core Business Objectives

You might also like...

Make users feel right at home with a great onboarding experience

Leverage Flagship to unite product teams and ensure great UX

Deploy the feature right with feature management

Flagship makes code deployments stress-free

Release the right feature with experimentation

… What about client-side tools for experimentation?

Wrapping up

You might also like...

What is testing in production?

To do or not to do: That is the real question

Which side are we on?

What are the big risks of testing in production?

Why should you still test in production?

Collect real-world data and feedback

Uncover bugs

Higher quality releases

Support a larger strategy of incremental release

Perhaps, most importantly: you already are testing in production, even if you didn’t know it!

Testing in production done right

You might also like...

At REO, you “believe digital experiences can always be better” – what does that mean?

What are you most proud of at REO?

Which ultimate tip for experience optimization do you have for our readers?

About REO

You might also like...

So, what is eye tracking?

Why is eye tracking useful in the digital age?

How eye tracking can help you understand your customers

How eye tracking benefits UX optimization

How eye tracking works in a nutshell

Essential eye tracking methods & techniques

Heat maps

Focus mapping

Gaze path plots

Eye tracking metrics

Getting started with eye tracking: best practices

Final thoughts

“You can’t solve a problem on the same level that it was created. You have to rise above it to the next level.”

—Albert Einstein

You might also like...

What a typical development cycle without our feature management platform looks like

The pitfalls of this approach, or: Why we developed a server-side solution

Unconvincing test results.

Shaky feature management.

We know the impact of a new feature