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")

Orientation

Specifies the screen orientation in which the app operates on the selected device. This parameter is useful when UI layout or feature behavior differs between portrait and landscape modes.

Available values:

• portrait — the app operates only in vertical orientation
• landscape — the app operates only in horizontal orientation
• both — the app supports both orientations; the configuration is not tied to a specific mode

OS Version

Specifies the operating system version used to generate the configuration. This parameter helps reproduce cases where app behavior, SDK logic, or system APIs differ across OS releases.

Used for:

• validating compatibility with older and newer OS versions
• testing features that rely on OS-specific APIs or permissions
• verifying ATT flows, system dialogs, and permission prompts
• reproducing layout or behavior differences caused by OS upgrades

Initial App Version

Specifies the first app version installed by the user. This parameter is important because many flows and features depend on the user’s initial installation version.

Used for testing:

• different onboarding flows introduced across versions
• new or deprecated features that depend on version ranges
• version-based A/B tests
• LiveOps logic tied to installation history
• upgrade and migration scenarios (e.g., moving from older builds)

Is New User

Indicates whether the user is new.

• Default behavior: false (existing user).
• true > configuration for the first app launch.

Used for testing onboarding, welcome offers, new-user A/B tests, early-stage feature availability.

Language

Examples: English, French, German, Spanish, Japanese.

Country

Examples: United States, Canada, Germany, Brazil, Japan.

Used for validating regional rules, A/B tests, LiveOps, and localized parameters.

Launch Date

Specifies the date and time at which the configuration should be generated. This parameter allows you to reproduce the configuration state at a specific moment — for example, when a LiveOps campaign starts or an A/B test becomes active.

Used for:

• validating LiveOps campaigns scheduled to start at a specific time;
• testing A/B tests activated at defined timestamps;
• confirming the correct behavior of time-based configuration logic.

Additional Parameters

The basic App Config fields are used both for generating the default configuration and for validating the current configuration under different conditions. Additional parameters do not override basic fields — they complement them and further narrow the configuration conditions.

Days After Launch

Specifies how many days have passed since the app was installed. The count starts from the first launch, regardless of whether the user opened the app again on the same day or not.

• 0 — the installation day (first launch day)
• 1 — the next calendar day
• 2 — the second day after installation, and so on

Days of Week

Specifies the day of the week for which the configuration should be generated. This parameter is used when testing logic that depends on calendar days, such as weekly events, rotations, or scheduled LiveOps behavior.

You can select only one day of the week.

If the field is set to “–”, the configuration is generated for the current server day of the week.

IDFA

Specifies the user’s IDFA (Identifier for Advertising) consent status. This parameter allows you to validate configuration behavior for different privacy and attribution scenarios.

Available values:

• Yes — the user has granted permission to collect IDFA
• No — the user has denied permission
• Unknown — the user’s status is unknown (for example, the prompt was not shown or the response is unavailable)

Only one value can be selected.

Use cases:

• testing feature behavior that depends on tracking authorization
• validating attribution or ad-related logic under different consent scenarios
• simulating users with missing or undefined IDFA status

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).

Only one value can be set.

Used for:

• testing configuration behavior across different payer segments
• validating logic applied to payer vs. non-payer groups
• checking A/B tests that depend on revenue-based segmentation

Bought In-App Purchases

Indicates the total number of in-app purchase transactions completed by the user.

Only one value can be set.

Used for:

• testing logic tied to purchase count (e.g., first purchase, repeat purchases)
• validating segmentation rules based on user purchasing activity
• simulating different purchase behavior scenarios

Rewarded Video Impressions

Specifies the number of rewarded video (RV) ads the user has watched by a specific analytical milestone X (DX). These values are cumulative, meaning they represent the total number of RV impressions watched from D0 through DX (inclusive), regardless of when exactly the impressions occurred.

How cumulative RV logic works

Analytical checkpoints might include: D0, D4, D7, D14, etc.

At each checkpoint, the system records the total number of RV impressions accumulated up to that moment. Later checkpoints inherit earlier totals and increase only when new impressions occur.

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.