Building a great website is, unfortunately, not simply a matter of following best practices. Even within a single industry, users will hold varied expectations based on your brand, communication style, target audience, funnel, etc. And while browsing the same website, users’ expectations can vary, with some knowing exactly what they want and others needing to explore, check your returns policy, learn about your sustainability initiatives, and so on.

We have all heard the hype about how AI has been revolutionizing how marketers approach experimentation. Generative AI offers new opportunities for optimizing every aspect of the user journey, allowing marketers to:

• streamline testing,
• create new online experiences, 
• and create new types of user segments for more precise personalized experiences that drive conversions.

This guest blog post was written by Rodolphe Dougoud, Project Lead at fifty-five—a leading data company that helps brands harness the potential of Generative AI and mitigate associated risks effectively with a comprehensive and pragmatic AI strategy, among other services. 

Below, we’ll explore these three perspectives in depth, with real-life examples gleaned from AB Tasty’s new algorithm, Emotions AI, and fifty-five’s work with its clients around GenAI. 

AI in Action for Experiences that Matter

1. Streamline testing

When thinking about A/B testing, you might immediately picture creating an experiment and launching it live on a website. However, the most time-consuming phases of the A/B testing process generally come before and after that: finding new features to try out in order to create a testing roadmap and analyzing the results of these tests. Here, AI can increase test velocity by helping to reduce bottlenecks hindering both of the aforementioned stages.

Test ideation

Your roadmap must not only be top-down but also bottom-up: pay close attention to insights from your UX designers, based on benchmarks from your competitors and industry trends, and data-driven insights based on your own analytics data. Here, AI can facilitate the process by analyzing large datasets (e.g., on-site Analytics data) to find insights humans might have missed.

Result analysis

Similarly, it’s essential to analyze the results of your tests thoroughly. Looking at one KPI can sometimes be enough, but it often represents only one part of a bigger story. An aptly-calibrated AI model can find hidden insights within your testing results. 

While we generally know what data we want to access, the actual querying of that data can be time-consuming. Applying a GenAI model to your dataset can also allow you to query your data in natural language, letting the model pull the data for you, run the query, and create instant visualizations for major time gains.

Content creation

While not necessary for most tests, creating new content to be included in the testing phase can take a long time and impact your roadmap. While GenAI cannot produce the same quality of content as your UX team, a UX designer equipped with a GenAI tool can create more content faster. The model used can be trained with your design chart to ensure it integrates with the rest of your content. Overall, adding a GenAI tool as a complement to your design arsenal can yield substantial gains in productivity and, therefore, reinforce your testing roadmap timeline.

2. Create new online experiences

Marketers should not hesitate to experiment with AI to create unique and interactive experiences. Generative AI can create personalized content and recommendations that can engage users more effectively. 

Consider, for instance, fifty-five’s recent work with Chronodrive, a grocery shopping and delivery app. We used AI to address a common user challenge (and, frankly, near-universal issue): deciding what to make for dinner. 

With our innovative solution, taking a picture of the inside of your fridge will allow the app to create a recipe based on the ingredients it identifies, while a photo of a dish – taken at a restaurant or even downloaded from social media – will generate a recipe for said dish and its associated shopping list. 

 Artificial Intelligence opens new creative options that weren’t available with previous LLM models. Chronodrive’s solution may not be applicable to most companies, but every business can think back on their typical user’s pain points and conceptualize how GenAI could help ease them.

3. Create new types of user segments for more precise personalized experiences

When a customer enters a store, a salesperson can instantly personalize their experience by checking if they want to be helped or just want to browse, if they are discovering the brand or are already sold on it, if they require guidance or know precisely what they want… A website, on the other hand, necessitates extra effort to present the user with a similarly personalized experience. 

Online, segmentation thus becomes indispensable to deliver the most satisfying user experience possible. Even during testing phases, deploying A/B tests on user segments makes achieving significant results more likely, as increased precision helps mitigate the risk of obtaining neutral results.

AI can analyze a wide array of user interactions on a given website to determine which elements drive the most conversions, or how different users respond to specific stimuli. This analysis can allow brands to classify users into new segments that could not have been available otherwise. For instance, fifty-five applied AI to split Shiseido’s website users between low and high-lifetime value segments. This allowed Shiseido to run differentiated A/B tests and personalize their website depending on the expected lifetime value of the user, resulting in a 12.6% increase in conversions.

Going even further, what if AI could read your emotions? AB Tasty’s new AI algorithm, Emotions AI, can automatically segment your audience into 10 categories based on emotional needs. 

• If a user needs to be reassured, the website can emphasize its free return policy
• If they need clarity, the website can highlight factual information about your product
• And if they need immediacy, the website can hide any unnecessary information to instead focus on its main CTAs

The model estimates the needs of the user by taking into consideration all of their interactions with the website: how long they wait before clicking, whether they scroll through an entire page, where their mouse hovers, how many times they click, etc. This enables stronger personalization, both during testing phases and when deploying online features, by letting you know exactly what your users need. 

Want to Learn More?

If you would like to dive deeper into current experimentation trends, watch our webinar replay here, where fifty-five and AB Tasty explored key CRO case studies and more. And if you have any questions or insights you’d like to share, please leave a comment – we would love to hear from you! 

The post From Clicks to Connections: How AI is Shaping the Future of Digital Optimization appeared first on abtasty.

This enables teams to reduce the risk of a big bang release that could lead to buggy features that could damage the user experience. This also prevents doing a full rollback and then implementing rollout all over again.

This ultimately means that software organizations are constantly releasing new updates and features to improve their products’ stability and quality and to deliver the best user experience possible.

Having a set plan in place to introduce new features allows teams to roll out releases to gather feedback and optimize accordingly before going for a full release. 

What is a feature rollout plan?

A feature rollout, as the name implies, is when new product features (or updates to existing features) are released to end-users. It’s all the processes that go into gradually introducing a feature to a set of users to test its functionality before deploying to all your users.

Put simply, the main purpose of a feature rollout plan is to keep all teams involved in the development and release of new features on the same page by making it easier to identify what are the key elements of each phase in the rollout.

Failure of efficiently managing the release of these new features could potentially lead to low quality releases and a negative impact on the user experience. This could all severely damage a company’s reputation and competitiveness in a world where customer expectations are at an all time high. In that sense, a solid rollout plan will ensure more adoption of the software by your customers and improved and more organized workflows for all teams involved. 

Therefore, it’s generally recommended to put together a detailed, robust plan early on in the development process and not scramble at the last minute as this plan will require meticulous planning to ensure the successful release of your new features.

Feature rollout process

It’s important to first highlight the steps involved in a feature rollout so teams can effectively incorporate the requirements of each phase into their planning. 

Typically, the rollout process is divided into the following phases:

• Design and planning – Define your objectives and KPIs, key stakeholders involved, set deliverables and communicate this plan to teams. This includes determining which features to prioritize and release to create the rollout plan accordingly.
• Develop rollout strategy – Identify your target users whose needs are best addressed with the new feature and determine how you will give them access to your new features- your deployment strategy.
• Build the feature and manage its progress throughout the development process.
• Controlled rollout – validate and test your features with controlled rollouts using feature flags, for example.
• Collect feedback by putting in place a constant feedback loop.
• Full release – once the feature has been optimized and refined according to the feedback collected, it is ready to be released to all users.

You will also need to identify and anticipate any potential roadblocks and challenges along the way in your planning and address them early on.

As you advance in the rollout process, plan in-house training sessions and a user onboarding strategy as well as proper documentation to support your feature rollout to serve as a guide for users (both internal and external) to understand the feature in-depth and its value proposition.

Therefore, based on the above, your rollout plan should ideally include the following components to make sure your releases go without any hiccups:

• Main objective and goals for each phase
• Action steps and the teams involved 
• Timeframe to provide clarity and set expectations for all teams
• Metrics to observe
• Checkpoints to monitor progress and ensure the project stays on track

Best practices to creating the ideal plan

All in all, to have an efficient rollout plan at hand, you can follow these best practices:

Start early

As already mentioned, you need to draw up your plan early, way before the development and deployment stages. For a successful feature launch, you should start working on your rollout plan as soon as the development process kicks off.  

Planning a seamless feature rollout could take months so the earlier you start considering all the elements within your plan, the easier it will be to keep your teams aligned and avoid any mishaps along the way.

Be flexible 

It’s important that your plan allows for enough flexibility and can be adapted throughout the development process. This means your rollout plan shouldn’t be so rigid that it cannot be updated as priorities and timelines continuously shift throughout the software development lifecycle. 

Define a clear rollout strategy

Your rollout plan will revolve around what strategy you’re adopting to roll out your new features. This means you need to determine how you’ll be rolling out your new features and the type of deployment strategy that is best suited to your new feature.

For example, should you choose a small group of beta users to opt in to test your product first to collect feedback and optimize your product before going for a full launch? Or is it better to run alpha testing on internal users first before releasing to real-world users?

Alternatively, you may decide to do a progressive rollout using canary deployment where you start with a small percentage of your users then expand the rollout process gradually until it’s released to all your users.

Set a tentative timeline

Being flexible is not equal to not having deadlines. You need to set a rough timeline of your rollout process with a clear rollout date that your team should target.

Setting a realistic timeline creates accountability by allowing individuals to outline their own responsibilities and build a personal roadmap that defines smaller deadlines leading up to the rollout release.

Set milestones

Setting key milestones in your feature rollout plan can be useful to further keep all stakeholders aligned and in sync throughout the project. This will allow them to clearly monitor as the software goes from one stage of the rollout to the next to track its progress by establishing clearly defined roadmaps for success. 

Keep stakeholders in the loop

As we’ve seen, a feature rollout process requires coordination and collaboration between stakeholders and multiple teams across an organization.

Early on, establish a core team including relevant and key stakeholders from each department to get their input on key decisions in the rollout process and provide them with all the information needed to understand the value of the new feature and to ensure a successful rollout. 

Outline an external communication plan

So you’ve developed and released your new feature but how do you make sure that your target users know about your exciting new releases?

You will need to make sure that you set a communication strategy so that customers know your software release is available. This is particularly important when you’re releasing new changes or updates to your features so customers know you’re continuously striving to improve your products.

Afterwards, you will also have to determine how you will start collecting the feedback you need to reiterate your products throughout the rollout process.

However, as we’ve mentioned in the previous point, make sure that your communication strategy includes all relevant stakeholders, external and internal users, and your  customer-facing teams. Clear and consistent communication is required from top management so that teams are aware of and understand the vision and strategy behind any new feature. 

Why do you need a feature rollout plan?

One of the biggest advantages of a feature rollout plan is that it allows for enhanced collaboration and communication among teams involved in the feature rollout process.

A rollout plan helps keep teams on the same page and move forward towards the same objectives to get your software into the hands of your users. In that sense, feature rollouts usually require the close collaboration of many teams and not just development teams so a plan helps different teams aligned around the same end-goals.

Furthermore, as new features are gradually introduced to users, such a plan enables careful planning. Thus, it gives teams more control over the release process by carefully planning who gets to see the new feature and when. 

We also mentioned the importance of identifying any potential roadblocks in your feature rollout process. A rollout plan can facilitate the discovery of these roadblocks and anticipate them so you can work on removing them so they don’t interfere with the new feature release. Otherwise, you might end up coming across these roadblocks when it’s way too late in the process significantly delaying your release. 

Above all, a rollout plan’s primary purpose is to manage and mitigate any potential risk among which includes a backup plan in case things go awry during the rollout process to minimize negative impact on your user base as much as possible.  

Feature flags: The foolproof ingredient for successful rollouts

There are many ways and strategies to roll out new features, one of which includes the use of feature flags.

Feature flags are a powerful software development tool that allows teams to mitigate risk of release by separating code deployment from release.

This means that teams can hide new features behind a flag and turn them on for certain user segments while keeping them switched off for the rest while they monitor performance and impact on KPIs.

Feature flags, therefore, are an essential ingredient in your feature rollout plans for your teams to have more control over their releases and perform gradual rollouts of new features to gather necessary feedback.

There are many deployment and rollout strategies you can use alongside feature flags including A/B testing, canary deployments and blue/green deployments to test new features before committing to a full rollout.

Your release strategy can also be more specific. For example, you can choose to release your feature to users in a certain country while keeping them turned off for everyone else.

Keep reading: How you can use feature flags for risk-free deployments for a more optimized user experience 

Plan for success

Feature rollout is not a one-time event. Rather, it’s a continuous process that many teams will need to partake in. 

For that reason, releasing and implementing new features can be very stressful.There are a lot of elements and risks involved in the process, which means having a clear plan in place can make the process much easier. 

A well-designed plan is key to providing a structured framework or blueprint to plan and execute the rollout process efficiently and it’s also an indispensable tool when it comes to successful implementation and coordination among teams.

Ultimately, the success of any project will depend on how well cross-functional teams work together towards shared objectives by communicating, defining clear goals, adapting quickly to changes as they occur while staying motivated and productive.

The post Feature Rollout Plan 101: Create the Perfect Plan for Stress-Free Releases appeared first on abtasty.

CHALLENGE

The Whitepages’ marketing team set a goal to increase conversion rate and boost memberships for their monthly plan by improving the structure of the pricing page and make it easier for customers to compare the different plans.

TEST IDEA

The layout of the price subscription page was changed so that all three plans were more prominently displayed next to each other in the form of expanded vertical menus to clearly showcase what’s included in each plan. 

Dynamic toggles were also placed at the top so users could compare monthly and annual pricing plans while the bottom of the page featured a larger payment tab under the plans instead of next to them.

RESULTS

With the new layout, the team was able to present a simpler and easier navigation for Whitepages customers to seamlessly compare different plans with just the right amount of information they need to make a decision.

As a result, after one week, the team saw a 23% increase in conversion rate and a 31% increase in monthly membership plans.

TAKEAWAYS

Feature experimentation has given the Whitepages team the ability to quickly make adjustments while running a test, target a specific audience, and turn on or off a test or device type. This has given the marketing team greater flexibility and autonomy without relying on engineering sources which resulted in faster workflows.

The test involved more complex and dynamic elements (such as the inclusion of the contact’s record of the current plan to which the user is subscribed). This required each of these elements to interact with the entire IT system, which was only possible through server-side testing. The team plans to continue using server-side experimentation to test pricing pages to drive more conversions for the plan upgrades for current members and new users.

The post Whitepages Boosts Subscriptions with AB Tasty’s Feature Experimentation appeared first on abtasty.

With a focus on feature experimentation – this webinar will showcase app experience.

Sapphire Samiullah, Senior Product Lead at Student Beans, and John Hughes, Senior Partner Marketing Manager at AB Tasty, showcase how they use data-driven insights to optimize their customer journey.

Learn about:

• Optimizing for app performance
• How Student Beans organize their team to get better results 
• Ideas for tests, sprints and continuous improvement 
• Real experiments that have worked

Outlining Student Beans brand approach to drive CX innovation and deliver impactful results.

The post Elevating Customer Engagement with Student Beans appeared first on abtasty.

Undoubtedly, feature flags become increasingly important as engineering and product teams begin to see their benefits. By separating code deployment from feature release, teams can now deliver new functionalities to users safely and quickly.

Feature flags are also extremely versatile and their uses can extend to a number of different scenarios to achieve various tasks by all teams across your organization. As feature flags help developers release faster with lower risk, it makes sense that teams would want to extend their usage across these additional use cases.

We can look at feature flag implementation as a journey that is used initially for one simple use case and which then evolves to more advanced implementations by different stakeholders. This article will illustrate this journey by introducing you to the different use cases of feature flags from simple to more complex and to help you consider whether it is in your best interest to build or buy a feature flag management system according to your goals.

Are you looking for a feature flagging solution packed full of features with an easy-to-use dashboard? AB Tasty is the all-in-one feature flagging, rollout, experimentation and personalization solution that empowers you to create a richer digital experience — fast.

The value of feature flags

Before we go deeper into the build vs buy topic, it’s important to highlight exactly why you need feature flags in your daily workflows and the value they can bring to your teams.

As we’ve mentioned, feature flags can be used across a range of use cases. Here’s a quick overview of when feature flags are especially handy:

• User targeting and feature testing: When you have a new feature but you’re not yet ready for a big bang release; instead, you want to have the control to target who sees this new feature to collect necessary feedback for optimization purposes.
• Testing in production: When you want to test a production by gradually rolling out a new feature or change to validate it.
• Kill switch: When you want to have the ability to quickly roll back a feature in case anything goes wrong and turn it off while the issue is being fixed.
• Migrations: Feature flags offer a low-risk way to perform architectural or database migrations such as migrating from a monolith architecture to microservices. 

This means that feature flags are a great way to continuously (and progressively) roll out releases with minimal risk by controlling who gets access to your releases and when. 

The journey begins with a simple step: if/else statements

A feature flag in a code is essentially an IF statement. Here is a very straightforward, basic example:

Therefore, you can just be starting off with a simple if/else statement, usually reserved for short-lived flags but less so if you’re planning to keep the flag around for a long time or for other more advanced use cases which require more sophistication. Therefore, feature flags have evolved beyond one use case and can serve a variety of purposes. Inserting a few IF statements is easy but it’s actually maintaining a feature flag management system that’s hard work; it requires time, resources and commitment. 

You can implement a feature flag by reading from a config file in order to control which code path will be exposed to your subset of users. Using a config file at the beginning may seem like a viable solution but in the long-term may not be so practical, resulting in technical debt that accumulates over time.

Keep reading: Best practices on storing feature flags.

Here, a simple flagging solution will not suffice and so you would need to turn to a more advanced solution. Implementing the solution you need in-house can be quite costly and requires a lot of maintenance. In this case, you can turn to a third-party option.

Bumps along the road: Evolving use cases

When you’re just starting out, you’ll implement a feature flag from a config file with an easy on/off toggle to test and roll out new features. Sounds simple enough. Then, one flag turns into 10 or 20 and as you keep adding to these flags leading to the aforementioned technical debt issue as it becomes harder to pinpoint which of your active feature flags need to be removed. In this case, a proactive approach to managing your flags is essential in the form of a comprehensive feature flag management system.

Therefore, at the start of your feature flag journey, you may simply be employing one use case which is experimentation through release management but over time, you may want to implement feature flags across a variety of use cases once you’ve seen first-hand the difference feature flags are making to your releases. 

Test in production

You may for example want to test in production but only internally so you expose the feature to people within your organization. You may also use feature flags to manage entitlements, that is a small subset of users can access your feature, such as users with a premium subscription to your product or service. These types of flags are referred to as permission toggles. So you will need to build a system that can handle different levels of permissions for different users.

Indeed, one of the most important uses for feature flags is the ability to toggle features on or off for a certain subset of users. This use case is referred to as testing in production, which is essential to verify that your feature works as it should in real time and allows you to easily roll back the feature if it turns out to be buggy resulting in safer releases.

To be able to carry out such controlled roll-outs, your feature flagging system should enable you to make such context-specific flagging decisions, for example, for carrying out A/B tests. 

So, for example, you might want to expose your feature to 5, 10 or 15% of your users or you might be looking to test this feature on users from a certain region. A good feature management system provides the means necessary to take such specific contexts when making flagging decisions. Therefore, such contexts can include additional information about the user so here we take into consideration the server handling the request as well as the geographic market the request is linked to.

Read more in our guide to running sophisticated A/B tests with feature flags.

Choose your players

As a result, feature flags allow you to choose who you want to release your feature to, so the new code can be targeted to a specific group of users whose feedback you need. This would require you to have a system in place that would allow you to perform feature experimentation on those users and attach KPIs to your releases to monitor their reception. However, some companies may not have the time or resources or even experience to collect this kind of rich data.  

Kill switches

Feature flags can be used to kill off non-essential features or disable any broken features in production. Therefore, as soon as your team logs an error, they can easily turn off the feature immediately with the click of a button while your team investigates the issue. This would require your team to have a 2-way communication pathway between monitoring tools and the internal flag system that could be complex to set-up and maintain. The feature can then just as easily be turned on again once it’s ready for deployment. Such kill switches usually require a mature feature flag service implementation platform.

Feature flag hell

We can conclude that when implementing feature flags, you must continuously be aware of the state of each of your feature flags. Otherwise, you could find yourself becoming overwhelmed with the amount of flags in your system leading you to lose control of them when you’re unable to keep track of and maintain them properly. Things could get complicated fast as you add more code to your codebase so you need to make sure that the system you have in place is well-equipped to handle and reduce those costs. 

You’ve probably already come across the term ‘merge hell’ but there’s also such a thing as ‘feature flag hell’. This is basically when you add too many feature flags which can convert your code into the nightmare that is ‘feature flag hell’.

As mentioned above, you can start off with a simple if/else statement but more sophistication will be needed to implement these more advanced use cases.

It is also important to be able to manage the configuration of your in-house system. Any small configuration change can have a major impact on the production environment. Therefore, your system will need to have access controls, audit logs and custom permissions to restrict who can make changes. 

Your system will also need to have an environment-aware configuration that supports a flag configuration from one environment to the next. Most systems should be able to create two kinds of environments: one for development and one for production with its own SDK key. Then you would be able to control the flag’s value depending on which of these environments it’s being used. For example, the flag could be ‘true’ in development but ‘false’ in production. 

Having different environments prevents you from accidentally exposing something in production before you are prepared. When you have all these flags across different environments, it becomes harder to keep everyone in sync, which leads us back to the issue of ‘feature flag hell’ if you don’t have the right system in place.

Feature flags categorization

With such sophisticated use cases, it would not make sense to place feature flags under one category and call it a day. Thus, here we will talk about feature flags when it comes to their longevity and dynamism.

Static vs dynamic

The configuration for some flags will need to be more dynamic than for others. Flipping a toggle can be a simple on/off switch. However, other categories of toggle are more dynamic and will require more sophisticated, very context-specific flagging decisions which are needed for advanced use cases such as A/B testing. For example, permission toggles, usually used for entitlements mentioned earlier, tend to be the most dynamic type of flag as their state depends on the current user and are triggered on a user basis. 

Long- vs short-lived

We can also categorize flags based on how long the decision logic for that flag will remain in the codebase. On the one hand, some flags may be transient in nature, such as release toggles, which can be removed within a few days where the decision logic can be implemented through a simple if/else statement. On the other hand, for flags that will last longer then you’ll need to use more maintainable implementation techniques. Such flags include permission toggles and kill switches.

Therefore, it is important that your feature management solution can keep track of all the flags by determining which flag is which and indicating which flags need to be removed that are no longer needed or in use.

Challenges of an in-house system

As use cases grow so do the challenges of developing an in-house feature flagging system. Among the challenges organizations face when developing such a system include:

• Many organizations will start out with a basic implementation where config changes would need to be made manually so the config change for every release will need to be made manually, which is time-consuming. Similarly, when rolling out releases, compiling customer IDs will also be done manually so keeping track of the features rolled out to each user would prove to be a major challenge.

• Most of these manual processes would be carried out by the engineering team so product managers would be unable to make changes from their end and so will be dependent on engineers to make those changes for them.

• The preceding point also raises the question of what you want your engineers to devote their time to. Your engineers will need to dedicate a large chunk of their time maintaining your in-house feature flagging tool which could divert their attention from building new features that could drive revenue for your company.

• This ties to a lack of a UI that could serve as an audit log tracking to monitor when changes are made and by who. The lack of a UI will also mean that only engineers can control feature rollouts while product managers cannot do such deployments themselves or view which features are rolled out to which users. Thus, a centralized dashboard is needed so that all relevant stakeholders can monitor feature impact.

• As mentioned previously, inability to monitor and clean up old flags will become increasingly difficult as more flags are generated. When flag adoption increases, people across your organization will find it more difficult to track which flags are still active. 

Eventually, if your team does not remove these flags from the system, technical debt would become a major issue. Even keeping track of who created which flag and for what purpose could become a problem if the in-house system doesn’t provide such data.

Thus, while the advantages of feature flags are numerous, they will be far outweighed by the technical debt you start to accumulate over time that could slow you down if you are not able to take control and keep track of your feature flags’ lifecycles.

• There are often high costs associated with maintaining such in-house tools as well as costs associated with upgrades so over time you will see such costs as well as your technical debt accumulating over time. 
• Besides the rising costs, building and maintaining a feature flagging system requires ample resources and a high degree of technical expertise as such systems require a solid infrastructure to handle large amounts of data and traffic, which many smaller organizations lack.

• Such in-house tools are usually built initially to address one pain point so they have minimal functionality and thus cannot be used widely across teams and lack the scalability required to handle a wide range of uses and functions.

• Time taken to develop feature flag solutions could be time lost that you could have spent developing features for your customers so you will need to consider how much time you are willing to dedicate to developing such a system. 

On the other hand:

• Buying a platform from a third-party vendor can be cost-effective which means you can avoid the associated costs with building a platform. There are also ongoing costs associated with buying a platform but with many options out there, companies can find a platform that suits their needs and budget.
• Third-party systems typically come with ongoing support and maintenance from the vendor including comprehensive documentation so you wouldn’t have to worry about handling the upkeep for it yourself or the costs associated to maintain the platform to handle large-scale implementations.
• Perhaps one of the biggest advantages of buying a solution is its immediate availability and market readiness as the solution is ready-made with expert support and pre-existing functionalities. Thus, you can save valuable time and your teams can quickly implement feature flags in their daily workflows to accelerate releases and time-to-market. 
• Time dedicated to building and maintaining your in-house solution could otherwise be spent developing innovative and new revenue-generating features.

Safe landing: How to proceed

To ensure a safe arrival at the final spot of your feature flag journey (depending on why and how you’re using feature flags), you will need to decide whether in-house or a third-party solution is what’s right for you. With each additional use case, maintaining an in-house solution may become burdensome. In other words, as the scope of the in-house system grows so do the challenges of building and maintaining your in-house system.

Let’s consider some scenarios where the “buy” end of the argument wins:

• Your flag requirements are widening: your company is experiencing high growth- your teams are growing and different teams beyond development and engineering are becoming more involved in your feature flag journey, who in turn have different requirements. 
• With increasing flag usage and build-up, it’s become harder to keep track of all them in your system eventually leading to messy code.
• You’re now working with multiple languages that maintaining SDKs may become highly complex.
• You have an expanding customer-base which means higher volume of demand and release velocity leading to strained home-grown systems.
• You need more advanced features that can handle the needs of more complex use cases. In-house systems usually lack advanced functionalities as they are usually built for immediate needs unlike third-party tools that come equipped with sophisticated features.

All these different scenarios illustrate the growing scope of feature flag usage which in turn means an increase in scope for your feature flagging system, which could pose a serious burden on in-house solutions that often lack the advanced functionalities to grow as you grow. 

Many third-party feature flagging platforms come equipped with a user-friendly UI dashboard that teams can easily use to manage their feature flag usage.

Using AB Tasty’s Feature Experimentation and Rollouts, all teams within an organization from development to product can leverage to streamline the software development and delivery processes. Product teams can run sophisticated omnichannel experiments to get critical feedback from real-world users while development teams can continuously deploy new features and test in production to validate them.

Teams also have full visibility over all the flags in their system in our “flag tracking dashboard” where they can control who gets access to each flag so when the time comes they can retire unused flags to avoid build-up of technical debt. 

Feature flag system is a must

At this point, you may decide that using a third-party feature flag management tool is the right choice for you. Which one you opt for will largely depend on your needs. As already pointed out, implementing your own solution is possible at first but it can be quite costly and troublesome to maintain. 

Keep in mind the following before selecting a feature flag solution:

• Pain points: What are your goals? What issues are you currently facing in your development and/or production process?
• Use cases: We’ve already covered the many use cases where feature flags can be employed so you need to consider what you will be using feature flags for. You also need to consider who will be using it (is it just your developers or are there stakeholders involved beyond developers such as Product, Sales, etc?)
• Needs and resources: Carefully weigh the build vs buy decision taking into account factors such as total costs and budget, the time required to build the platform, the scope of your solution (consider the long-term plan of your system), whether there is support across multiple programming languages-the more languages you use, the more tools you will need to support them.

Following the aforementioned points, your feature flagging management system will need to be: stable, scalable, flexible, highly-supported and multi-language compatible.

It’s more than fine to start simple but don’t lose sight of the higher value feature flags can bring to your company, well beyond the use case of decoupling deploy from release. To better manage and monitor your flags, the general consensus is to rely on a feature flag management tool. This will make feature flags management a piece of cake and can help speed up your development process. 

With AB Tasty, formerly known as Flagship, we take feature flagging to the next level where we offer you more than just switching features on and off, offering high performance and highly scalable managed services. Our solution is catered not just to developers but can be widely used across different teams within your organization. Sign up for a free trial today to learn how you can ship with confidence anytime anywhere.

Download our build vs buy debate e-book to help guide you further in your decision. 

The post Feature Flags: Should I Build or Buy? appeared first on abtasty.

This means long before the code is written and tested, teams need to carefully plan the deployment process of new features and/or updates to ensure it won’t negatively impact the user experience.

Having an efficient deployment strategy in place is crucial to ensure that high quality software is delivered in a quick, efficient, consistent and safe way to your intended users with minimal disruptions. 

In this article, we’ll go through what a deployment strategy is, the different types of strategies you can implement in your own processes and the role of feature flags in successful rollouts.

What is a deployment strategy?

A deployment strategy is a technique adopted by teams to successfully launch and deploy new application versions or features. It helps teams plan the processes and tools they will need to successfully deliver code changes to production environments.

It’s worth noting that there’s a difference between deployment and release though they may seem synonymous at first.

Deployment is the process of rolling out code to a test or live environment while release is the process of shipping a specific version of your code to end-users and the moment they get access to your new features. Thus, when you deploy software, you’re not necessarily exposing it to real-world users yet.

In that sense, a deployment strategy is the process by which code is pushed from one environment into another to test and validate the software and then eventually release it to end-users. It’s basically the steps involved in making your software available to its intended users.

This strategy is now more important than ever as modern standards for software development are demanding and require continuous deployment to keep up with customer demands and expectations.

Having the right strategy will help ensure minimal downtime and will reduce the risk of errors or bugs so users get the best experience possible. Otherwise, you may find yourself dealing with high costs due to the number of bugs that need to be fixed resulting in disgruntled customers which could severely damage your company’s reputation.

Types of deployment strategies

Teams have a number of deployment strategies to choose from, each with their own pros and cons depending on the team objectives. 

The deployment strategy an organization opts for will depend on various factors including team size, the resources available as well as how complex your software is and the frequency of your deployment and/or releases.

Below, we’ll highlight some of the most common deployment strategies that are often used by modern software development and DevOps teams.

Recreate deployment

Image 

A recreate deployment strategy involves developers scaling down the previous version of the software to zero in order to be removed and to upload a new one. This requires a shutdown of the initial version of the application to replace it with the updated version.

This is considered to be a simple approach as developers only have to deal with one scaling process at a time without having to manage parallel application deployments. 

However, this strategy will require the application to be inaccessible for some time and could have significant consequences for users. This means it’s not suited for critical applications that always need to be available and works best for applications that have relatively low traffic where some downtime wouldn’t be a major issue.

Rolling deployment

Image

A rolling deployment strategy involves updating running instances of the software with the new release.

Rolling deployments offer more flexibility in scaling up to the new software version before scaling down the old version. In other words, updates are rolled out to subsets of instances one at a time; the window size refers to the number of instances updated at a time. Each subset is validated before the next update is deployed to ensure the system remains functioning and stable throughout the deployment process.

This type of deployment strategy prevents any disruptions in service as you would be updating incrementally- which means less users are affected by any faulty update- and you would then direct traffic to the updated deployment only after it’s ready to accept traffic. If any issue is detected during a subset deployment, it can be stopped while the issue is fixed. 

However, rollback may be slow as it also needs to be done gradually.

Blue-green deployment

Image

A blue/green deployment strategy consists of setting up two identical production environments nicknamed “blue” and “green” which run side-by-side, but only one is live, receiving user transactions. The other is up but idle.

Thus, at any given time, only one of them is the live environment receiving user transactions- the green environment that represents the new application version. Meanwhile, teams use the idle blue system as the test or staging environment to conduct the final round of testing when preparing to release a new feature.

Afterwards, once they’ve validated the new feature, the load balancer or traffic router switches all traffic from the blue to the green environment where users will be able to see the updated application.

The blue environment is maintained as a backup until you are able to verify that your new active environment is bug-free. If any issues are discovered, the router can switch back to the original environment, the blue one in this case, which has the previous version of the code.

This strategy has the advantage of easy rollbacks. Because you have two separate but identical production environments, you can easily make the shift between the two environments, switching all traffic immediately to the original (for example, blue) environment if issues arise.

Teams can also seamlessly switch between previous and updated versions and cutover occurs rapidly with no downtime. However, for that reason this strategy may be very costly as it requires a well-built infrastructure to maintain two identical environments and facilitate the switch between them.

Canary deployment

Image

Canary deployments is a strategy that significantly reduces the risk of releasing new software by allowing you to release the software gradually to a small subset of users. Traffic is directed to the new version using a load balancer or feature flag while the rest of your users will see the current version 

This set of users identifies bugs, broken features, and unintuitive features before your software gets wider exposure. These users could be early adopters, a demographically targeted segment or a random sample.

Therefore, you start testing on this subset of users then as you gain more confidence in your release, you widen your release and direct more users to it. 

Canary deployments are less risky than blue-green deployments as you’re adopting a gradual approach to deployment instead of switching from one environment to the next. 

While blue/green deployments are ideal for minimizing downtime and when you have the resources available to support two separate environments, canary deployments are better suited for testing a new feature in a production environment with minimal risk and are much more targeted.

In that sense, canary deployments are a great way to test in production on live users but on a smaller scale to avoid the risks of a big bang release. It also has the advantage of a fast rollback should anything go wrong by redirecting users back to the older version.

However, deployment is done in increments, which is less risky but also requires monitoring for a considerable period of time which may delay the overall release.

A/B testing

Image

A/B testing, also known as split testing, involves comparing two versions of a web page or application to see which performs better, where variations A and B are presented randomly to users. In other words, users are divided into two groups with each group receiving a different variation of the software application. 

A statistical analysis of the results then determines which version, A or B, performed better, according to certain predefined indicators.

A/B testing enables teams to make data-driven decisions based on the performance of each variation and allows them to optimize the user experience to achieve better outcomes.

It also gives them more control over which users get access to the new feature while monitoring results in real-time so if results are not as expected, they can redirect visitors back to the original version.

However, A/B tests require a representative sample of your users and they also need to run for a significant period to gain statistically significant results. Moreover, determining the validity of the results without a knowledge database can be challenging as several factors may skew these results.

AB Tasty is an example of an A/B testing tool that allows you to quickly set up tests with low code implementation of front-end or UX changes on your web pages, gather insights via an ROI dashboard, and determine which route will increase your revenue.

Feature flags: The perfect companion for your deployment strategy

Whichever deployments you choose, feature flags can be easily implemented with each of these strategies to improve the speed and quality of the software delivery process while minimizing risk. 

By decoupling deployment from release, feature flags enable teams to choose which set of users get access to which features to gradually roll out new features.

For example, feature flags can help you manage traffic in blue-green deployments as they can work in conjunction with a load balancer to manage which users see which application updates and feature subsets. 

Instead of switching over entire applications to shift to the new environment all at once, you can cut over to the new application and then gradually turn individual features on and off on the live and idle systems until you’ve completely upgraded.

Feature flags also allow for control at the feature level. Instead of rolling back an entire release if one feature is broken, you can use feature flags to roll back and switch off only the faulty feature. The same applies for canary deployments, which operate on a larger scale. Feature flags can help prevent a full rollback of a deployment; if anything goes wrong, you only need to kill that one feature instead of the entire deployment. 

Feature flags also offer great value when it comes to running experiments and feature testing by setting up A/B tests by allowing for highly granular user targeting and control over individual features.

Put simply, feature flags are a powerful tool to enable the progressive rollout and deployment of new features, run A/B testing and test in production. 

What is the right deployment strategy?

Choosing the right deployment strategy is imperative to ensure efficient, safe and seamless delivery of features and updates of your application to end-users. 

There are plenty of strategies to choose from, and while there is no right or wrong choice, each comes with its own advantages and disadvantages. 

Whichever strategy you opt for will depend on several factors according to the needs and objectives of the business as well as the complexity of your application and the type of targeting you’re looking to implement i.e whether you want to test a new feature on a select group of users to validate it before a wider release.

No matter your deployment strategy, AB Tasty is your partner for easier and low risk deployments with Feature Experimentation and Rollouts. Sign up for a free trial to explore how AB Tasty can help you improve your software delivery processes.

The post Rollout and Deployment Strategies: Definition, Types and the Role of Feature Flags in Your Deployment Process appeared first on abtasty.

First, let’s start with a simple definition of feature flags. A feature flag is a software development technique that lets you turn functionalities on and off to test new features in production without changing code.

This means that feature flags significantly accelerate software development processes while giving teams greater control and autonomy over releases.

Keep reading: Our complete guide to feature flagging

This is a technique that can be employed by all teams in an organization across a wide range of use cases, from the most simple to more advanced uses to improve their daily workflows. 

In this article, we will explore these different uses to illustrate what feature flags can do across different contexts depending on your pain points and objectives.

Feature flags examples and use cases

Many of the use cases outlined below allow teams to take back control of releases and enable them to deliver new features quickly and safely. There may be a bug in production and you want to turn it off without delaying the release or you have second thoughts about a feature and you’re not ready for all your users to see it so you’d rather test this feature on a subset of users. 

Feature flags also increase productivity and speed of teams. You’re no longer waiting to merge your code if other changes are incomplete; you just put it behind a flag until it’s ready. With this, you get more predictability to your releases. There’s no need to delay your release cycle for any last-minute bugs detected. 

Therefore, we will see how the use cases outlined below bring these benefits to your team.

• Prepare for launch
• Hassle-free deployments: Release anytime by decoupling release from deployment
• Experience rollouts and progressive delivery
• Time your launch
• Running experiments and A/B testing
• Continuous integration and continuous delivery
• Managing access: User targeting
• Risk mitigation
• Test in production
• Feature flags and mobile app deployment: Bypass app store validation
• Kill Switch: Feature rollback
• Sunsetting features
• Managing migrations
• Feature flags as circuit breakers
• Bottomline: Use feature flags often but proceed with caution

Prepare for launch

Hassle-free deployments: Release anytime by decoupling release from deployment

Feature flags allow you to deploy whenever you and your team sees fit. You no longer need to delay your releases. Any changes to a feature that are not yet ready can be toggled off with a switch.

What feature flags do in this scenario is separate code deployment from release. This is done through a release toggle, which allows specific parts of a feature to be activated or deactivated so any unfinished features will remain invisible to users until they are ready to be released. 

Why is the distinction between deployment and release significant? To answer this question, it is worth noting the difference between the two terms:

• Deployment is the process of putting code in its final destination on a server or any other place in your infrastructure where your code will run.
• Release is exposing your code to your end-users and so it is the moment when they get access to your new features.

This difference is why we talk about decoupling deployment from release because once you do that, you can push code anywhere, anytime, without impacting your users. Then, you can release gradually and selectively whenever you’re ready through progressive and controlled rollouts as we will see below.

Experience rollouts and progressive delivery

With feature flags, you are in complete control. This means once you have a feature ready for release, you can control which subset of users will see this feature through phased rollout of releases. 

When we talk about experience rollouts, we’re referring to the risk-free deployment of  features that improve and optimize the customer experience.

This is usually achieved through progressive rollouts, which builds on continuous delivery to include the use of feature flags to gradually introduce features to your users.

Rather than releasing to all your users, which is often risky, you may want to release to just 5% or 10% of your users. These users should represent your overall users. Meanwhile, the team observes how these users respond to the new feature before rolling out to everyone else. 

One progressive rollout technique is known as canary deployment. This is where you test how good your feature is on a small group of users and if there’s any issue, you can immediately fix it before it’s exposed to a larger number of users. This sort of gradual rollout helps mitigate the risk of a so-called big bang release. It also helps ease the pressure on your server in case it cannot handle the load.

You may also carry out what is known as ‘ring deployments.’ This technique is used to limit the impact on end-users by gradually rolling out new features to different groups. These groups are represented by an expanding series of rings, hence the name, where you start with a small group and keep expanding this group to eventually encompass all users. 

In a ring deployment, you choose a group of users based on similar attributes and then make the features available to this group. 

Rings and feature flags work together where feature flags can help you hide certain parts of your feature if they’re not ready in any of the deployment rings.

The advantage of such controlled rollouts is the feedback you would generate from users, especially for releases you’re less than confident about and so with the feedback received, you can improve your product accordingly.

Time your launch

We know at this point that feature flags give you the control to release at any time you deem suitable. Feature flags, then, are important because you always decide the ‘when.’ As such, with feature flags, you can aim for a timed launch where you push your feature for people in your trusted circle, such as your QA team, to test in production. 

Afterwards, when it’s time to launch, you simply turn on the feature for everyone else without any fuss with the added advantage that you’re feeling much more confident when it comes to the actual release to everyone else.

This significantly reduces stress among your team because you’ve tested the feature before the official launch and you’ve made sure it’s working as it should before going ahead with a wider release.

Running experiments and A/B testing

Feature flags are great for A/B tests, where you can assign a subset of users to a feature variation and see which performs better.

This is a great use for product and marketing teams who can easily test new ideas and eliminate them if they don’t fulfil the hypothesis defined upon creation of the test.

For example, feature flags would allow your product and marketing teams to send 50% of users to the new variation of a feature and the other 50% to the original one to compare performance according to the goals set and see which variation runs better according to the KPIs set.

Using feature flags to run A/B tests is particularly useful when a feature receives enough traffic to generate efficient results. So, as a cautionary note, keep in mind that not everything can be an A/B test when it comes to feature flags.

In this sense, you can look at feature flags like a light switch. You decide when you want to turn on the feature, when to turn it off and which users have access to it. This allows you to continuously test in production until you’re satisfied with the end-result which you can then roll out to the rest of your users.

Continuous integration and continuous delivery

Feature flags means developers no longer need multiple long-lived feature branches which more often than not lead to merge conflicts.

Let’s imagine you are all set to release but then one developer’s changes have not yet been integrated into the main feature branch. Does this mean you need to wait especially when you know time is precious when it comes to releasing to impatient customers in this day and age?

With this method, developers can integrate their changes, or commit code in small increments, much more frequently, perhaps even several times a day. Through trunk-based development, a key enabler of continuous integration, developers can merge their changes directly into the master trunk helping them move faster to ensure that code is always in a ready-to-be-released state. 

Consequently, we can deduce that feature flags also facilitate the process of continuous delivery.

Feature flags are essential to maintain the momentum of CI/CD processes because as mentioned, feature flags decouple deployment from release so even unfinished features can be merged but can easily be hidden behind a flag so users don’t see it while other changes can still be delivered to users without waiting on those unfinished features.

In other words, feature flags will still allow you to still continuously deploy your code so even if there is an incomplete feature, users won’t be able to access the functionality as it would be hidden behind a flag.

Read more: Feature flags and CI/CD: Increased velocity and less risk

Managing access: User targeting

You don’t just choose the when, you also choose to whom.

Feature flags, as we’ve seen, gives you a lot of control over the release process by putting the power of when to release in your hands. 

It‘s worth mentioning yet another form of power feature flags can give you, which is the ability to choose which users can access the feature. When you are testing in production, having the option to choose who you want to test on is extremely valuable depending on the kind of feedback you’re seeking.

Giving early access

We’ve seen in canary deployment that sometimes the sample you pick can be completely random. Other times, however, you might decide to carefully handpick a select group of users to give them early access to your new feature.

Why is this important? Because these are the users that are considered to be ‘early adopters.’ They are users you trust and whose feedback is top priority and who are most interested in this particular feature. These users are also the most forgiving should anything go wrong with the release.

With feature flags, you can release the feature to these early adopters who are more than willing to provide the kind of feedback you need to improve your product. This technique works well if you have a very risky release that you’re hesitant to release to a wider audience.

Power to the users: beta testing

Beta testing is another side to early access where in this scenario users willingly opt-in to test out your new features before they are released to the rest of your users.

As a result, the customers who opt-in get to see and test the feature by turning it on in their accounts and should they wish to back out they can easily disable the feature, which makes these users more inclined to opt-in in the first place as it makes them feel more in control.

This is an important use-case because it shows your customers that you’re really listening to their feedback by asking them to test your release. 

The users who opt-in are those who you’re targeting with this feature so how they react to the feature will be of extreme use to you. Hence, you get to test out your new feature and you deliver value to your customers by responding to their feedback; it’s a win-win situation!

Dogfooding

This term refers to eating your own dog food, or in this case refers to an organization using its own product or service. You can, therefore, look at it as a way to test in production on internal teams. 

It’s a form of alpha testing that you can run on internal users (within the organization) to make sure that the software meets all expectations and is working as it should. Thus, it represents an opportunity to evaluate the performance and functionality of a product release as well as obtain feedback from technical users.

This is a great way of testing to obtain meaningful feedback especially when you’re introducing new features or major changes that you’re not fully confident about. 

This way, you are taking less risks because it’s only people within your organization who can see the releases as opposed to your actual, external users who may be more unforgiving in case things take a bad turn during a release.

No trespassing allowed: blocking users

Just as you can pick users who you want to access your feature, you can also block users from seeing it. For example, you can block certain users from a particular country or organization.

What feature flags would allow you to do is hide some features from users who might not give you the right sort of feedback while giving access to the relevant target consumers who would be most impacted by the new feature. You can also target certain features for a certain type of user to provide a more personalized experience for them.

Managing entitlements

With feature flags, you can manage which groups of users get access to different features. This is especially common in SaaS companies that offer various membership plans and so with entitlements, you can dictate which features each plan can access. This way, you would be offering different experiences to your users.

Let’s take the example of Spotify. Spotify offers free and paid plans. With the free membership, you can stream music but with advertisements while with the premium membership, you can stream unlimited music with no ads. You also get unlimited skips and you can download music to listen to offline. There are also different levels of premium to choose from including student and family plans. Consequently, with each plan, you are entitled to different content and features.

With feature flags, you can wrap a flag around a feature and release it to a particular customer depending on their subscription plan. These types of flags are usually referred to as permission toggles. They also allow you to move features easily between the different plans i.e. paid and free versions, for example.

Managing entitlements is considered to be an advanced use case as it requires careful coordination across teams and involves working with multiple flags to control permissions for the features. The person who manages entitlements is usually on the product team so careful planning and monitoring of each change performed by which person is required. 

There should also be a seamless process in place to move users from one plan to another. Thus, this use case requires vigilant implementation.

Product demos and free trials

On a similar note, product and sales teams may be looking for a way to offer prospective customers a demo or a free trial or specialized demo of a feature.

Feature flags are a great way to give prospects temporary access to certain features under various pricing plans to give them a taste of through a live demo of the features among the higher plans so they can decide if an upgrade is worth it by simply toggling these features on with a flag then turning it off once the demo is complete. 

Risk mitigation

Test in production

Through the use of Feature flags, teams can confidently ship their releases by testing code directly in production to validate new features on a subset of users.

Unlike testing in a staging environment, when you test in a production environment, you can collect real-world feedback from live users to ensure that teams are building a viable pipeline of products.

Testing in production also allows you to uncover any bugs that you may have missed in the development stages and discern whether your new feature can handle a high volume of real-world usage and then optimize your features accordingly.

Feature flags and mobile app deployment: Bypass app store validation

This is when we use A/B testing to test different experiences within mobile apps. Imagine you’ve just released a brand new app or introduced a new shiny update to your app.

How can you make sure your app or this update is running smoothly or that you haven’t unintentionally introduced an update full of bugs that crashes on your users? Anything that goes wrong will involve a lengthy review process that will setback your entire release as you attempt to locate and resolve the issue.

You no longer need to wait for app store approval, which could take some time and the changes are released to all users instead of smaller segments.

Instead, with remote config implemented through feature flags, any changes can be made instantly and remotely and then released to a small subset of users to get feedback before releasing it to everyone else. Therefore, you can upgrade your app continuously in real-time based on feedback from your users without waiting on app store approval.

It’s also a good way to personalize experiences for different types of users rather than creating a unified experience for all users depending on the demographics you set forth. 

As a result, with feature flags, you can roll out different versions of your mobile app to monitor their impact by releasing different features to different groups of users. Afterwards, you can decide on what features will be incorporated in the final release of your app.

Using feature flags to test out your mobile app is an excellent way to generate buzz around your release by giving exclusive access to a select number of users.

Kill Switch: Feature rollback

Using feature flags will allow you to disable a feature if it’s not working as it should. This is done by using a kill switch. Thus, whenever anything goes wrong in production, you can turn it off immediately while your team fixes the issue. This would prevent you from having to roll back the entire release so other changes can be deployed and released without worrying about delaying the whole release.

With a kill switch, you can switch off a specific, troublesome feature so you can decrease the number of users who can see it, including turning it off for all users if necessary until the issue is analyzed and resolved by your team. This way, you won’t have to go through the entire code review process to locate the issue.

Kill switches therefore give you even more control over the release process. This not only empowers your team of developers but also marketing and production teams with no software development experience who can now easily test in production and kill a feature without having to rely on engineering support.

AB Tasty offers an automatic rollback option that enables you to stop the deployment of a feature and to revert all the changes that have been made in order to ensure that your feature isn’t breaking your customer experience. This is done by defining the business KPI you want to track that would indicate the performance of your feature. If it reaches a certain value, the rollback is automatically triggered.  

Sunsetting features

Feature flags can also enable the ‘sunsetting’ of features. For example, with time, you might see your usage of feature flags increasing and widening to encompass a number of features. However, this accumulation of features may eventually turn into a heavy debt. 

This is why it is important to continuously keep track of which features you are using and which features have run their time and need to be retired from your system.

Sunsetting, then, enables you to kill off features that are no longer being used. Feature flags would give you an idea of the usage of certain features which would help you determine whether it’s time to kill it off, lest you end up with the dreaded technical debt.

Removing unused features and clearing up old flags is the best way to keep such hidden costs in check. Thus, you should have a careful plan in mind to remove some flags once they have served their purpose or otherwise you end up with the aforementioned technical debt. This will require you to have an efficient feature flag management system in place to track down ‘stale’ flags.

Managing migrations

Feature flags can be used to safely and effectively migrate to a new database as business requirements change and evolve. What organizations would normally do before feature flags is a one-time migration then hope for the best as rollbacks are usually a painful process.

Obviously, the biggest risk that comes with switching databases is loss of data. Therefore, developers need a way to test that the data will remain intact during the migration process. 

Enter feature flags. They allow you to facilitate migration and should something go wrong, you can disable the migration by simply toggling the flag off.

A percentage rollout can then be implemented using feature flags to validate the new database and any changes can be reversed by using feature flags as a kill switch.

Read more: How to migrate from monolith to microservices architecture using feature flags

Feature flags as circuit breakers

Feature flags are particularly useful when your system is experiencing heavy load during times of exceptionally high traffic. 

In particular, the on/off switch of feature flags (operational toggles) can be used as circuit breakers to disable non-critical features that add stress to the system to help your website run better and avoid any backlash from any potential downtime caused by a heavy load. 

For example, many e-commerce websites experience heavy traffic during Black Friday. To avoid a potential system outage or failure, development teams can use feature flags to turn on critical features and turn off the rest until this period of heavy traffic passes to shed some of the load from a system.

Bottomline: Use feature flags often but proceed with caution

As we’ve seen so far, many of the use cases can be easily implemented. However, others will require the ability to make detailed, complex and context-specific decisions so a more advanced feature flagging system that enables such functionalities would be needed.

Regardless of what you decide to use feature flags for, one thing is clear: feature flags put you in the driver seat when it comes to releases. You are in complete control of the when and to whom you release. It also allows you to experiment to your heart’s content but without the risks, especially when the release doesn’t go as expected. 

Working with feature flags also increases productivity among teams. As we’ve seen in the use cases outlined above, it’s not only developers who have complete control over and access to the release process but product and operations teams can also release and roll back as needed.

Read more: Feature flags use cases for product teams

You can use features for many things across different contexts. Some may remain for a long period of time while others need to be extracted as soon as possible so as not to accumulate technical debt. 

Thus, the general advice would be to use feature flags often but keep in mind that proactive flag management and implementation will be needed to maximize the benefits while minimizing the costs.

Don’t just take our word for it. Start your feature flag journey and see for yourself what  feature flags can do for you by signing up for a free trial at AB Tasty.

The post The Many Uses of Feature Flags to Control Your Releases appeared first on abtasty.

This doesn’t mean your favorite experience rollout and feature management tools are disappearing, but rather it’s part of a new exciting chapter for AB Tasty with the goal to make all our features available in one place under one name.

We have merged the AB Tasty and Flagship websites. All resources and landing pages previously hosted on Flagship’s website (flagship.io) can now be found in one location on the AB Tasty website (abtasty.com).

This branding evolution means the Flagship name will be phased out and then retired. While we feel a little nostalgic for the old name, the end goal is to make it easier to get access to the AB Tasty umbrella of solutions and features and join them together to keep our promise of being your go-to-platform for improving and optimizing the customer experience.

If you have questions about what this change means for you, you’ve come to the right place. Below we will dig into what is changing, helpful links and resources and some general FAQs.

As always, our team of AB Tasty magic makers are available to answer any additional questions that might pop up along the way. If you have any more questions after reading this, don’t hesitate to send us an email at hello@abtasty.com and we will update this page as needed.

How are AB Tasty and Flagship related?

AB Tasty and Flagship have always been the same company, just with different names for the server-side solutions and client-side solutions.

AB Tasty’s experimentation suite enables brands to carry out client-side A/B testing and personalizations in order to provide a richer digital experience and boost conversions.

Meanwhile, Flagship by AB Tasty is also built to provide richer experiences that convert through risk-free feature management, server-side experimentation and personalization. Again, same company, just different ways of helping brands provide the best experience for their customers.

What do you mean when you say merge? Will the Flagship website be gone for good?

Yes, everything on the Flagship website (flagship.io) has moved over to the AB Tasty website (abtasty.com). This means links to existing landing pages and resources are all redirected to AB Tasty, and any new resources will be posted directly on AB Tasty from here on out. Easily access resources like e-books, blogs, guides and more by clicking on the resources tab above or following the link here.

Why are we merging the Flagship and AB Tasty websites and names?

From the start, our focus has always been on what we do best, which is giving clients the tools they need to validate ideas while maximizing impact, minimizing risk and accelerating time to market.

Marketing teams and tech teams are working more closely together than ever before to bring new features to market to stay competitive. Our customer-first approach means we want to make our features more accessible and find the tools you need for all your experimentation and personalization needs. For this reason, we have decided to bring Flagship to the AB Tasty website and to position it as AB Tasty’s Feature Experimentation and Experience Rollouts rather than as a separate solution.

Many of our client-side clients have evolved their experimentation needs to the point where they are running more advanced experiments and rolling out more advanced features. For our clients who are ready to start server-side experimentation, this change makes it much easier and faster to find all the information and support they need about all our features, including our server-side functionality, in one place.

What will happen to all the resources (blog posts, guides, e-books, etc.) on the Flagship.io?

As mentioned above, the Flagship content is now migrated and all links from flagship.io are redirected to the AB Tasty. From there, all our resources from guides to blog posts and e-books about feature management, experimentation and more can all be found on the AB Tasty website.

You’ll find your favorite content can be easily accessed here if you filter for the “Rollouts” and “Feature Experimentation” topics.

How can I log into my Flagship account? And where can I access the documentation and SDK libraries?

You can access your accounts by visiting abtasty.com and clicking the login button in the top right-hand corner.

All our documentation and SDKs will have the same links as before. You can access them below:

• Documentation
• Libraries and SDKs

How will the merger affect existing customers of both Flagship and AB Tasty and the support they receive?

All our clients, regardless of whether they are using AB Tasty or Flagship or both, will not be affected. You can continue to use our platform for all your experimentation needs without any changes.

Likewise, you can expect to receive the same level of support and have access to the same dedicated team for client- and/or server-side experiments as before.

As always, your CSM will inform you in a timely manner when/if there any changes to the platform occur.

How will the merger affect new customers? Where can I sign up for a demo for AB Tasty’s Feature Experimentation and Rollouts?

If you’re new and you’d like to try out AB Tasty’s Feature Experimentation or Experience Rollouts, click the banner below or click the “Get a demo” button on the top right-hand corner of the page to explore how server-side experiments can positively impact your business.

A very special thank you to our customers and our partners for supporting us in this exciting evolution of AB Tasty. Your feedback and support helps shape important changes such as these, and we are grateful for it.

Have any additional questions about AB Tasty? Send us an email at hello@abtasty.com to let us know and stay tuned for more exciting updates and information still to come!

The post A New Chapter for Flagship as it Merges with the AB Tasty Website appeared first on abtasty.

However, as an experimentation program matures, companies are more likely to want to delve deeper into more sophisticated types of testing which require more expertise and a more advanced tool.

This is the point when many companies are ready to take the plunge from client- to server-side experimentation.

In this article, we will explore when is the right time to make the shift to server-side testing and discuss the importance of running these types of tests by outlining the various scenarios where server-side experiments are more appropriate. 

Client-  vs server-side testing

Before we go deeper into server-side testing, we will quickly point out the differences between client- and server-side tests to understand why you need both types of testing as your experimentation and optimization program evolves.

In client-side testing is where experimentation occurs on the client side through Javascript that runs in the browser. Therefore, client-side tools enable you to create variations of your pages by changing the content sent by your server to users in the web browser. The user then gets one variation of your altered content based on your targeting rules.

Put simply, all the work happens at the level of the browser thanks to Javascript. Because of this, client-side testing is usually best for surface-level changes such as layout, design and colors to measure their performance and impact on key KPIs.

Meanwhile, all the work in server-side testing happens at the server level rather than the browser. In other words, it’s your server that randomly sends a user the modified variation. As a result, the experimentation tool works on the server instead of inside your users’ browsers. 

Perhaps one of the biggest benefits of client-side tests is that it’s easy to implement and no special expertise is required to run these tests on the front-end of the website.

However, because of its advanced capabilities, server-side tests require technical expertise  and coding skills and so developers are usually the ones running these tests on the back-end.  

What are the benefits of server-side testing?

Before we go into when you should be using server-side tests, we will outline some of their benefits in order to better understand their use cases.

Omnichannel experimentation

Client-side solutions are usually limited to devices with web browsers, whether that’s on desktop, mobile or tablet. This means you cannot run experiments on mobile apps or connected devices.

Server-side solutions, for their part, allow you to experiment across multiple channels including mobile apps which significantly widens your playing field and opens up numerous opportunities to A/B test beyond web browsers so you can cover all your bases.

Enhanced performance

Perhaps one of the biggest advantages of server-side tests is the absence of the flicker effect, which is often a major downside associated with client-side solutions.  

The flicker effect occurs when the original page loads and is replaced by the test variation and is usually seen by the user.

Unlike client-side tools that require adding a Javascript tag to your pages, you don’t need to add this tag in server-side tools. That’s because experiments are rendered on the server before being pushed to the client and so all the major work occurs at the server level- it’s not noticeable on the client side. 

In other words, during a server-side test, the variation is retrieved from the server and delivered to the user’s browser. As a result, no modifications take place on the front-end or browser, so there’s no flickering effect

Endless testing opportunities

Your teams have a lot more options to work with when it comes to server-side testing as it enables you to modify all aspects of your site.

As server-side tests are rendered from the back-end server, you can test more complex dynamic content unlike with client-side tests where it’s not easy to test such content and may damage the user experience if done on the client-side. 

In other words, you can build tests that are much more complex that go deeper within your tech stack beyond the scope of UI or cosmetic changes to unlock a whole new world of experimentation. 

With such deep experimentation capabilities, teams can thoroughly test all facets of a product to validate its functionality such as evaluating its underlying features, algorithms and back-end logic. 

The next section will go over these various use cases where you should consider running server-side testing instead.

When does it make sense to move to server-side testing?

As we’ve mentioned, server-side tests are usually used to run more advanced types of tests and experiment deeply within your tech stack to thoroughly explore how a product works.

Put simply, server-side experimentation solutions allow teams to conduct more robust and secure experiments that are focused on modifying a product’s functions. 

Here are some use cases where server side testing is recommended over client-side testing:

• Run experiments on your mobile app

As already mentioned, one of the key advantages of server-side testing is enabling omnichannel and cross-platform experimentation.

As client-side solutions rely on Javascript and cookies, it’s not possible to use them to test on native mobile apps and you’re limited to devices that have a default web browser.

This means to run experiments on your mobile app, you will need a more advanced server-side testing solution to handle mobile app technologies, which are more complex and vastly different from web technologies. 

Moreover, because server-side testing works on both web applications and mobile apps, you can run the same test serving the same variations irrespective of which channel they’re using. This allows you to compare data from each channel and optimize the user experience across all the different touch points accordingly. 

Finally, if you use feature flags to conduct server-side testing on mobile apps, you can bypass the tedious and time-consuming app store approval. Put simply, feature flags enable you to turn functionality on or off remotely without redeploying code to app stores and waiting for its approval or having to wait for all changes to be ready at the same time to release your own changes.

• Test your search algorithms

Server-side A/B tests are efficient for testing deeper level modifications related to the backend and the architecture of your website.

This is the case with search algorithms which require modification to your existing code. E-commerce websites usually turn to server-side testing to ensure that customers can easily browse through their website and find the product they’re looking for. 

Thus, search algorithms are key in getting customers to find the product they’re looking for by providing a seamless search experience that eventually gets them to purchase.

For example, you can test what is displayed to customers in their search results, whether this should be based on pricing, popularity or reviews or whether you need to prioritize products based on what customers purchased/liked/viewed in the past. 

Server-side testing allows you to create such complex scenarios and rules to provide customers with more personalized reocmmendations and optimize their search experience on your site. These are more difficult to test through client-side solutions as search pages are based on the search query and so they are rendered dynamically.

Thus, server-side testing offers more comprehensive testing and allows you to experiment with multiple algorithms by modifying the existing code.

• Optimize your product recommendations

Similarly, with server-side tools, you can test multiple product recommendation algorithms typically found at the bottom of product pages to measure which types of layouts generate the most sales or increase average order value. For example, is it better to promote similar products, the most popular products or those that were recently viewed?

Such recommendations are based on a variety of criteria, like browsing history and on your own PIM (Product Information Management) system and other data sources. Server-side testing will allow you to test these multiple algorithms to uncover the best performing selection of recommended products.

• Test data-sensitive pages

Server-side testing is great for testing on pages where data security is vital as it ensures that the data remains safe internally within the server without worrying about a security threat.

This is ideal to test on e-commerce payment pages or for banking applications, for example, or any other web pages or apps that contain sensitive data.

You can also use feature flags to test out a new payment method on a subset of users and see how they adapt before rolling it out to everyone else.

• Determine the ideal form length

This is especially important for SaaS businesses that rely on free trial and request demo forms to gather information from their visitors. Thus, they need to determine the best length for such forms without risking drop-offs but still being able to gather all the necessary information about a prospect. 

Server-side testing is the way to go in this scenario as your forms are directly linked to how your database is structured. If a field is obligatory, you will not be able to hide it using JavaScript because the form’s validation will fail server-side.

As a result, testing the length and complexity of a form that has the highest positive impact on conversion rates should be done on the server-side.

This also applies to other websites that utilize such forms from visitors such as hotel reservation or insurance sites. Note that different sectors will require different and more or less information depending on the type and purpose of the information being gathered. 

• Test the limit for free shipping

E-commerce businesses should be able to determine the order value over which free shipping is possible. This is important as shipping costs are one of the major causes for cart abandonment.

Therefore, since shipping cost is one of the determining factors in a customer’s purchase decision, companies should test out various cart value thresholds to find out the optimal limit for free shipping to improve transaction rates.  

Since shipping costs are usually rendered dynamically from the back-end server, you will need to test them on the server-side. Any modifications made should have an impact on all of the following steps, and should be managed server-side. 

• Validate your features

Server-side tests allow you to conduct feature testing to validate your product features by rolling out variations of your feature to different groups of users to evaluate its performance before going for a general release. 

With the help of feature flags, you can run server-side A/B tests and segment your users by directing them to one variation or the other. If anything goes wrong with a variation, you can easily roll it back by disabling the flag before it further impacts the user experience. 

Finally, according to the feedback generated from these users, you can then optimize your features and release them to all your users with the confidence that it matches customers requirements. 

Server-side tests and feature flags

The best way to run server-side tests is through feature flags. By decoupling deployment from release, you can conduct server-side A/B tests by rolling out new features to a small group of users. You can then measure their performance on this group of users before rolling out to everyone else.

While server-side testing requires technical expertise and coding skills, it’s not only relevant to tech teams. Often, non-technical staff team up with product teams to define experiments, which are then executed by the engineers. Once implemented, an experiment can usually be controlled, monitored, and analyzed via a dashboard.

With the right feature management solution, all teams across an organization can run server-side tests with the help of an easy-to-use dashboard without facing any technical hassles. 

Client- vs server-side testing: Context matters

In the end, it’s important to note that it’s not a question of whether server-side is better than client-side. They’re both complementary approaches and whichever one a company chooses depends on which is better suited for its optimization and larger business goals.

In other words, one type of testing doesn’t replace the other. It’s a matter of looking at the type of experiment you want to run and which type is more suited in that particular context and which teams are looking to run the experiment- marketers tend to favor and use client-side testing more often while product managers and developers usually opt for server-side testing for their experimentation needs. It also depends on the resources businesses have at hand and the maturity of their optimization programs.

To ensure your website is optimized and provides a seamless user experience, having both testing techniques at hand is key to surviving in a competitive digital world. 

Both types of testing are indispensable to help you build great products that will bring in maximum revenue. The key is to use both together to heighten productivity and achieve maximum impact.

The post When to Make the Leap from Client- to Server-Side Testing appeared first on abtasty.

In the age of digital transformation, organizations now more than ever have to move fast to meet fast-changing customer and market demands and to gain competitive advantage.

DevOps is one methodology that many teams have incorporated into their work flows to increase efficiency and speed of delivery while maintaining and even improving product quality.

And yet, with its widespread adoption, there is still much confusion over DevOps and what the term encompasses.

This guide seeks to put all your questions about DevOps to rest by going in depth into the concept of DevOps and all the essentials surrounding this methodology. We also take a look at how feature flags can facilitate DevOps implementation by reducing deployment time and enabling low-risk and faster software delivery. 

In particular, this e-book will go over:

• The definition, fundamentals and culture of DevOps
• The benefits of the DevOps approach and the skills needed for its successful implementation in your organization
• How feature flags fit into the DevOps methodology

The post A Guide to All Things DevOps appeared first on abtasty.