8 posts tagged with "user targeting"

Many people think of the Internet as a place where they can find information or communicate with others. However, the Internet is far more than that, it is also growing with its capabilities. Holding data resources that support the lives of billions of people around the world.

One way to transfer data on this great thing we call the Internet, while having a good development pipeline and maintaining security, is to construct a Web API.

Software development is a really challenging endeavor. A lot of time and energy has to go into making sure that customers like what you're building for them.

Many people make the mistake of thinking that product development mainly consists of coding. Developing a product (ideally) needs specialists, managers, tactics, and various tools. A good idea can indeed go a long way, but if you want to give your product the highest possible chance to penetrate the market, then you need to allocate all possible resources that you have available to throw at it.

Let's say you've just built a new feature, but it's not ready for a full release just yet. So, you decide to test it with a small group of people.

You can go about it in two ways - deterministic or random. The first way lets you specify people by name, email, company or any other attribute you know about them. The latter uses fancy math and probability to randomly assign users into groups. Let's see how you'd accomplish both using ConfigCat's feature flag services. For context, ConfigCat is a developer-centric feature flag service with unlimited team size, awesome support, and a reasonable price tag.

Picture this: You’ve added a new feature to your software, linked it to a feature flag, and deployed it to production. Now, you’d like to enable this feature for a subset of your users to get their feedback before you take the leap and roll it out to everyone.

But who gets to see this new feature first? How do you choose the first user segment? How do you use feature flag rules to target them?

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

Let’s look at some typical real-world examples of how you can do canary releases using ConfigCat.

Features can sometimes reach a high-enough level of complexity that simply cramming the entire thing behind a single feature flag and calling it a day becomes widely impractical.

More modular feature control needs to be thought of and implemented beforehand. Since such scenarios happen quite often all throughout development, a more advanced form of feature flag management is needed.

Understanding the Flag Hierarchy​

While the base concept of feature flagging remains untouched (in the sense that they still toggle stuff on and off), feature flags nowadays tend to act more like an interconnected web of toggles where they may or may not be dependent on each other to run. The main benefit of all this added complexity is the ability to use flags to control certain parts of a feature in a very modular and clean way.

Separating your customers into distinct segments will help your product in all sorts of ways. It can help you track the usage of your app in a more meaningful and granular way. It can also reveal how specifically different segments behave differently, which will help you prioritize future feature development as well as focus your marketing efforts.

Focusing on frontend applications, we introduced sensitive text comparators to make sure sensitive info (like email address, username) is kept hidden in targeting rules.

Satisfying the feature request of our customers from the mobile app development industry, ConfigCat now supports semantic version (SemVer) based user targeting. Typical use case where app builders wish to enable or disable features based on the iOS or Android version on the device their app is running on. For example deciding if 2.3.40 is less than or equals 2.30.4 sometimes not that straightforward by only using the traditional < > = comparators.