Have you ever been stuck in a phase where you are endlessly waiting to deploy an app update? It might be due to a setback in feature testing, a lack of current resources, or a delay in team communication.
Most of the time, there is immense ambiguity surrounding how users might perceive a new feature or change in an existing feature. If you are a decision-maker or part of the product management team, you are also rendered incapable of performing minor releases or tests without the help of the technical team/developers.
The remote configuration
feature helps make changes to application behavior and appearance without needing an update. It simply changes the server-side configurations by helping you enable or disable them from the interface (UI) of the application.
For example, say you want to run a script of code for a specific group of users - like changing the language preferences for a country- you can just enable it for that segment with a few simple clicks using remote configuration.
Let’s look deeper into the various ways you can implement remote configurations using product analytics tools.
Integrating remote configurations into your product application
Releasing updates (minor or major) cannot get easier than with the use of remote configuration. It can be applied to many different cases of product changes, such as time-critical updates, percentage deployment, infrastructural change, and more.
Implementing these changes for your product management with remote configuration involves a few methodologies. Before we look into that, however, we should know that there are certain filers that we need to apply for remote configuration to work.
Product analytics tools
typically have two main filters that can be applied to remote configurations that help you enable these changes in your application, called conditions and parameters:
Conditions are filters you can apply when you perform releases that will help you provide features to a particular segment of users or app instances. These may be a set of high-value customers
, users from a certain region or country, users with any particular OS specification, etc. The user segments can also be based upon more specific categories, such as the app version or users who made a purchase.
In a good product analytics application, you will be able to add any number of applicable conditions and import configs
from other apps.
Parameters are unique values that can be assigned to a filter. Therefore, they exist as parameter names (key) and their respective value in pairs. Various teams can view and set these parameters from their product analytics dashboards and use them.
These parameters have values generally assigned to them as true or false, which is to say whether they are applicable or not applicable to some condition. For example, if you want to display a language change option for certain countries for your product, you can simply set that parameter as true for users from those countries only.
Now, let’s look at some of the main capabilities of remote configuration.
Launch updates for sections of users with ‘percentage rollouts’ and ‘A/B tests’
Remote configuration helps companies do this by rolling out changes to a small percentage of users that are randomly selected. These random percentage of users are now your test group, where you can immediately see how they respond to these new changes. To begin with, this percentage can be as small as 1% of users and usually not higher than 5% or 10% of the total user base.
Based on the feedback from this small section of feature users, you can either expand the user scope or choose to go all out with the feature across the whole user base.
is another great method for feature testing where you can test features for two groups of users. This method helps you make two different versions of application behavior instead of one. Common test scenarios in A/B testing are changes in web pages, like the usage of a different palette of colors, call-to-action buttons (CTAs), or text/element placements. You can then observe which one brings more engagement and leads or if one helped to solve an issue better than the other.
Test major application changes on beta user groups
Some releases of features can be more of a gamble than normal, where you prefer to know in detail how users were able to utilize features.
Establishing a beta test group is a great way to test features with real users who request features. They can also sign up to use your application to test experimental changes. They are a great resource for companies who need specific feedback on features. They are also very useful for products that keep updating on a regular basis.
In this way, you can completely forego the risks involved in experimenting with unsuspecting users, who could be instantly put off by bugs in your software.
Navigate risky rollbacks and pull the switch on unwanted features
Product rollbacks are incredibly humiliating affairs, where you have to pull an update entirely from everywhere that it has been deployed and made available. What if, instead, you could just disable particular features or parts of the application without affecting the whole app update?
With remote configuration, you can instantly pull the kill-switch on unwanted features. You can even use the ‘sunset’ method, where you can slowly eradicate old features for segments of users.
Enable every team to control changes
Sometimes, some teams seem to have more control over implementing changes that affect the whole organization. This can be detrimental to the overall product health as it limits each team’s contribution to product development.
Remote configuration is one way of eliminating sole dependence on the technical team to make changes, thus empowering every team to take control of product changes. This can be achieved in two ways.
One is to roll out changes to internal teams, such as the QA team and then the marketing and product teams, before making final deployments. This is especially true if there is a specific feature that has heavy involvement from other teams or if it is a major rebranding where you need to see things play out on an experimental basis. After you have ensured that everything is working perfectly, you can simply enable the feature for all users everywhere. The other is to enable teams to take control of simple updates to the UI, such as enabling or disabling push notifications
, changing the elements/content, or deciding on feature-visibility to some users.