Overview

This article provides a detailed reference for App Config, focusing on its parameter structure, configuration logic, and practical usage scenarios.

It explains how App Config is used to generate both the default configuration embedded into the app build and the current configuration resolved under additional user conditions, such as segmentation rules or A/B test participation.

The following sections describe the role of the default configuration, how App Config parameters are structured, and how different parameter groups are combined to resolve a single configuration state.

Default Configuration

The default configuration is the baseline configuration the application launches and operates with, regardless of segmentation, A/B tests, or additional conditions.

It is embedded into the app build and represents the initial set of parameters available to the app before any Remote Config rules are applied.

The default configuration guarantees that the application always starts in a valid and predictable state — even if network rules are not yet applied or the user does not match any segmentation criteria. All Remote Config rules, segmentation logic, and A/B tests are applied on top of this configuration, modifying individual parameters rather than replacing it entirely.

Because of this, the default configuration serves as the reference point and foundation for all configuration logic in the application.

App Config Parameter Structure

App Config parameters are divided into two logical groups, each serving a distinct purpose.

Main fields define the baseline configuration context. They are used both to generate the default configuration and to validate the current configuration, and are typically configured once. After that, the main block does not need to be modified when downloading default configurations for different app versions, unless the baseline configuration itself changes.

Additional parameters complement the main fields and are used only to validate the current configuration under extra conditions — such as segmentation rules, user states, or A/B tests. They do not affect the default configuration and are not included in the production build.

All selected parameters are applied together to resolve a single configuration state. The resulting JSON configuration can be downloaded from Remote Config > App Version.

As a result, App Config can be used both to verify the default configuration and to validate the current configuration under additional conditions.

What is a JSON Config

A JSON configuration is a set of server-defined parameters such as feature flags, LiveOps settings, and A/B test conditions. Downloading the JSON configuration allows you to see the exact configuration state the app would receive under the selected conditions.

Important

Changes made in App Config do not affect real users.

• The main block defines parameters used for generating the default configuration.
• Additional fields are used only for testing and validation. They are not included in the production build.

App Config allows testers, product managers, and marketers to reproduce app behavior without code changes or developer involvement.

General Information

Each application has a single App Config card. It is reused and updated as needed; separate cards per app version are not required.

How to Create an App Config

1. Open App Config.
2. Click Create New.
3. Fill in the required fields.
4. Save the configuration.

Settings Overview

Although many fields mirror parameters in Remote Config > Segmentation, here they are used solely for testing configuration states, not for segmentation logic.

Application

The application for which the configuration is created.

• Selected once.
• Becomes locked after saving.

Device

Defines the device profile used to generate the configuration.

Android

• phone-xxhdpi — mid-range
• phone-xxxhdpi — flagship
• tablet-xhdpi — tablets

iOS

• iPhone12,3 (iPhone 11 Pro)
• iPhone14,5 (iPhone 13)
• iPhone15,2 (iPhone 14 Pro)
• iPad8,9 (iPad Pro 11")

Generated In-App Purchases

This section allows you to specify parameters related to the user's previously completed in-app purchases. These parameters help simulate and validate configuration behavior for different payer segments: non-payers, low-payers, and high-payers.

The section contains two fields:

Generated In-App Purchases Revenue

Indicates the total revenue generated by the user through in-app purchases over their entire lifetime in the app. The value is specified in US dollars (USD).

Available Fields

You may select one, several, or all of the following:

• Impressions d0 — RV impressions accumulated by day 0
• Impressions d1 — by day 1
• Impressions d4 — by day 4
• Impressions d7 — by day 7
• Impressions d14 — by day 14
• Impressions d30 — by day 30

Each field accepts one numeric value.

UA (User Acquisition)

Specifies user acquisition attributes used to validate configuration behavior for different traffic sources, campaigns, and ad groups. This section allows you to reproduce scenarios for users coming from specific marketing channels.

The following parameters are available:

Media Source

The traffic source from which the user was acquired. This is a dropdown containing all media sources detected in the system.

Only one value can be selected.

Use cases:

• testing configuration behavior for users acquired from a specific traffic source
• validating segmentation rules for paid vs. organic traffic
• reproducing behavior associated with particular ad networks

Acquisition Campaign Name

The attribution campaign name associated with the user. This value must be entered manually.

Only one value can be selected.

Use cases:

• validating logic tied to specific UA campaigns
• testing A/B tests applied to users from individual campaign funnels
• QA verification of campaign-level segmentation

Acquisition Ad Group Name

The attribution ad group name from which the user was acquired. This value is also entered manually.

Only one value can be selected.

Use cases:

• validating segmentation based on ad group or creative set
• testing behavior tied to specific creative structures
• reproducing granular acquisition-based scenarios

A/B Test Configuration

Specifies A/B tests and test groups used to validate configuration behavior. This section allows you to reproduce the configuration a user would receive when participating in specific experiments.

The following rules apply:

• Only A/B tests with Running status are displayed in the dropdown.
• For a single A/B test, you can select only one group to generate a valid configuration.
• You can add multiple A/B tests using the Add A/B Test Configuration button.
• Each selected test must have a corresponding group specified.

Use cases:

• validating configuration values for a specific A/B test group;
• QA verification of experiment setup and group assignment;
• reproducing user behavior under multiple active experiments.