Application Feature

Overview

An Application Feature (or simply feature) in Magify is a configurable container of parameters that control specific behaviors or settings in the application. These parameters are delivered via Magify and interpreted by the client-side logic of the app. Features enable flexible configuration of game or app functionality without requiring a new app version, as long as the logic for handling the feature is already implemented in the client.

App features require advanced Magify SDK integration and proper service initialization. For detailed setup instructions, see the App Features article in the Unity SDK section.

Key Properties of Features

• No App Update Required: Features can be created or updated server-side at any time. However, they will only take effect if client-side logic for handling the feature key is already implemented.
• Client-Side Logic Required: The app must be able to recognize and apply each feature key; otherwise, changes in Magify will have no effect.
• Flexible Usage: Features can be included in segmentation rules, remote configurations, and A/B testing experiments.

Feature Use Case Examples

The following are example use cases of how features can be applied.

Enabling or disabling specific game modes.

Managing In-Game Ad Banner Display.

Customizing the color scheme or visual theme of specific sections.

Configuring reward quantity and type in victory chests.

Default Features (Optional)

Magify provides a set of default system features, available under the Default Features (Optional) section, that are used internally by the SDK. These features control specific logic and behaviors directly within the SDK. They do not require additional handling on the client side but are still included in the configuration and can be accessed by the application if needed.

If you add any of these features to your application via Remote Config → Configurations → Application Feature, the SDK will automatically recognize and apply the corresponding behavior wherever it is supported — without requiring any additional client-side implementation.

Creating a New Application Feature

To create a new feature in Magify, follow these steps:

1. Navigate to Remote Config → Configurations → Application Feature → Create New
2. Select the appropriate application.
3. Fill in the Key field.
   Important: The feature key (field key) cannot be changed after the feature is created. Once the feature is saved for the first time, the key becomes locked and read-only. Below is an example of how this appears in the interface:
   
   
   
   
   
   
   

   

4. Fill in the Value field.
5. Click Save to apply the changes.

The screenshot below displays the default value of the feature along with the associated configuration fields:

Additional Fields for the Default Feature Value

1. Description This field is visible only within the admin interface. We recommend using it to describe the feature’s functionality, purpose, and any additional notes for future reference.
2. App Version From / To These fields define the range of app versions for which the default value of the feature should be delivered.
   • App Version From: the minimum version (inclusive).
   • App Version To: the maximum version (inclusive).

Supported Data Types for Feature Values

The Value field in an Application Feature supports the following data types: object, string, integer, number, boolean, array, null.

If the Value field is left empty when the form is saved, the system will automatically assign a default value of null.

Below are examples and usage guidelines for each supported type:

string

Use double quotes around the value.

boolean (true / false)

Used to enable or disable a feature.

number

Floating-point numbers representing decimal values.

integer

Whole number values.

object

The object type allows grouping multiple related parameters under one feature key.

array

The array type is used to define an ordered list of values.

Feature Value Distribution Logic

Each Application Feature in Magify is structured into three blocks:

1. Default Value
2. Segmented Values
3. A/B Tests Values

When the client requests a configuration, Magify evaluates applicable feature values in the following priority order:

1. A/B Test assignment – If the user matches any active test group.
2. Segmented value – If no A/B test is matched but the user fits a segment.
3. Default value – Used if no other match is found.

More details on how to create segmented features, the meaning of their configuration fields, and how to set up A/B test features can be found in Segmented and AB Test Features article.

Within each configuration block — whether A/B Tests or Segments — values are evaluated from top to bottom, and their position in the interface determines priority. By default, entries are ordered by creation time, but this can be adjusted manually by dragging and rearranging them.

Changing the order may directly affect which configuration value is delivered to the user.

Recommendation: Always review the order of entries manually after making bulk changes, as priority is determined by their position in the list.

Additional Feature Evaluation Scenarios

Below are typical scenarios for how feature values are resolved in the client context, based on combinations of default values, segments, and A/B tests:

1. Only Default Value Specified

• If no segmentation or A/B testing is applied, the client will receive only the default value of the feature.

2. Segments Specified (Without A/B Test)

• User matches a segment: → The feature value defined for that segment is delivered to the client.
• User does not match any segment: → The default feature value is delivered.
• Two segment entries with identical segmentation logic: → The client receives the value from the first segment listed in the configuration (order matters).
• Segment includes an Exclude rule (or the exclusion is defined inside an A/B test): → If the user matches the Exclude condition, they will receive either the default or an alternative segment value, depending on the exclusion setup.

3. Both Segment and A/B Test Specified

• Segment and A/B test share the same targeting logic: → The value from the A/B test takes priority and is delivered.
• Segment and A/B test have different targeting logic: → The user receives the value based on which segment or test they match, following the standard priority logic (A/B test > Segments > Default).

These examples illustrate how Magify handles feature resolution in complex targeting environments. Understanding this logic ensures reliable behavior when configuring segmented or experimental feature flags.

Deleting Application Feature Values for Segmentations or A/B Tests

Magify allows the deletion of feature values defined for specific segments or A/B tests:

Backend Behavior: When a segmented or A/B test value is deleted, it is removed from the configuration and will no longer be delivered to users.

Client-Side Behavior:

• If the entire feature is deleted, the app will fall back to its hardcoded default behavior (as defined in the client logic).
• If a segmented or A/B-specific feature value is deleted, the system will evaluate the next applicable configuration block (e.g., another segment, A/B test, or the default value) and deliver that to the user.

Retaining A/B Test Values After Test Completion: If you want to preserve A/B test values for users after the experiment ends, use segmentation based on A/B test assignment. This can be done by creating a new segment and applying the corresponding A/B test criteria to ensure users continue receiving the same values they had during the test: