As a first step, name your remote configuration and select a context (part of your application) you’d like to manage remotely. Examples of app contexts you may configure with us:
main_paywall: to set up settings for different user segments for your main paywall.
main_paywall_products: to manage only products remotely.
onboarding: to set up the entire user onboarding journey.
onboarding_step_2: to configure only specific steps of the user onboarding flow.
[your_key]: to set up any part of your user’s monetization experience.
Qonversion Remote Config provides you with flexible in-app values using which you can set up any behavior and appearance of your app. The core of these in-app values is a plain JSON file consisting of key-value data. We support the following data types:
String.
Use this option to validate pricing, communication, or visual hypothesis.
Examples: native.subs.full.v4.w.8.99.trial.7d, Unlock Fast and Secure Browsing, #3076FF, etc.
Number.
Use this option, for example, to show only a subset of your onboarding screens.
Examples: 2, 5, 23, etc.
Boolean.
Use this option to turn on or off some features.
Examples: true, false
Json.
Use this option to validate advanced changes in your app’s behavior.
Qonversion Remote Configs and Experiments share single methods to get configurations. You can distinguish the source of the result received by looking at the source field. Learn more about fields available.
To receive the configuration with the Context key set, call the following Qonversion remoteConfig method.
Qonversion.shared().remoteConfig(contextKey: "my_context_key") { remoteConfig, error in // Use remoteConfig here}
In case you’re using configurations with empty Context key, call the same method with no arguments added:
Qonversion.shared().remoteConfig { remoteConfig, error in // Use remoteConfig here}
If necessary, you can also request a list of remote configs for all the context keys, including the empty one.
Qonversion.shared().remoteConfigList { remoteConfigList, error in // Use remoteConfigList here}
If you need remote configs for a specific set of context keys, just use the following method.
Qonversion.shared().remoteConfigList( contextKeys: ["my_context_key", "another_context_key"], includeEmptyContextKey: true // to include remote config without context key) { remoteConfigList, error in // Use remoteConfigList here}
How the current payload was assigned to the user. Either automatically or manually.
type
One of the following: experiment control group, experiment treatment group, remote configuration.
contextKey
Context key assigned to either experiment or remote config.
Please, note:
If you’re using the Qonversion Experiments feature, the remoteConfigobject will also contain experiment-related fields.
Qonversion assigns eligible users to launched experiments once the remoteConfig is called. We also recommend paying attention to the Segmentation rules for the configuration.
We highly recommend testing if your app works properly with the changes you want to roll out to your users. You can do so by following the following steps:
Copy the ID for your remote config
Pass the values to Qonversion SDK by using the attachUserToRemoteConfiguration method
Qonversion.shared().attachUser(toRemoteConfiguration: "your_remote_configuration_id") { success, error in // handle result}
In case your user has already been attached to another configuration, use the detachUserFromRemoteConfiguration method.
Qonversion.shared().detachUser(fromRemoteConfiguration: "attached_remote_configuration_id") { success, error in // handle result}
Call the Qonversion remoteConfig method. Now Qonversion SDK returns data associated with previously set remote config.
Validate your app logic without launching the configuration.
Do not forget to remove the usage of the attachUserToRemoteConfiguration method before your app release. Otherwise, all your users may be exposed to only one remote config.
Qonversion Remote Config has flexible options to target a desired user segment.Segment users by:
App install date
Use this option to assign the configuration only to new app installs.
App version
Use this option to assign the configuration only for users with the app version with the new features implemented.
Country
Use this option to run new behavior only in selected countries.
Store
Use this option to target only a specific store (Apple App Store or Google Play).
User’s active subscription
Use this option to target only users with/without any active subscriptions or having a specific one.
Purchased product
Use this option to target users based on their purchase history. You can select specific products or use (any) to match users who made at least one purchase, or (none) for users with no purchase history. Unlike “Active subscription”, this filter checks all purchases regardless of their current status (active, expired, or cancelled).
Last purchase date
Use this option to target users based on when they made their most recent purchase. For example, you can target users whose last purchase was more than 60 days ago to identify churned users.
Once you have added all the necessary properties to your in-app configuration, validated changes in your app, and assigned desired segmentation rules, the only thing left is to click the Create button to move the configuration from Draft to Active state.
To enhance the reliability of remote configurations, consider utilizing Qonversion fallback files. These files will serve as a backup in case of network provider errors or system failures, ensuring that your application continues to receive essential data and avoids any downtime. For more information on fallback files and how to install them, please refer to this page.What’s Next
