DEV Community: Zayyad Muhammad Sani

Beyond Environment Variables: When to Use Feature Flags (and Why)

Zayyad Muhammad Sani — Thu, 07 Aug 2025 14:14:34 +0000

When talking to devs in the software development community about feature flags, a question that often comes up is, “Can’t I just use environment variables for that?” It's a fair question; both can influence how an app behaves. But under the hood, they serve very different purposes. Let's break it down.

What's an Environment Variable?

Environment variables are key-value pairs used to supply configuration values to your application. They typically live in your app’s runtime environment. You can set environment variables through the command line, CI/CD pipelines, or hosting platform settings using a config file.

Environment variables are commonly used in the following scenarios:

Applying environment-specific data such as port numbers and database URLs.
Keeping sensitive data such as API keys and credentials out of your source code.
Changing software behavior based on environment (e.g., setting API rate limits in a production environment).

Simple, dependable, and great for bootstrapping config. But they have limits.

What's a Feature Flag?

A feature flag or feature toggle represents a boolean-type setting value that allows development teams and product managers to toggle features on or off. Feature flags allow you to separate deployments from feature releases. They are typically used in if-else statements to make features visible to an entire user base or, with precise targeting, to specific audiences and individual users.

Common feature flags use cases include:

Progressive delivery (e.g., canary releases and staged rollouts)
Trunk-based development
Experimentation and marketing campaigns (e.g., A/B testing)
Kill switches for cases where features are not working correctly

They are typically managed using a feature management platform like ConfigCat or LaunchDarkly, or via a homegrown solution if you have the time and resources.

Understanding the Differences

While feature flags and environment variables can both affect how applications behave, their similarities end there. Here are the factors that set them apart:

Redeployment: This is probably the biggest difference. Changing the value of an environment variable requires you to redeploy the application code or rebuild your app to reflect the changes. In contrast, when you toggle a feature flag, your app reflects the changes almost immediately without redeployment.
Targeting: Feature flags enable you to roll out features to specific subsets of users or user segments based on contextual data, such as country, email address, or device type. Environment variables, on the other hand, do not support user targeting and segmentation.
Values: Environment variable values can only be strings. While you can pass numbers and booleans as strings, you need to parse them in your app before use. Complex values, such as objects, must be stringified first. Feature flags, on the other hand, are traditionally boolean values, but modern systems also support strings, numbers, and even JSON objects.

Now that we’ve covered the differences, let’s look at the pros and cons of using feature flags and environment variables to modify application behavior.

Feature Flags vs. Environment Variables: Quick Comparison

Feature	Environment Variables	Feature Flags
Change requires redeploy?	✅ Yes	❌ No
Supports targeting?	❌ No	✅ Yes
Value types	Strings only (must parse others)	Booleans, strings, numbers, JSON
Per-user control	❌ Not possible	✅ Easy to segment users
Frontend-safe?	❌ Risky (can expose secrets)	✅ With proper flag setup
Best for	Static config, secrets, bootstrapping	Dynamic features, rollouts, A/B tests

Pros and Cons

Environment Variables
✅ Easy to use, no external tools
✅ Language-agnostic and widely supported
❌ Require redeploys
❌ No user segmentation
❌ Harder to manage at scale
❌ Only handle strings

Feature Flags
✅ No redeploys needed
✅ Fine-grained control over rollouts
✅ Safer feature experimentation
❌ More complex testing (must test multiple flag states)
❌ Can clutter code if not cleaned up

What to Use When?

Use environment variables when:

You need config only at startup
You don't need to target users
You're storing secrets or low-level infrastructure config

Use feature flags when:

You want to enable/disable features instantly
You're rolling out to a subset of users
You need flexibility and safety during releases

Bonus Tips

If you choose to use environment variables, check out OpenFeature's environment variable providers. They support booleans, numbers, strings, and objects, and provide a nice API for evaluating these values. If you'd rather use OpenFeature to manage your ConfigCat feature flags, take a look at our OpenFeature guide.

Have the culture and tooling in place to remove stale (zombie) flags.
Give your feature flags descriptive names.
Make your feature flags observable.

ConfigCat can help you with all of the above (except the team culture part 😅). ConfigCat provides zombie flag alerts, integrations for monitoring and analytics platforms, and many other features that allow you to use feature flags and remote configuration with ease. Get started with the generous forever free plan, or contact the team for a demo.

You can also check out ConfigCat on Facebook, X, LinkedIn, and GitHub.

Frontend Feature Flags vs Backend Feature Flags

Zayyad Muhammad Sani — Sat, 24 May 2025 11:34:46 +0000

Does it matter whether you evaluate feature flags on the backend or the frontend? The answer is yes. As you might have guessed, the frontend and backend are distinct components of software architecture—and the factors we consider when working with them, such as security and control, apply to feature flags as well.

In this article, we'll explore the pros and cons of backend and frontend feature flags and solutions to challenges you may face while working with them.

What are Feature Flags?

Feature flags, also known as feature toggles, are powerful tools in modern software development that let you turn features on or off without redeploying your code. Feature flags could be used for gradual feature rollouts, separating deployments from releases, A/B testing, and pretty much any situation where you want to reduce the risks of feature releases.

In practice, feature flags look something like this:

isCoolNewFeatureEnabled = getFeatureFlag("cool-new-feature")
if(isCoolNewFeatureEnabled) {
    // do the new thing
} else {
    // do the old thing
}

To assign a feature flag to a feature in your app, you'll need to wrap the feature in an if-statement that depends on the flag's value. When the feature flag is enabled, the feature or functionality will be available in the app.

Feature flags can be managed and stored in various ways, but the simplest approach is to use a feature management platform like ConfigCat. Such platforms provide a user-friendly interface to create, toggle, audit, and remove feature flags as needed.

Feature flags can be configured with targeting rules and/or percentage options to deliver features to specific user segments. For example, you could use a feature flag to control the pricing tiers of a software product based on a user's location.

The process of determining a feature flag's value is called evaluation. The context in which this evaluation happens is what distinguishes frontend (client-side) feature flags from backend (server-side) feature flags.

TIP 💡: If you're looking for solutions to common challenges with frontend and backend feature flags, feel free to skip ahead to the Working Around the Challenges section of this article.

Frontend Feature Flags

Frontend feature flags are used to control the user interface and user experience of an application. Frontend feature flags can manage access to premium features, subscriptions, or other monetization strategies. Examples include toggling price tags during sales events, displaying different versions of a landing page, showing features based on a user's country, etc.

Pros

Easier to implement because the features they control are close to the user and have a visual impact.
Simpler to debug and straightforward to remove when they are no longer needed.
Involve less code, as developers only need to wrap the feature's UI components in conditional statements. They also won't need to write HTTP requests to fetch the feature flags from an API.

Cons

A slow internet connection might cause browsers to download feature flags slowly, leading to a brief flash of content that should be hidden behind a feature flag.
Users may be able to view sensitive information in a feature flag's targeting rule through a browser's Devtools.

Backend Feature Flags

Backend feature flags are evaluated on the server-side. Common use cases include modifying system behavior, such as API rate limiting, blue-green deployments, database migrations, or implementing kill switches for misbehaving features. A kill switch is a critical tool that allows teams to quickly disable problematic features if issues arise, thus maintaining stability and preventing major disruptions to the user experience.

Backend feature flags can sometimes control client-facing features through frameworks like Rails and Laravel or by providing an API for the client side to fetch flag values. This approach is especially useful for scenarios where client-side evaluation is not feasible. Backend feature flags can also be gradually released to larger user groups incrementally, minimizing risks associated with software releases by enabling quick adjustments and ensuring that new functionalities perform reliably before reaching a broader audience.

Pros

Backend feature flags keep evaluations secure on the server-side and reduce the risk of exposing information in the browser.
Latency is less of a problem here since developers can easily configure fallbacks and make the backend fail more gracefully.
They also allow for centralized control, making them ideal for features that depend on complex business logic or require consistency across different client platforms.

Cons

Because the code for backend flags is separate from the frontend code they affect, developers may easily forget the purpose of the flags over time.
In architectures where multiple client-side frameworks rely on server-side evaluations, any errors at the server level can impact all connected clients.
Developers need to write additional code to handle HTTP requests because backend feature flags require communication between the client-side and server-side. This extra layer of interaction adds complexity, as developers need to implement and maintain the necessary APIs or endpoints to support this process.

TIP 💡: The points mentioned in this article apply to most feature management tools since they work in similar ways. However, there may be slight differences depending on the architecture of the feature management tool you use.

Working Around the Challenges

Let's explore a few ways to handle the challenges we mentioned earlier.

Frontend

To avoid leaking sensitive data, consider using a backend flag and access it through an API on the frontend. If you're using ConfigCat's feature management platform, you can use confidential text comparators to hash your targeting rules so they're not readable in the browser. Though ConfigCat's SDK keys are visible in browsers, they're read-only and can't be used to modify feature flags.
Consider using animations, loading states, and other techniques to hide features while the feature flags are downloading. This point is more important when you're running experiments because users interacting with multiple variations at once will affect the results.
To avoid flashing content, consider using modern frameworks (like Next.js or SvelteKit) that support server-side rendering or backend frameworks like Django and Laravel that can generate web pages on the server by default.

Backend

Consider using templates provided by server-side frameworks (e.g., Blade, ERB, Jinja2), as these mimic the visual simplicity of frontend feature flags by keeping the logic for displaying the feature flag closer to the UI, while also offering the advantages of backend feature flags.

Both (Frontend and Backend)

For increased security and reliability, consider using ConfigCat Proxy to host an evaluation backend in your infrastructure. With the proxy, you can use external caching solutions like Redis and MongoDB and stream feature flag changes with Server-Sent Events (SSE). Plus, you won't have to write a custom API to serve feature flags to the frontend.
Cache feature flags, but don't forget to update them so they don't become stale. ConfigCat caches feature flags automatically and allows you to configure how often you want to update them.
Use reasonable default values for your feature flags that your app can fall back to when facing network issues.

General Best Practices

Give your feature flags detailed names that describe their purpose, where they'll be used, and for how long. Check out this feature flag naming guide for more.
Have a system in place to remove unused flags. Tools like ConfigCat’s zombie flag reports and code references can help track and remove stale flags.

Conclusion

I hope you now have a well-rounded view of frontend and backend feature flags. Keep in mind that the suggestions here are not fixed rules, and ultimately, you'll have to choose what works best for you and your users.

If you're in the market for a feature management platform, check out ConfigCat. You can start with the forever free plan, which has all the features you'll need at a small scale.

You can stay up-to-date with ConfigCat on Facebook, X, GitHub, and LinkedIn.

Announcing Official Support for OpenFeature

Zayyad Muhammad Sani — Mon, 17 Mar 2025 14:43:10 +0000

At ConfigCat, we've seen firsthand how feature flags help teams ship faster with less risk and build more resilient, user-friendly applications. We want more people to experience these benefits, so we've decided to officially support OpenFeature.

Our OpenFeature providers were previously developed and maintained by open-source contributors. Moving forward, we've opted to develop and maintain some providers in-house, while continuing to collaborate with open-source contributors for others.

In the upcoming sections, we'll explore how to integrate OpenFeature into a Python application that currently uses the ConfigCat Python SDK.

What is OpenFeature

OpenFeature is a project under the Cloud Native Computing Foundation (CNCF) that offers a standard, vendor-agnostic API for feature flagging. With OpenFeature, developers can utilize a single SDK to interact with multiple feature management platforms. To make this possible, feature management platforms or the open-source community develop providers that connect their SDKs to OpenFeature. These SDKs and providers are available for many programming languages and feature management platforms.

Why use OpenFeature with ConfigCat?

Here are a few reasons why combining OpenFeature with ConfigCat is a game-changer for your development process:

Avoid vendor lock-in: OpenFeature's APIs and SDKs let you work with any feature management platform, so you're not tied to just one.

Benefit from the OpenFeature ecosystem: OpenFeature offers a growing set of tools to help you integrate feature flags across your software development stack.

Migrate to ConfigCat more easily: If you're switching to ConfigCat from another platform, OpenFeature makes the migration process easier at the code level.

Check out our OpenFeature guide for more detailed explanations of these benefits.

Getting Started: Integrating ConfigCat with OpenFeature

Let’s see how you can integrate OpenFeature with ConfigCat in a Python app. We'll use a project with ConfigCat already set up to demonstrate how easy this integration can be.

TIP 💡
If you’re interested in using OpenFeature with other languages, check out our docs for the list of OpenFeature providers we have.

Sample App

The app is an online courses API with a GET endpoint that returns a predefined list of courses. The endpoint is linked to a feature flag I created in ConfigCat:

The endpoint will return the course list if the feature flag is turned on:

It will return an error if the flag is turned off:

After adding OpenFeature to the app, it should function just as before.

Installing OpenFeature

To run the sample app, you'll need the following:

A ConfigCat account
Python v3.9+
Git v2.33+
A tool to make HTTP requests (I'll be using Postman)
Intermediate knowledge of Python and FastAPI and basic knowledge of Git

You can find the sample app's source code on GitHub. The main.py file contains the initial code before OpenFeature was added, while cc-openfeature.py has the completed version with OpenFeature integrated.

Follow these steps to add OpenFeature to the project:

1) Install the OpenFeature Python provider.

pip install configcat-openfeature-provider

2) Import the newly installed packages in main.py:

# ... other imports
from openfeature import api
from configcat_openfeature_provider import ConfigCatProvider
# ... remaining code

Using ConfigCat with OpenFeature

As we integrate OpenFeature into the app, we'll use its API in place of ConfigCat code.

1) In the lifespan function, use the OpenFeature provider to initialize the ConfigCat client.

# BEFORE
client = configcatclient.get(os.getenv("CONFIGCAT_SDK_KEY"))
app.state.client = client

# AFTER
cc_provider = ConfigCatProvider(os.getenv("CONFIGCAT_SDK_KEY"))

2) Enable the provider with OpenFeature's API and instantiate a new OpenFeature client.

api.set_provider(cc_provider)
client = openfeature.get_client()
app.state.client = client

The OpenFeature client accesses the provider we set up and uses it to evaluate feature flags.

3) After the yield statement, use OpenFeature's API to clean up the providers when the application shuts down.

yield
api.shutdown()

The lifespan function should now look like this:

@asynccontextmanager
async def lifespan(app: FastAPI):
    cc_provider = ConfigCatProvider(os.getenv("CONFIGCAT_SDK_KEY"))
    api.set_provider(cc_provider)
    client = api.get_client()
    app.state.client = client
    yield
# clean up all provders
    api.shutdown()

We have one more code change to make.

4) Evaluate the feature flag using the OpenFeature client in the get_courses function.

# BEFORE
is_get_courses_enabled = app.state.client.get_value('get_courses_enabled', False)

# AFTER
is_get_courses_enabled = app.state.client.get_boolean_value('get_courses_enabled', False)

And here's the full function:

@app.get("/courses/")
def get_courses():
    is_get_courses_enabled = client.get_boolean_value('get_courses_enabled', False)
    if is_get_courses_enabled:
        return {"courses": courses}
    else:
        raise HTTPException(status_code = 404)

We're using a boolean flag that returns True when the flag is on and False when the flag is off. For cases like A/B tests, user segmentation, or targeting, an OpenFeature context object is required to evaluate the feature flag. Check out our OpenFeature Python docs to see how the context object works.

5) Run the program in your terminal:

fastapi dev main.py

6) Toggle the flag in your ConfigCat dashboard and visit http://localhost:8000/courses. The app should work like before:

And there you have it! The app is now OpenFeature compliant. As always, you can find the complete code on GitHub.

Conclusion

Open-source software has increased collaboration among developers and accelerated advancements in the software industry like never before. Whether a company offers proprietary software, open-source software, or a mix of both, everyone benefits when projects like OpenFeature make feature flags more accessible and better integrated across the entire software development stack.

Resources

For more on feature flags, check out ConfigCat on Facebook, X, LinkedIn, and GitHub.

Using OpenFeature with ConfigCat

Zayyad Muhammad Sani — Tue, 12 Nov 2024 16:48:51 +0000

Let's say you've heard about the benefits of using feature flags for gradual feature rollouts, and you're ready to adopt them in your organization. The next step would be deciding whether to "build or buy."

If you choose to develop your feature flagging tool, you'll need to figure out how to make it fetch, evaluate, and manage feature flags. If you want to use a third-party tool, you might have to learn and unlearn different APIs as you search for the right one.

Challenges like these inspired the creation of OpenFeature, a CNCF (Cloud Native Computing Foundation) project that aims to standardize feature flagging.

What is OpenFeature?

OpenFeature is a specification that provides a unified API for using feature flags. Going back to our earlier scenario, this means you'd use the same code to evaluate (get the values of) feature flags when trying out feature flag platforms for your company.

How does this work?

OpenFeature provides SDKs for evaluating feature flags. Feature flag vendors (or open source contributors) then have to develop OpenFeature providers to connect their SDKs to OpenFeature SDKs. In short, OpenFeature providers act as a bridge between OpenFeature SDKs and feature flag platforms.

💡 INFO
You don't use OpenFeature to create and manage feature flags; you only use it to evaluate them. You'll need a third-party or custom-built feature management tool to create and manage feature flags.

Benefits of OpenFeature

Here are some positive changes OpenFeature brings to feature flagging:

OpenFeature makes migration between feature flag platforms easier at the code level: Many feature flag platforms are compatible with OpenFeature, so switching to another vendor will involve little change in your code. With the recent release of OpenFeature's Multiproviders (currently available for JavaScript), you can use more than one feature flag platform during migration. This advantage also applies to homegrown feature flagging tools since you can create providers to make them accessible to OpenFeature.
OpenFeature encourages community collaboration and tool-sharing: The open-source community can collaborate and build vendor-agnostic tools around feature flags that everyone can benefit from. A good example is OpenTelemetry Hooks for OpenFeature, which you can use to attach feature flag metadata to metrics and traces.

I've said a lot about OpenFeature. Let's see how it integrates with ConfigCat, a feature management platform with first-class OpenFeature support.

Demo

For this demo, I built an AI-powered PDF extractor. The app's users can choose between different AI models for extracting data from PDFs.

I want to test newer, more powerful AI models for employees at PD-EF Corp, a fictional SaaS company, so I'll use feature flags to enable the feature for users whose emails end with @pd-efcorp.com.

Creating the Feature Flag in ConfigCat

Let's get started.

1) Sign in to ConfigCat, or sign up if you don't have an account.

2) Create a feature flag with the following details.

Name: Enable pro models
Key: enable_pro_models
Hint: Enable pro AI models for PD-EF Corp employees

We'll add the targeting rule for PD-EF Corp employees next.

3) Click IF +, then click Add rule with user condition.

You'll see two sections: an IF section for configuring the condition and a THEN section for setting the feature flag's value based on the condition.

4) In the IF section, select Email as the comparison attribute, then select ENDS WITH ANY OF (hashed) as the comparator.

5) Enter @pd-efcorp.com in the field next to the comparator, then turn on the feature flag in the THEN section below.

6) Click SAVE & PUBLISH CHANGES.

Now that we've configured the feature flag, let's move on to the code.

Installing ConfigCat and OpenFeature

Prerequisites

Node.js v18+
Basic understanding of Node.js and Express

To use ConfigCat and OpenFeature together, we'll need to install ConfigCat's Node.js provider for OpenFeature. ConfigCat's Node SDK and OpenFeature's Server SDK will be automatically downloaded alongside the provider.

1) Open your terminal and install the provider.

npm install @openfeature/config-cat-provider

2) Import the provider and OpenFeature server SDK in index.js.

import { ConfigCatProvider } from '@openfeature/config-cat-provider';
import { OpenFeature } from '@openfeature/server-sdk';

3) Create a provider with your ConfigCat SDK key. Then, set the provider and create an OpenFeature client.

// create a provider with your SDK key
const provider = ConfigCatProvider.create("YOUR-SDK-KEY");

// set the provider
OpenFeature.setProviderAndWait(provider);

// Create a client.
const client = OpenFeature.getClient();

ConfigCatProvider.create creates a ConfigCat client with the specific SDK key. The setProviderAndWait method sets ConfigCat as the source of feature flag values and ensures the provider is ready before we begin using it. Finally, OpenFeature.getClient creates a client that uses the set provider to evaluate feature flags.

Using OpenFeature with ConfigCat

I have an existing /models route for serving the list of AI models to the frontend. I'll modify its callback function to accommodate the feature flag.

app.post('/models', async(req, res) => { 
    // get the user's id from the database
    const user = db.getUser(req.body.userId);
    // fetch the models
    const proModels = db.getModels('pro');
    const standardModels = db.getModels('standard');

    // create the evaluation context
    const context = {
        targetingKey: user.id,
        email: user.email
    }

    // evaluate the feature flag with the context
    let modelsListEnabled = await client.getBooleanValue(
      "models_list", false, context
    );

    // serve the models based on the feature flag's value
    if(modelsListEnabled) {
        res.json(proModels)
    } else {
        res.json(standardModels)
    }
});

I created the context object to store the user's email and unique targeting key. Next, I evaluated the feature flag, passing in the key, default value, and context. The provider automatically transforms context into a ConfigCat User object, which ConfigCat will use to determine whether the user's email matches the condition I set in the targeting rule.

Finally, I added a condition to return the appropriate model based on the feature flag's value. That's all the code we'll need. Let's see how it looks.

Once I open the website and sign in with a PD-EF Corp email address, I'll see the pro AI models.

💡 INFO
The call to the API's models/ route is implemented in the frontend. You can find the complete code on GitHub.

Why use ConfigCat with OpenFeature?

First-class OpenFeature support: ConfigCat builds and maintains its own OpenFeature providers, which are available for most languages.
Powerful and easy to use: Both seasoned and new feature flag users will benefit from using OpenFeature with a capable and beginner-friendly feature management platform.
Existing ConfigCat users can benefit from an open feature-flagging ecosystem: ConfigCat users can leverage available tools in the OpenFeature ecosystem and contribute by building tools and sharing knowledge with the feature-flagging community.

Recap

Thanks for accompanying me on this short trip through OpenFeature and ConfigCat. We covered:

What OpenFeature is.
The benefits of OpenFeature.
How to create a feature flag in ConfigCat.
How to use OpenFeature with ConfigCat.
The benefits of using OpenFeature with ConfigCat.

Next Steps

Check out OpenFeature.dev to learn more about OpenFeature and its ecosystem. You can also join the OpenFeature Slack channel to get the latest updates.

If you're not using feature flags yet, you can start with ConfigCat. ConfigCat has SDKs and OpenFeature providers for many popular programming languages and a free-forever plan suitable for small-scale feature flagging.

For more on feature flags, check out ConfigCat on Facebook, X, GitHub, and LinkedIn.

A/B Testing with ConfigCat and Google Analytics

Zayyad Muhammad Sani — Mon, 23 Sep 2024 16:22:10 +0000

Suppose you come up with an idea to improve the conversion rates on your website. You could implement the idea and roll out the changes to all users. But what happens if the idea is only good on paper and fails in reality? In cases like this, conducting an A/B test is an excellent way to validate your idea.

In the upcoming sections, we'll learn how to set up an A/B test using ConfigCat feature flags and visualize the test's data in Google Analytics.

Using Feature Flags for A/B Testing

Feature flags (or feature toggles) are virtual switches you can use to turn features in your app on or off without redeploying code. Feature flags are commonly used for gradually rolling out features, running beta tests, quickly rolling back features, etc.

An A/B test involves comparing two variations of a webpage, email, or other digital content to see which delivers better results. Using a feature flag, you can toggle variation A (the new feature you want to measure) for 50% of users while keeping variation B (the control) on for the remaining users. During the test, events are tracked and recorded on an analytics platform to help you select the best variation.

Demo

Prerequisites

Basic knowledge of Google Analytics
Knowledge of Vue.js 3 and JavaScript

To demonstrate, I built an animal quiz game where players listen to an animal's sound and select the correct answer from four options. Currently, the players don't see the correct answer when they choose an option. They only see their scores at the end of the game, leaving them to guess which questions they got wrong.

While the current design makes the game fun and generates curiosity, I think highlighting the answers will encourage users to play longer to beat their high scores.

Let's use an A/B test to determine which variation users like the most.

Sign up for a free ConfigCat account, or log in if you already have one.
Click the "ADD FEATURE FLAG" button, name the feature flag "Highlight answer" and give it the following hint: "Highlight the correct answer when a user selects an option."

Click "ADD FEATURE FLAG" to create the flag, then click the +% button to target a percentage of users.

You should see 50% of users in both fields. Leave the values as they are since only half of the users should see the highlight feature.

Click "SAVE & PUBLISH CHANGES".

Using the Feature Flag

You'll need to install a ConfigCat SDK before you can use feature flags in your app. We'll use ConfigCat's Vue SDK since our sample app was built with Vue.js.

Open your terminal and install ConfigCat's Vue SDK.

npm install configcat-vue

Import configcat-vue in main.js and initialize the ConfigCat client:

// other imports
import { ConfigCatPlugin } from 'configcat-vue';

const app = createApp(App);

app.use(createPinia());

app.use(ConfigCatPlugin, {
  // Don't forget to put in your actual SDK key below
  sdkKey: 'YOUR-SDK-KEY',
});

app.mount('#app');

ConfigCatPlugin creates a ConfigCat client with the given SDK key and makes it available to other Vue components. ConfigCat will download and cache the latest feature flag values every 60 seconds by default. You can check out other configuration options in the documentation.

Open src/components/Question.vue and add this CSS class to the <style> section.

.correct__option {
  background-color: lime;
}

Add the following code to the <script> section of Question.vue.

import { inject, onBeforeMount, ref } from 'vue';
import { User } from 'configcat-vue';
import { useUserStore } from '@/stores/user';

// Inject the ConfigCat client
const configCatClient = inject('configCatClient');
let isAnswerHighlightEnabled;

// Add these after defining props and events

onBeforeMount(() => {
  setHighlightStatus();
});

async function setHighlightStatus() {
  // get the value of the Highlight answer feature flag
  isAnswerHighlightEnabled = await configCatClient.getValueAsync(
    'highlight_answer',
    false,
    new User(useUserStore().userID),
  );
}

In the snippet above, I accessed the ConfigCat client and called setHighlightStatus() to fetch the value of the feature flag. ConfigCat requires unique user identification when using the targeting feature, so I also created a ConfigCat user object and assigned it a unique ID from the user store.

Finally, add the correct__option class to the option button:

<template>
  <div>
    <div class="options">
      <button
        v-for="(option, index) in question.options"
        :id="`option${index + 1}`"
        class="btn option"
        :class="{ correct__option: (optionsDisabled && option === question.answer && isAnswerHighlightEnabled) }"
        :disabled="optionsDisabled"
        @click="selectOption(option)"
      >
        {{option}}
      </button>
    </div>
  </div>
</template>

I'm using Vue's conditional classes to highlight the correct option when the feature flag is enabled. Let's now turn our attention to Google Analytics.

Setting up Google Analytics

Google Analytics is a popular online analytics platform that allows individuals and organizations to gain insights into user interactions. For this demo, we'll use ConfigCat's Google Analytics integration to gather and visualize event data for our A/B test.

Following the instructions on adding Google Analytics to a website, I'll add the following code after the <head> tag in index.html.

<!-- Google tag (gtag.js) -->
<script
  async
  src="https://www.googletagmanager.com/gtag/js?id=YOUR-MEASUREMENT-ID"
></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag() {
    dataLayer.push(arguments);
  }
  gtag('js', new Date());

  // send the userID to Google Analytics
  gtag('config', 'YOUR-MEASUREMENT-ID', {
    user_id: localStorage.getItem('userID'),
  });
</script>

In the snippet above, I set up Google Analytics on the web page and set the user ID I generated for the player. The user ID helps Google Analytics track users across different devices and is always generated by the website owners. In this case, I'm keeping things simple by using a randomly generated ID stored in local storage. But in a real-world app, you'll probably have a database where you store your user IDs.

INFO: 💡Google Analytics doesn't allow you to use emails or any other form of Personal Identifiable Information (PII) for your user IDs. Read the documentation for more about the rules and limitations for user IDs.

Add a restart event to the top of QuizContainer.vue:

function restart() {
  // send the restart event to Google Analytics
  gtag('event', 'restart');
  emit('generateQuestions');

  questionCounter.value = 0;
  currentQuestion.value = props.questions[questionCounter.value];
  score = 0;
  optionsDisabled.value = false;
}

I'll use the restart event to track the number of times users restart the game after a session.

Google Analytics will start tracking the events when users play the game, but it won't be able to identify which variation they belong to. I'll solve this issue with variation IDs.

Sending ConfigCat Variations to Google Analytics

Whenever you create a targeting rule in ConfigCat, each variation gets a unique ID. I'll send the variation IDs to Google Analytics so it can match events to their correct variation.

Update onBeforeMount in Question.vue with the following code:

onBeforeMount(() => {
  configCatClient.on('flagEvaluated', (evaluationDetails) => {
    // send feature flag information to Google Analytics
    const variant =
      'configcat-' + evaluationDetails.key + '-' + evaluationDetails.value;
    gtag('event', 'experience_impression', {
      exp_variant_string: variant,
      variation_id: evaluationDetails.variationId,
    });
  });

  setHighlightStatus();
});

I'm using the flagEvaluated hook with a special gtag event called experience_impression to send data whenever the app evaluates (checks the value of) the feature flag. The experience_impression event takes the parameters exp_variant_string and variation_id that we can use to segment users in Google Analytics. For example, if a user is in the control group with a variation ID of 64c323sh, the event's parameters will evaluate to:

{
  'exp_variant_string': 'configcat-highlight_answer-false',
  'variation_id': '64c323sh'
}

For the final step, I'll create audiences in Google Analytics based on the variation data it receives from the game.

Creating Audiences in Google Analytics

You can use Audiences in Google Analytics to segment users based on the actions they perform or properties they share. For example, in a SaaS app, you can create an audience for customers in a particular country to analyze their behaviors compared to customers in other countries.

Before creating audiences for the variations you created in ConfigCat, you may have to wait for up to 24-48 hours for the events' data to reach Google Analytics. However, you can confirm that users are firing the events by checking the Realtime reports page in your Google Analytics dashboard.

Once Google Analytics has received the events data, follow these steps to create audiences:

Go to the Admin page on your dashboard and select "Audiences" under "Data Display".

Select "New Audience", then "Create a custom audience".
Name the audience "Answers highlighted" and give it a description.

Click "Add new condition".

Click "Events", then select experience_impression from the list.

Click "Add parameter" and select variation_id under "Other".

Go to your ConfigCat dashboard and copy the variation ID for the feature flag that's turned on.

Back in Google Analytics, select "exactly matches(=)" under Condition and paste the variation ID you copied into the field.

Click "Apply" then "Save" in the top right corner.

Follow steps 2-9 above to create an audience for the other variation. But in this case, copy the variation ID for the other fifty percent of users who do not have the flag turned on.

With the audiences created, I can build reports to analyze the data.

Visualizing Data from the A/B Test

You may have to wait another 24-48 hours before Google Analytics includes users in your audiences. After that, you can follow these steps to view the data:

Go to the Reports page and select "Events" from the sidebar.

You can also access events from the events card in the Reports snapshot page.

Click "Add comparison", then "Create new".

Select "Audience name" under "Dimension", then select "exactly matches" under "Match type".

Select "Answers highlighted" under value.
Click "Save" in the top right corner and "Confirm" in the dialog that opens.
Repeat steps 2 - 5 for the second audience, "Answers not highlighted".
Remove the "All users" comparison.

When you've completed the steps above, your chart should look similar to this:

You can scroll down to see details of each event per audience.

Now, before you pick the winning variation, you'd have to wait for at least a week so you can see how users interact with the new feature over time. Also, take note of any external factors that might affect these results. You can ask users for feedback on the feature when you end the experiment so you can understand the results better.

TIP: Check out "The Role of Feature Flags in A/B Testing" for a complete, high-level guide to A/B testing.

Summary

Here's a recap of the steps I took to set up an A/B test with ConfigCat and Google Analytics. I:

Created a percentage-based feature flag with a 50% split in ConfigCat.
Added ConfigCat to the app.
Added Google Analytics to the app with a unique user ID to identify each user.
Added the restart event to track how many times users restart.
Added the experience_impression event to send feature flag data to Google Analytics.
Created audiences in Google Analytics.
Added comparisons to analyze data for the audiences.

Resources

I hope you found this article useful. If you want to read more articles on A/B testing and other feature release strategies, check out the ConfigCat blog. You can also stay connected to ConfigCat on Facebook, X, GitHub, and LinkedIn.

A quick guide to Feature Flag Naming Conventions

Zayyad Muhammad Sani — Sun, 24 Dec 2023 10:39:07 +0000

Can naming feature flags be hard?

Yes. Just like variables in programming, naming feature flags can get tricky if you don't follow a naming standard. When feature flags don't have good names, it can be difficult for people using them to remember what they do. In this article, we'll see a few naming conventions we can use for feature flags.

A Quick Refresher on Feature Flags

Feature flags (or feature toggles) are controls that allow you to turn features in your software on or off without having to redeploy your code. Using feature flags, you can separate deployments from releases by deploying code and keeping it disabled until you're ready to turn it on. They have many use cases, such as canary releases, A/B testing, and even infrastructure migrations. With so many use cases, you can start to see how a naming convention can come in handy.

Conventions

General Rule

A feature flag's name should be descriptive enough to explain what it does; its function should be obvious to anyone who looks at it. That said, don't be afraid to give your feature flags long names. It's better for a feature flag to have a lengthy, descriptive name than a short, confusing one. Let’s take an example.

Imagine that an online Markdown editor software has a new spellcheck feature in development. The developers want to hide it behind a feature flag and turn it on when it's ready for release. They name the feature flag:

rollout_text_editor_spellchecker

The word "rollout" tells us that when the developers turn the flag on, it will release the spellchecker feature to users. The "text_editor_spellchecker" part is self-explanatory. This feature flag's name is pretty descriptive, and anybody using it is unlikely to be confused about what it does. Let's see what other information we can add to feature flag names to make them more detailed.

Team name

Considering the size of development teams nowadays and the fact that non-development teams (like marketing and product management) can be in charge of toggling feature flags, it can be helpful to prefix a feature flag’s name with the name of the team responsible for toggling it. Here's an example using our spellchecker flag from before:

naming structure:
teamname_flagfunction

flag name:
engineering_rollout_text_editor_spellchecker

In this example, the prefix "engineering" in the flag's name indicates that the engineering team in the organization is responsible for toggling the flag. When people from other teams see this name, they'll immediately know who's in charge of the flag. Here's an example for the marketing team:

flag name:
marketing_simplified_signup_form

In this example, the marketing team is using A/B testing on a signup form to see if the company's product gets more users. They'll be responsible for toggling the flag for the experiment.

Flag Type

There are 4 main types of feature flags: release, experiment, ops, and permission. They all have defining characteristics, so it can be a good idea to include them in a feature flag’s name. Let’s apply this convention to our previous examples:

naming structure:
teamname_flagtype_flagfunction

flag name:
engineering_release_rollout_text_editor_spellchecker

flag name:
marketing_experiment_simplified_signup_form

Since the spellchecker feature is deployed but won't be released until it's ready, it's hidden behind a release flag. As for the signup form, it's hidden behind an experiment flag because the marketing team is running an A/B test on it.

You might have noticed that the names are significantly longer than they were before. I know I said you shouldn't be afraid to give your feature flags long names, but it's also nice to keep things balanced so that your flag names don't get too complex. Let's take a short detour to see how we can achieve this balance.

ConfigCat's Flag Hints and Tags

ConfigCat is a cloud-based feature management service that enables you to toggle features remotely, with options for user targeting and segmentation which you can use for A/B testing, canary releases, and more.

ConfigCat allows you to add hints to your feature flags, so you don’t forget what they do. You can also create tags for your feature flags so that they are easier to identify and organize. Here are our examples in ConfigCat's dashboard:

Using the team names and flag types as tags, you won't need to keep them in the flag names anymore. And as a bonus, you'll be able to filter your feature flags by their tags. Though the flag names are shorter, they're still verbose, and you can add more information about your flags thanks to hints.

That's all for our little detour. Let's get back to the conventions.

Longevity

If you want to indicate how long a feature flag is going to be used, you can add suffixes like "temp" and "perma" to its name. With this convention, you can easily spot a feature flag that is due for removal if you’re trying to clean up feature flags that are no longer in use. Let's see some examples:

naming structure:
teamname_flagtype_flagfunction_longevity

flag name:
sales_permission_enable_plagiarism_checker_for_user_perma

flag name:
engineering_release_rollout_text_editor_spellchecker_temp

We have a new example: a permission flag that the sales team can toggle for users that purchase the premium plagiarism checker feature. This flag will be there for as long as the app exists, so it gets "perma" in its name. The spellchecker feature is hidden behind a release flag, and since release flags are usually short-lived, the flag gets "temp" in its name.

Flag Creation Date

You can include a flag's creation date in its name as a timestamp to make auditing flags easier. You may use dates as criteria for evaluating what flags to remove. For instance, if a feature flag is old and turned off, it's a good sign that it's not in use anymore. Here's an example:

naming structure:
teamname_flagtype_flagfunction_longevity_creationdate

flag name:
engineering_release_rollout_text_editor_spellchecker_temp_051123

The date in the example is in the day-month-year format, meaning it was created on the 5th of November 2023. It's no secret that date formats can be confusing, but you're less likely to mix up dates if you select one date format for your projects.

Casing Styles

Here's a list of popular case styles and how they look:

Camel case - myCoolFeatureFlag
Kebab case - my-cool-feature-flag
Snake case - my_cool_feature_flag
Pascal case - MyCoolFeatureFlag

If you're using ConfigCat, you can choose camel, snake, or pascal case for your feature flag keys. As a bonus, you won't have to type out the name with the casing. Just give your feature flag a name, and ConfigCat will generate a key from it using the case style you chose.

Those are all the naming conventions we'll look at in this article. You probably understand their usefulness by now, but let's go over a few more points to see just how important they are.

Avoiding Costly Mistakes

There are quite a few things that could go wrong when teams do not use a naming convention for their feature flags:

Someone could accidentally turn on a feature that is not ready for production. Such a mistake can negatively impact the software's users and cause the organization financial losses.
Someone could turn on a retired feature because its flag name is similar to that of a new feature they want to launch. The impact of such a mistake will be worse if the retired feature conflicts with other parts of the software.
Someone could mistake an experiment for a feature release and turn it on for all users. The results of such an experiment will be affected, and the team might have to discard it or start all over again.

These problems are more likely to occur when teams don't have good feature flag management practices. Nevertheless, if feature flags are a part of your development process, you wouldn't want anything to go wrong because you named a feature flag poorly.

Conclusion

The conventions mentioned here are only guides to help you name your feature flags properly. You can tweak them as much as you need, but make sure that your feature flag names are clear enough so that those using them will understand what they do and the implications of toggling them.

And if you’re not using a dedicated feature management platform yet, you should try out ConfigCat. ConfigCat has a free-forever plan that offers a lot of features for small feature flagging use cases.

You can also check out ConfigCat on Github, Facebook, Twitter, and LinkedIn.

Building Software with No Code

Zayyad Muhammad Sani — Sat, 23 Dec 2023 13:44:43 +0000

As the world increasingly becomes digital, we rely on software to solve problems that pop up in everyday life. However, because traditional software development is complex and time-consuming, there aren't enough software developers to meet the high demand for software products. No-code and low-code tools offer a solution to this problem by allowing people to create software and multimedia content and perform complex tasks without writing code.

Low Code vs No Code

Low-code and no-code tools are very similar. Both tools offer users graphical interfaces to create content and perform tasks. They usually have building blocks and components users can put together and customize to fit their needs. The main difference between low-code and no-code tools lies in how much you can do without writing code.

No-code tools are targeted at people with no programming experience. Without writing a single line of code, anyone can create complex, full-featured websites and apps using no-code tools. However, this doesn't mean that no-code tools don't allow users to write any code at all. Many no-code tools, especially website and app builders, allow users to write custom code to extend functionality.

Low-code tools are better suited to people with programming skills. They can use graphical interfaces to create simple websites and apps, then seamlessly transition to writing code to handle complex development tasks and further customize their apps. That said, non-developers can use low-code tools, but they're likely to need the services of a developer for anything beyond simple cases.

Types of Low-code and No-Code Tools

Website and Web App Builders

By far the most popular type of low-code and no-code tools. These tools allow users to build websites using pre-made templates, components, and themes for different use cases and industries using drag-and-drop interfaces. They offer access to plugins and integrations for further customization and extra functionality. Some common low-code and no-code website builders are Bubble, Webflow, and WordPress.

Marketing

These tools allow businesses and individuals to automate their marketing processes and campaigns. They offer intuitive interfaces and pre-built components that enable marketers to create landing pages, run A/B tests, automate email campaigns, and track analytics. Some popular marketing tools are MailChimp and Hubspot Marketing.

Customer Service

These tools empower customer service teams to create interactive chatbots, self-service portals, and knowledge bases without coding. They often provide AI-powered assistants that help agents quickly solve customer support issues. They offer integrations with many platforms so customer service teams can resolve issues from other software they use. Popular customer service platforms include Zendesk and Intercom.

Spreadsheets and Databases

These tools allow users to create spreadsheets and databases, model relationships between data, and perform complex functions on them. Users can automate repetitive data entry tasks and easily visualize data with built-in charts. One cool thing about these tools is that their users can connect them to no-code builders and use the content in them as a data source for their apps. For example, Webflow users can use Airtable as a database or CMS for their websites. Google AppSheet takes this a step further by allowing users to generate apps using the content of spreadsheets from Google Sheets.

Automation

These platforms allow users to automate and schedule tasks in different applications without writing programming scripts. Users can trigger actions in many applications in response to specific events in another. They offer visual workflow builders and pre-built integrations so users can easily set up their automation workflows.

By leveraging feature flags, which act as toggles for turning specific features on or off, users can gain even more control and flexibility when using no-code automation tools like Zapier and Make.

For example, let's say you're a software company planning to perform maintenance on a critical feature of your application. With a feature management platform like ConfigCat, you can temporarily turn off the feature associated with the maintenance task using a feature flag. This action then triggers an automation workflow in Zapier that sends out notification emails to your customers, informing them about the temporary unavailability of the feature and providing any necessary updates or alternatives.

When to Use Low-Code and No-Code Builders

If we look at other categories of low-code and no-code tools, like marketing and customer service, we'll see that they offer obvious benefits to their users. Software development, however, is more complex, so we'll look at the pros and cons of using low-code and no-code tools in this context.

Pros

Empowers non-developers to create software: Non-developers with a solid grasp of their business objectives can create software solutions without relying on developers. They can build customized tools and applications to solve problems without coding experience. From websites for small businesses to personal blogs, anyone can bring their ideas to life with no-code tools.
Facilitates the easy creation of MVPs and prototypes: A massive advantage for startups and indie founders who frequently build new products while trying to keep costs down. They allow them to close the gap between ideas and reality and increase time to market. They're also helpful for quickly creating functional prototypes in traditional software development environments.
Provides cost-friendly solutions for a wide range of use cases: This is true, especially for small businesses that need basic websites and apps. Many no-code platforms allow them to save money they would have used to hire developers. Their features also make it easy to avoid the additional costs of maintaining software.

Cons

Limits the ability to customize and adapt software to specific needs: Though low-code and no-code tools are getting better with customization, they are not the best choice for custom software that has to look and function in very specific ways. Most low-code and no-code tools make users sacrifice control for ease-of-use. They might not be a right fit for people and organizations that need total control of their projects and visibility into all their systems. This lack of control can affect an application's ability to scale.
Raises potential security risks: Low-code and no-code platforms heavily depend on plugins and extensions to perform different functions. These can be security risks if plugin developers do not take proper security measures when building them or if the platform does not properly verify plugins. It's also common for users to stick with older, vulnerable versions of plugins because they're incompatible with newer versions of the platform. Another source of security risks in low-code and no-code tools comes from their focus on collaboration and ease of sharing data. Users may grant sweeping access to other users or misconfigure applications in ways that attackers can exploit to steal valuable data.

TIP 💡: The Open Web Application Security Project (OWASP) has a list of 10 low-code/no-code security risks, containing descriptions of these risks and how to mitigate them.

The Future of Software Development

Research firm Gartner predicts that organizations will build 70% of applications with low-code and no-code tools by 2025. As these tools become more powerful and allow people to build more complex software, people usually ask if they will replace developers or become the standard for software development. The answer, for now, is no. On the contrary, low-code and no-code tools have created more job opportunities for developers, as programming skills are still essential for creating custom functionality.

I'll ask a more interesting question.

Will no-code + generative AI tools, like ChatGPT, remove the need for programmers? After all, we are starting to see no-code platforms incorporate generative AI into their systems, allowing users to create content through prompts. The answer is still no, as current generative AI tools don't always produce correct, high-quality code. They also don't have the insight experienced programmers use to solve complex, edge-case problems. However, these tools are improving every day, and as time goes by, they may reach that level someday.

While we wait for the Future...

Have you ever needed to remotely turn on a feature in your app without redeploying code? With ConfigCat, you can seamlessly toggle features on or off in real time, providing personalized experiences for your users, greater control over feature releases, and much more. ConfigCat integrates with no-code tools like Zapier and Zoho Flow, so you can automatically perform actions in other apps when you turn features on or off.

Sign up for ConfigCat's free-forever plan to get up and running quickly. Or schedule a demo, and our team will give you a personalized walkthrough of ConfigCat and its features. The most lovable feature flag service... ever.

You can also check out ConfigCat on Facebook, Twitter, LinkedIn, and GitHub.

Feature Flag Use Cases for Non-developers

Zayyad Muhammad Sani — Sun, 21 May 2023 21:57:04 +0000

Creating software products is a highly collaborative process nowadays. Developers, designers, product managers, marketers, and many others all work together to bring software to life and ensure a smooth experience for customers.

Though developers are responsible for building new features, the control of releasing these features might be better in the hands of people that are outside of engineering teams. We can give these people control with the help of feature flags.

What are feature flags?

Feature flags (or feature toggles) are basically on/off switches that allow you to toggle a feature in software after you've deployed it, letting you launch new features and change your software configuration without (re)deploying code.

With feature flags, organizations can build features into an app, and release them when they want, separating feature deployment from feature release.

Now that we know what feature flags are, we'll look at a few scenarios where non-developers can benefit from using feature flags.

Running experiments

If you're a product manager or marketer, you might want to perform experiments like A/B testing to improve conversion rates of a website. Using feature flags, the developers can build new variants, hide them behind feature flags, and hand over control to you. You can then use the feature flags to turn on the variants for whatever percentage or segment of users you want.

After running the experiments and determining what features to keep, you can use the feature flags to roll them out to everyone. If the results of the experiments are not positive, you can turn them off and go back to the drawing board.

Giving product demos

As a product manager or salesperson, you might want to give a prospective customer a specialized demo of an app. You can show them the features in different pricing plans by toggling feature flags. You can also use feature flags to simulate how the app will behave in highly specific situations.

Feature flags can also be helpful when you're trying to convince existing customers to upgrade to a higher plan. You can give the customers temporary access, so they can play with a live demo and decide if upgrading will be worth it. Once they've finished using the demo, you can leave the flag on or turn it off depending on the decisions they make.

Enabling specific features for customers

Many SaaS (Software as a Service) platforms offer custom plans that allow their customers to choose the features they want. In cases like this, it makes sense for customer support representatives to have access to feature flags, so they can turn on features for the customers after understanding their needs. They can also use feature flags to activate premium features for high-paying customers.

Running sales events

As the head of sales of an e-commerce website, you're likely running several sales events in a year. Each sales event usually has discounts, coupons, and in-app banners. After fleshing out the details of each event, you can communicate with the developers to implement the features you need, deploy them and hide them behind feature flags. When it's time, you can launch the event without having the developers do it for you. And when you want to end the campaign, you only need to turn the flags off.

Rolling back features

Sometimes, when a new feature of an app goes live, it might not work well despite rigorous testing, causing bugs in the app and users to complain. If an organization uses feature flags as part of its development process, the product manager can roll back to a stable version of the app with a feature flag. It's even better if they use a cloud-based feature flag service like ConfigCat, so even if complaints come in after work hours, changes can easily be rolled back at any time. When the developers fix the bugs in the feature, the product manager can turn it back on.

Conclusion

At first glance, feature flags might seem like something only developers should handle. But as we've seen, there are scenarios where it makes sense for non-developers to use feature flags. So whether you're in product management, marketing, or even the CEO of an organization, feature flags can give you control over features and functionality most relevant to your role.

You can check out ConfigCat on Twitter, Facebook, Github, and LinkedIn.

How to A/B Test in Nest.js with ConfigCat and Amplitude

Zayyad Muhammad Sani — Sun, 21 May 2023 20:59:59 +0000

A/B testing answers the question: "Which of these versions will bring me better results, A or B?". It allows you to test two variations of a page to see which has a more positive impact. This could mean increased sign-ups for a landing page, more purchases on an e-commerce store, or even smoother user processes in an app. It all depends on what you want to improve. How does A/B testing work though?

The A/B Testing Process

A/B testing starts off with some analysis. After analyzing data from your site, you notice a page or a component that you can improve. After you figure out a way to improve it, you implement the changes, but you don't immediately release it to everyone because you're not sure how they will respond to it. To limit the risk of poor reception, you release the change to a percentage of your users.

One group of users will see the current version of the page, called the control. The other group will see the new version, called the variant. Whichever version makes the most positive impact will become the default version for all users.

ConfigCat's feature flag service makes A/B testing easier with percentage-based targeting. Percentage-based targeting allows you to split your users into groups and turn features on/off for the groups you want.

Quick refresher: Feature flags let you launch new features and change your software configuration without (re)deploying code.

I'll walk you through setting up an A/B test in a Nest.js app with ConfigCat and analyze the results in the Amplitude analytics platform. Let's take a look at the app we'll be testing.

Sample app

I'll run this A/B test on a fictional student management SaaS(Software as a Service) platform. The platform has a newsletter that offers helpful resources for educators, but the sign-up conversion rate is low. From my analytics dashboard, I notice I receive about 1000 visitors per month, but only about 20 people sign up. So I decide to run an A/B test on the newsletter section's heading. Specifically, I want to change the heading "Subscribe to Our Newsletter" to "Get Exclusive Access to Content for Educators" to see if that will capture their interest and get them to sign up.

Prerequisites

If you want to code along, you'll need:

Node.js v16 or above
Some knowledge of Nest.js and TypeScript or JavaScript
A Nest.js app connected to ConfigCat.

If you don't have a ConfigCat account, create one here, then follow the steps in this tutorial to connect ConfigCat to Nest.js.

The site runs on a Nest.js backend and a React frontend. I'll focus on the Nest.js part because that's where most of the logic will live. You can see the complete source code of the app on Github.
Let's see how to set up.

Splitting users in ConfigCat

For this A/B test, I want to do a 50-50 split. To do this, I'll log on to my dashboard and do the following:

Click the TARGET % OF USERS option on the feature flag.
Type 50% into any of the boxes.

3 Save.

On the code side, we'll need to add a unique user ID to the getValueAsync call. ConfigCat requires an ID for each user, so it can uniquely identify them during percentage-based targeting.

import { Injectable } from '@nestjs/common';
import * as configcat from 'configcat-node';

@Injectable()
export class ConfigcatService {
  private readonly configcatClient = configcat.createClient('YOUR-SDK-KEY');

  // I'm using a random userID to keep things simple. Use login IDs, and other unique values in production 
  private userID = '343467';

  getFlagStatus() {
    return this.configcatClient.getValueAsync('newheading', false, {
      identifier: this.userID
    });
  }
  // I'll use this later in the controller file
  getUserID() {
    return this.userID;
  } 
}

That's all we'll need for both versions to go live. Let's hook up the app to Amplitude, so we can track the number of clicks the "Subscribe" button gets and then analyze the results.

Setting up Amplitude

To connect the app to Amplitude you'll need an Amplitude account. If you don't have an account, you can create one here.

When creating a new account or a new Amplitude project, you'll need to select an SDK and log a test event. Amplitude guides new users through this step while signing up. However, if you're an existing user, you'll have to create a new project to access the SDK selection screen. In your dashboard, navigate to Settings >> Projects and click the "Create Project" button.

Since this is a Nest.js app, we'll need the Node SDK. Select the NodeJS SDK and follow these steps:

Install the Amplitude Node SDK.

npm install @amplitude/node

2 Copy the code from the instructions page and paste it in the main.ts file to quickly log the test event. Remove the code from the file after Amplitude receives the event.

Sending Event Data to Amplitude

With the test event out of the way, we can create our custom event:

Create an Amplitude service file in your project folder.

nest generate service Amplitude

**INFO: **This command will create an amplitude folder with an amplitude.service.ts file in it. It will also add the file to the providers array in app.module.ts.

2 Open amplitude.service.ts and add the following code:

import { Injectable } from '@nestjs/common';
import * as amplitude from '@amplitude/node';

@Injectable()
export class AmplitudeService {
    private readonly client = amplitude.init('YOUR-API-KEY');

    sendClickEvent(userID: string, flagValue: boolean) {

        this.client.logEvent( 
            {
                event_type: 'Click Subscribe', // event name
                user_id: userID,
                event_properties: {
                    newHeadingEnabled: flagValue
                }
            }
        );
    }   
}

In the snippet above, I created the event "Click Subscribe" and gave it an event property newHeadingEnabled, which will hold the value of the feature flag. Whenever someone clicks the button that triggers this event, it will send the value of the feature flag to Amplitude.

NOTE: Every Amplitude project has an API key, which you can find under Settings >> Projects >> [Your Project Name]. Be careful not to use one project's API key for another.

For the final step, I'll import the Amplitude service in the app.controller.ts file and call the sendClickEvent method when the frontend sends a POST request.

import { Controller, Get, Post } from '@nestjs/common';
import { ConfigcatService } from './configcat/configcat.service';
import { AmplitudeService } from './amplitude/amplitude.service';

@Controller()
export class AppController {
  constructor(private readonly configcatService: ConfigcatService, private readonly amplitudeService: AmplitudeService) {}

  @Get('/flag')
  async getFlagStatus(): Promise<boolean> {
    const flagStatus = await this.configcatService.getFlagStatus();
    return flagStatus;
  }
  // New code
  @Post('/send')
  async handleClick() {
    const flagStatus = await this.configcatService.getFlagStatus();
    const userID = this.configcatService.getUserId();

    try {
      this.amplitudeService.sendClickEvent(userID, flagStatus);
    } catch (error) {
      console.error(error);
    }     
  }
}

The backend is fully set up. Let's briefly take a look at the frontend code that triggers the event so we can see how it all comes together.

// other code...
function submitForm(event) {
    event.preventDefault();
    const formData = new FormData();
    formData.append('email', email);

    try {
    // call to the '/send' route in the controller
      fetch('http://localhost:3000/api/send', {
        method: 'POST',
        body: formData
      });
    } catch(err) {
      console.log(err);
    }
}
// remaining code here

That's all the code we'll need for the A/B test. Let's create a chart in Amplitude and see the results.

Analyzing the Results

Creating an Event Segmentation Chart

I'll use an event segmentation chart to see how many users have clicked the sign up button.
On your Amplitude dashboard, do the following:

Click + New on the left sidebar.
Select "Analysis".
Select "Segmentation".

You should now see an area with input fields:

I'm going to add the "Click Subscribe" event and filter it by the newHeadingEnabled property.
Take the following steps to add the event to the chart:

Click the "Select Event" button and pick "Click Subscribe" from the dropdown.
Click + where and select newHeadingEnabled.
Select a value there, either True or False. If you see only one of the two values there, you can manually add the other one.

4 Repeat steps 1 - 3 for event B, the second event on the list.

Once you're done setting up the events, the results will appear in the chart area below. Scroll down to the chart area to see the results.

You can see the number of clicks for the event when the new heading is enabled and when it's disabled. Click the "Uniques" button to see the number of unique users that triggered the event. You can also change the view to bar chart and compare the results to the past.

Picking the winning variation

The data just started rolling in, so I'll need more time to see how both versions perform before I make my decision. For a more high-level look at A/B testing and its best practices, check out this article.

Conclusion

As the drive for growth and improvement increases, A/B testing is a handy tool to have in your belt. Whether the results of your tests are positive or not, you can easily toggle them with ConfigCat's feature flags. Iterate, experiment, and learn more about your users' preferences. ConfigCat supports simple feature toggles, user segmentation, and A/B testing and has a generous free tier for low-volume use cases or those just starting out.

Here's a quick recap of how I set up the A/B test:

split users into two groups in the ConfigCat dashboard
set up the Amplitude SDK
set up an Amplitude event with custom properties for the feature flag
created an Event Segmentation chart
filtered the event with its custom properties

Resources

You can stay up to date with ConfigCat on Twitter, Facebook, Github, and LinkedIn.

Implementing A/B Testing in Next.js with ConfigCat & Amplitude

Zayyad Muhammad Sani — Sun, 09 Apr 2023 09:34:55 +0000

Scenario: You’ve thought up a small change for your app. You write and test the code, and everything looks good. As you’re about to push it into production, you stop and ask yourself, “Will the users like this?”

You start having doubts, that maybe the idea isn’t as good as you previously thought. Still, you continue to have a strong feeling that it’ll make your app better.

One solution to this dilemma is to gradually introduce the change to a portion of users and track its impact on them. This is called A/B testing, and it’s a simple, low-risk way of letting your users pick which variant yields better results.

How A/B Testing Works

In an A/B test, you serve users a slightly different version of a page on your app or website. Half of your users will see this new version, called the variant. The other half will see the version they’re used to, called the control.

You track user activity on that page, and if the variant produces better results than the control, you make it the new default page for all users.

There should only be one difference between the control and variant. If there is more than one difference, it will be harder to know what change caused the improvement.

A/B testing is effective because users don’t know they’re participating in a test and because the versions are randomly distributed among them, leaving little room for bias. These two properties make A/B tests natural.

Let’s see how to implement A/B testing in a Next.js app with ConfigCat.

My A/B Testing Use Case

You can find the sample app’s code on Github.

This sample website allows people to download a free e-book. The website does its job well, but I believe that there’s room for improvement. I want to know if more people will download the book if they see its size on the download button. My target audience is conscious of download sizes, so I think they’ll appreciate this change.

Let’s take a look at the button’s code:

<button id="download" onClick={handleClick}>
  Download PDF{showSizeEnabled && <span>(5MB)</span>}
</button>

The feature flag’s value is stored in showSizeEnabled. The website currently doesn’t display the download size on the button because the feature flag is turned off for all users.

Note: I’ve already connected ConfigCat to my Next.js website. You can find out how to do that in this tutorial

To kick off the A/B test, I’ll segment my site’s visitors with ConfigCat.

Segmenting Users in ConfigCat

ConfigCat offers user segmentation features through targetting. I’ll use percentage targetting because I want 50% of users to see the download size on the button.

Here’s how you can set it up:

Navigate to your ConfigCat dashboard.
Turn on the feature flag.
Select "TARGET % OF USERS".
Type 50% in any of the text boxes.
Save Changes.

ConfigCat’s targetting feature requires a unique identifier for users when fetching the value of a feature flag. I’ll set that up in the website’s code:

export async function getServerSideProps() {
  const configcatClient = configcat.createClient('YOUR-SDK-KEY');
  // feature flag key
  const ffKey = 'showdownloadsize';
  // ConfigCat requires a unique identifier when using targetting; I'm using a made-up number here
  const userId = 343467;
  // set userId as the identifier
  const showSizeEnabled = await configcatClient.getValueAsync(ffKey, false, {
    identifier: userId,
  });
  // add userId to the props object, we'll use it in the 'HomePage' function later
  return { props: { showSizeEnabled, ffKey, userId } };
}

export default function HomePage({ showSizeEnabled, ffKey, userId }) {
  //...
}

Done! Now, if people visit the website, some of them will see the control and some of them will see the variant. I need to know how many users are clicking the button and what segment they belong to. For that, I’ll need an analytics platform.

Setting Up Amplitude

Amplitude is an analytics platform used for tracking user interactions in websites and applications. I’ll use Amplitude to collect and analyze data from my website for the A/B test.

If you don’t have an Amplitude account, create one here and follow the sign-up process until you reach the SDK selection page:

Select "JavaScript SDK" and you’ll be taken to the next page. There, you’ll have to set up Amplitude in your code and log a test event.

Take the following steps to log an event:

Open your command line application in your project’s root directory and run the command below.

npm install amplitude-js

2 . Import amplitude-js in the index.js file.

import amplitude from 'amplitude-js';

3 . Create an Amplitude instance in the HomePage function.

const amplitudeInstance = amplitude.getInstance().init('YOUR-API-KEY', userId);

Note: Make sure to replace YOUR-API-KEY with the key from your Amplitude account. You can find it under the Settings > Projects > ‘Your Project’ page.

4 . Create an event handler to send data to Amplitude when a user clicks the button.

function handleClick() {
  amplitude.getInstance(amplitudeInstance).logEvent('Download Button Clicked!');
}

5 . Click the button in your app to log the event to Amplitude.

Note: Make sure to turn off any adblockers you have. They might prevent you from logging the event to Amplitude.

ConfigCat offers official Amplitude integration. It’s not required for working with Amplitude but it’s recommended. Check out how to activate the integration here.

I’ve now connected Amplitude to my site. Let’s see how to send event data over to Amplitude.

Sending Data to Amplitude

Amplitude does not automatically know what my user segments are. I’ll have to send the status of the feature flag to Amplitude for each user that clicks the button. To do this, I’ll need to create a custom user property with Amplitude’s Identify API.
Add this code under the Amplitude initialization in the HomePage function:

const identity = new amplitude.Identify();
// custom Amplitude user property
identity.set(ffKey, showSizeEnabled);
amplitude.getInstance().identify(identity);

The set() method receives a key-value pair as its argument. It creates a custom user property with the key as the name, "showdownloadsize" in this case. The value for this user property will be true or false, depending on what segment the user falls under.

If you’re following along, your code should look similar to this:

import Head from 'next/head';
import Image from 'next/image';
import Layout from './components/layout';
import * as configcat from 'configcat-js-ssr';
import amplitude from 'amplitude-js';

export async function getServerSideProps () {
    const configcatClient = configcat.createClient("YOUR-SDK-KEY");
    // feature flag key
    const ffKey = "showdownloadsize";

    // ConfigCat requires a unique identifier when using targetting; I'm using a made-up number here
    const userId = 343467;
    // set userId as the identifier
    const showSizeEnabled = await configcatClient.getValueAsync(ffKey, false, { identifier: userId });

    return { props: { showSizeEnabled, ffKey, userId } };
}


export default function HomePage ( { showSizeEnabled, ffKey, userId } ) {
    const amplitudeInstance = amplitude.getInstance().init("YOUR-API-KEY", userId);

    const identity = new amplitude.Identify();
    // custom Amplitude user property
    identity.set(ffKey, showSizeEnabled);
    amplitude.getInstance().identify(identity);

    function handleClick () {
        amplitude.getInstance(amplitudeInstance).logEvent('Download Button Clicked!');
    }
    return (
        // markup here
        <div>
        </div>
    )

That’s all the code we’ll need for the A/B test. All that’s left is to set up a chart in Amplitude and view the results.

Setting up Segmentation Charts in Amplitude

Amplitude offers several charts for analysing events. For this A/B test, I’ll use the Event Segmentation chart to view how many users have clicked the button depending on the segment they fall under.

Let’s create an Event Segmentation chart:

Click the "New" button on the sidebar.
Select the "Analysis" option.
Click "Segmentation".

Once you’ve created the chart, you should see this area with several input fields:

You can select events from the Events module on the left. You can use the Segmentation module on the right to categorise your users based on the conditions you want. My site’s visitors are segmented based on who sees the download size and who doesn’t.

Let’s reflect this in the chart:

Select "Download button clicked!" from the "Select Event" dropdown.
Rename "All Users" in the Segmentation module to "Download Size Enabled".
Click "Add Segment" and name the new segment "Download Size Disabled".
Click the "Select property" button under each segment and pick the custom "showdownloadsize" property sent from the website. Set the property values to "True" and "False" respectively.
Give your chart a name and click "Save" in the top right corner.

You should now see the chart populated with data. Click the "Uniques" tab so you can see the number of unique users who triggered events in your app. You can also change the chart view to "Bar chart" for a more straightforward look at things.

That’s all for setting up, now it’s time to analyze the data.

Analyzing the Results

From the chart, we can see that more users clicked the button with the download size enabled. This means that the change was a positive one. I’d still however have to wait a little while and get more data before I come to a conclusion.

When you’ve completed the A/B test, there’s no need to keep the feature flag logic in your code anymore. Make sure to remove the logic from your code and delete the feature flag from your dashboard. Check out this post for more A/B testing best practices.

Note: Since this isn’t a live website, I don’t have any users (except myself). I mimicked different users by changing the value of the identifier that I initialized ConfigCat with. This way, Amplitude thinks that it’s receiving unique user events from the website.

// old userId - 343467
const userId = 55555;

Summary

A/B testing helps you clear the doubts you have when introducing small changes to your apps. Feature flags simplify the A/B testing process, making it easier for you to improve your app’s user experience and grow your business.

To recap, we learned how to conduct an A/B test by:

creating user segments in ConfigCat.
installing the Amplitude SDK in a Next.js app.
sending event data to Amplitude.
analyzing user event data in Amplitude.

You can find the complete code for the sample app here.

You can stay up to date with ConfigCat on Twitter, Facebook, Github, and LinkedIn.