What are those Remote Settings, anyway?
It’s been a while since the IT community realized that sometimes code changes need to be brought out in stages instead of sharing it with the entire audience at once. That’s how the feature toggling (aka feature flags) technology came about. Here at CleverPay we call it Remote settings.
The principle behind it is very simple: instead of swapping out the old code for the new one, an app instead supports both versions. A remote server handles the ability to switch between the two, telling the app which variant to serve to which user.
This tool can be used for various purposes, but the most popular uses are these: gradual feature roll-out (e.g. via invites, to avoid system overload or bug overflow) and split-testing. Whatever the purpose, this technology is extremely widespread and some companies even share their open source implementation: Disqus has gutter, Etsy has feature, Reddit has a feature of their own.
What do Remote setting consist of?
Any Remote setting consists of the following:
- A name. Make sure the names are straightforward to avoid any confusion within the team. You should also add a description containing values that the app can read correctly;
- A set of parameters. Each parameter consists of a user segment and a corresponding text value that controls the functionality/visuals these users will get. The settings can be so precise that you could tailor your app to a single user.
When using Remote Settings with CleverPay SDK one must account for certain important details:
- Users don’t get the Settings if the first launch is offline. Data acquisition requires a connection to the internet, so you might not get anything in return for the initial request. That’s why you should specify default values;
- Local caching in-between the requests. CleverPay automatically requests the most recent data quite frequently and all of it gets cached in-between the requests. Currently, we have no cache invalidation mechanism, new data just replaces the old one. When a user’s subscription expires we request the most recent updates, but if the request fails it doesn’t trigger cache invalidation. If you hook up a feature to a Setting, make sure you set up your own cache invalidation logic;
- The Human Factor. If you’re counting on getting one of the two possible values, don’t forget to factor the possibility of human error. Say, an intern enters his username, home address or his mom’s phone number into the admin panel. Wouldn’t it be best to have a fallback to a default value if you get a value that stands out?
How is CleverPay different from Firebase Remote Config?
Remote Config does not provide real-time data. And that’s ok. Feature toggling includes various types of features to be managed.
Martin Fowler, «Feature Toggles (aka Feature Flags)»
Remote config deals primarily with the so-called “release toggles”, which implies a certain behavior:
- frequent caching in-between requests, while there’s no out-of-the-box solution to forcefully obtain the most recent data;
- Even if you manage to successfully obtain the latest values, our tests show that it takes anywhere from 5 to 15 seconds. That’s not the speed of processing that could facilitate an experiment in a number of scenarios (take onboarding, for one). You can’t trust this tool with handling the rapidly changing values.
CleverPay serves non-cache data for each request with the average response time under 300ms. You can also forcefully obtain the most recent data anytime.
How to stop hard-coding the link between the product and feature availability
There are several potential pressure points to speak of here:
- How to set it all up in the first place?
- What are the safe default values one can set in anticipation of a human error or an offline first-time launch?
- How to control the payment page interface should the feature set and pricing change?
How to set it up. It’s all very simple: each individual feature of the app has its own Remote setting. If you decide to make a feature available to, say, users who purchased the SuperPremium product, you’ll create a relevant SuperPremium user segment and set the value at
yes for those. If you change your mind, switching the segment or changing the value will take no longer than a minute.
Safe default values. Usually, the default values are the values that reflect your business model at the moment. If 3 out of your 5 features are available via subscription only, you can set the 3 features as locked by default. Rest assured: if we couldn’t get the most recent data on settings it means a user doesn’t have any relevant purchases (yet).
How to manage the interface. There are many apps out there with an interface that lists the features that belong to a subscription plan. There are many ways to manage such interfaces:
- You can create a separate setting that will feed to the client the current lineup of paid features. This is the option that suits you best if you want to find out how making a paid feature free affects your metrics. That’s the way to do it quickly and effortlessly;
- You can set up Custom data for the screen and specify which elements on the list to display. This option is a bit more complicated, however, it grants you total control: you can generate any number of screens, displaying only the prescribed features. That way you get to test out the performance of various subscription plans as well as to sell features as Non-consumables.
That’s what our set up looks like for the user who has access to the debt tracking feature.
On the left, you can see a list of self-explanatory segments. On the right — a simple «yes» that grants the users access to the feature. The most amazing thing about it is that the segments are fixed in time, no new users can get on the list. Once we’ve committed to offering a certain feature set, we don’t go back on our word — the users will have access to the service forever and we won’t have to spend any time or effort managing their plan.
And here’s what the main screen settings look like:
Our main screen has a list of features available to that particular subscription group. A parallel branch has Premium users (exp. 12) and all of their features (excluding debts, reports and shared). Both screens are shown in the same spot in the app, one after the other and their maintenance requires no extra effort.