Skip to main content

Parameter Stores

Parameter Stores are a new way of organizing and managing parameters in your mobile app via the Statsig console. They are now available for Statsig Android, iOS, and React Native sdks.

What is a Parameter Store?​

Rather than thinking in terms of Statsig entities (Feature Gates, Experiments, Layers, Dynamic Configs), Parameter Stores allow you to think in terms of parameters - things in your app that you want to be configurable remotely. Parameters decouple your code from the configuration, much like Statsig Layers decouple your code from the specific experiment. It is a level of indirection that allows you to run any set of experiments, or change gating or values on the fly, without hardcoding an experiment name in your app. Each of these parameters that you define and check can be remapped at will between statsig entities - provided you maintain the same type for that parameter. As a result, the parameters will receive different values depending on the StatsigUser you initialize the SDK with. These dynamic values can be updated at any time, without a mobile code change, and without waiting for your mobile release cycle.

How should I use Parameter Stores?​

Here is a suggested workflow:

  1. Create a parameter store for you team or project. Parameter Stores are an object to hold related parameters.
  2. As you are adding to your mobile app, consider which variables you'd like to be controlled on the server-side, rather than hard coded into your app. These can be things like:
  • A boolean parameter to control access to a new feature. Even though you may be used to using Feature Gates for boolean based feature management, start with a boolean parameter instead
  • A string parameter for a text resource that you may want to swap or experiment with
  • A number parameter that you use as input to an onboarding flow (onboarding_steps), a list length to truncate at, etc ... and many more
  1. You can start simple with a static value for that parameter - whatever you would have hard coded into your app can be the static value
  2. Later, when your app is shipped and the feature is ready, you can remap that parameter to a feature gate/experiment/dynamic config/layer in order to test different variants, or target different variants
  3. When you are done experimenting, you can update the static value, or gate it to particular app versions, all in real time across you mobile apps that are already released.

I'm not sold​

If you've had this problem already, you'll recognize the power immediately. If you're just getting started using a Statsig SDK in your mobile app - start with Parameter Stores from the beginning. Parameter Stores are inspired by Facebook's Mobile Config. Uber's engineering blog explains this same idea. Firebase Remote Config works similarly. The most serious companies in mobile use this to move faster, maintain backwards compatibility, and experiment more freely. The extra configuration in the Statsig console is not as convenient as creating a gate, but it saves you in the future when your app version is shipped and does not hard code any Statsig entity values. That's why we are only introducting Parameter Stores for mobile - your backend or website can usually be updated much more quickly, so you can swap out Statsig entities as you please.

Parameter Stores are available in:

  • Android SDK v4.33.0+
  • iOS SDK v1.45.0+
  • @statsig/js-client v1.4.0+