Set up conversion rules

Conversion Rules are an advanced feature under the Protect pillar. They allow you to validate installs and user engagements by applying custom rules that you define.

Growth solution:

To enable Conversion Rules for your account, please contact sales@adjust.com.

Before you begin

Here's what you need to know before getting started.

Requirements

Set up a conversion rule

To set up a conversion rule, follow these steps.

  1. Under Protection, select Conversion rules.
  2. Select New conversion rule.
  3. Enter a name for your rule.
  4. Choose one of the following status:
    • Live - Rule is applied to attributions immediately when conditions are met.
    • Test - Use this to test your conversion rule. For conversion rules in Test status, we don't change the attribution source or send any callbacks.
    • Pause - Your rule is not applied to any attributions.
  5. Select your app.
  6. Select the rule type, and configure your rule accordingly.
  7. Select Create rule.

Once your rule is Live, Adjust checks attribution data against the rule configuration. This might change your attribution results. You will see these changes in your raw data exports and Datascape. For any rules in Test status, we don't change the attribution source or send any callbacks.

Attribution behaviours

For specific rule types, you can define how attribution results should be handled. The following options are available:

Unverified devices

  • Adjust retains postbacks and aggregated data.
  • Unverified devices can be reattributed.

Untrusted devices

  • This represents the highest severity level.
  • Adjust does not retain postbacks or aggregated data.
  • Untrusted devices cannot be reattributed.
Important:

To use this attribution behaviour in either live or test mode, your account must have the Conversion Rules Core feature enabled. Please contact sales@adjust.com for assistance.

Store

The 'Store' type rule allows app installs from Google Play Store or Apple App Store.

If you want to set up the store rule, follow these steps:

  1. Choose the allowed store(s). For single-platform apps, only the corresponding platform stores will be shown.
  2. Choose what the attribution result should be if the store doesn't match the allowed stores:
  3. If you don't want the rule to be executed for specific channels, use the Exclude channels option.
  4. Select Create rule.

With this rule, installs from outside the allowed stores are attributed to Unverified devices or Untrusted devices.

Region

The 'Region' type rule allows devices and installs from specific regions.

If you want to set up the region rule, follow these steps:

  1. Choose what the attribution results need to be changed to, in case the regions don't match your specified region:
  2. Under Rule conditions, choose multiple regions by setting conditions for Country:
    1. Condition type - Set to Is equal to or Exclude.
    2. Value - Choose a value from the list.
  3. If you don't want the rule to be executed for specific channels, use the Exclude channels option.
  4. Select Create rule.

With this rule, installs from outside the specified countries are attributed to Unverified devices or Untrusted devices.

Example: A 'Region' rule with

  • Condition Type: Include
  • Country Value: Japan

Interpretation: As a marketer, I want to attribute only installs coming from the Japan region

Behaviour: This rule attributes any installs outside Japan as either Unverified or Untrusted devices.

Version

The Version rule allows you to define conditions based on version-specific fields such as:

  • App version
  • SDK version
  • Signature version
  • OS version

You can use this rule to restrict attribution to devices running specific versions. If the conditions aren't met, attribution will be assigned to either unverified or untrusted devices, depending on your configuration.

If you want to set up the version rule, follow these steps:

  1. Choose how attribution should behave if version data points don’t match your specified conditions:
  2. Under Rule conditions:
    1. (Optional) Pre conditions act as global filters, limiting the rule's application. They must be satisfied before any group conditions are evaluated.
      For example, to apply this rule only to Android devices in a multi-platform app, use the following pre condition:
      • Condition: OS name
      • Condition type: Equal to
      • Value: Android
    2. (Required) Conditions – Add one or more version-based conditions that must be satisfied for the install to be attributed normally.
      Conditions within a group are combined using AND logic. Use separate groups to apply OR logic.
  3. If you don't want the rule to be executed for specific channels, use the Exclude channels option.
  4. Select Create rule.

Example:
As a marketer, I need to define a rule that follows the security team’s requirements for my multi-platform app.
The requirement is to block installs on Android if:

  • App version is lower than 2.2.1 and device OS version is lower than 6.0.0
  • App version is lower than 2.9.1 and device OS version is lower than 7.1.2

Attribution behaviour if the condition does not match: Untrusted devices

Pre conditions:
[OS name] [Equal to] [Android]

Match conditions:

Group 1
[App version] [Greater than or equal to] [2.2.1]
[OS version] [Greater than or equal to] [6.0.0]

Group 2
[App version] [Greater than or equal to] [2.9.1]
[OS version] [Greater than or equal to] [7.1.2]

  • Case 1: Install OS name is iOS
    • Result: rule is skipped
Note:

If the rule had not included the OS name pre condition, the attribution of the install would have been rejected because no conditions matched.

  • Case 2: Install OS name is Android, App version is 2.3, OS version is 6.1

    • Result: Condition matched. No rejection.

  • Case 3: Install OS name is Android, App version is 2.1, OS version is 6.1

    • Result: Condition didn’t match. Attribution rejected.

Pre conditions & conditions details

NameDetails
App versionString condition types:
- Equal to (string)
- Not equal to (string)
- Contains
- Does not contain
✅ Equal to (string) and Not equal to (string) support multivalue

Semantic versioning condition types¹:
- Equal to (semantic)
- Not equal to (semantic)
- Greater than
- Greater than or equal to
- Less than
- Less than or equal to
- In range
- Not in range
✅ Equal to and Not equal to support multivalue

Comparison logic:
Adjust compares the App Version (from the rule) with:
- app_version_short on iOS
- app_version on all other platforms
OS nameList condition types:
- Equal to
- Not equal to
✅ Supports multivalue
OS versionSemantic versioning condition types¹:
- Equal to (semantic)
- Not equal to (semantic)
- Greater than
- Greater than or equal to
- Less than
- Less than or equal to
- In range
- Not in range
✅ Equal to and Not equal to support multivalue
SDK versionSemantic versioning condition types¹:
- Equal to (semantic)
- Not equal to (semantic)
- Greater than
- Greater than or equal to
- Less than
- Less than or equal to
- In range
- Not in range
✅ Equal to and Not equal to support multivalue

Usage guidance:
For non-native SDKs (e.g., React Native, Unity), target the non-native SDK version.

Examples:
client_sdk = react_native5.0.0@ios5.1.0
Rule: SDK version = 5.0 → ✅ Accepted
Rule: SDK version = 5.0, Native SDK version = 5.0.0 → ❌ Rejected
SDK platformList condition types:
- Equal to
- Not equal to
✅ Supports multivalue

Usage guidance:
Used for non-native SDKs like React Native or Unity.

Examples:
client_sdk = react_native5.0.0@ios5.1.0
Rule: SDK platform = React Native → ✅ Accepted
Rule: SDK platform = React Native, Native SDK platform = Android → ❌ Rejected
Native SDK versionSemantic versioning condition types¹:
- Equal to (semantic)
- Not equal to (semantic)
- Greater than
- Greater than or equal to
- Less than
- Less than or equal to
- In range
- Not in range
✅ Equal to and Not equal to support multivalue

Usage guidance:
Use this field when your app integrates with Adjust’s native SDK, or when a non-native SDK (e.g., React Native, Unity) is layered on top of it.

You can:
- Use only Native SDK version to target all integrations using a specific native SDK version, regardless of wrapper (e.g., Android SDK 5.0.0 across multiple wrappers). 
- Combine Native SDK version with SDK platform and SDK version to precisely match installs using a specific wrapper + native SDK combination (e.g., React Native 5.0 + iOS SDK 5.1.0).
Native SDK platformList condition types:
- Equal to
- Not equal to
✅ Supports multivalue

Usage guidance:
Can be combined with SDK platform to match exact SDK pairs.

Examples:
client_sdk = react_native5.0.0@ios5.1.0
Rule: SDK platform = React Native, Native SDK platform = iOS → ✅ Accepted
Rule: SDK platform = React Native, Native SDK platform = Android → ❌ Rejected
SDK signature versionSemantic versioning condition types¹:
- Equal to (semantic)
- Not equal to (semantic)
- Greater than
- Greater than or equal to
- Less than
- Less than or equal to
- In range
- Not in range
✅ Equal to and Not equal to support multivalue
Note:

¹ Semantic version format The version must follow the standard semantic versioning format:

Format:
MAJOR.MINOR.PATCH[-pre-release]

Components:

  • MAJOR, MINOR, and PATCH are numbers (e.g. 1.2.3)
  • An optional pre-release tag may follow, such as: -alpha, -beta, -rc, or -dev
  • You may also include build metadata like +build, which will be ignored during comparison

Examples of valid versions:

  • 5.3.1
  • 1.0.0-beta
  • 2.2.0-rc
  • 3.4.5-dev+123
  • v2.1.0 (the optional v prefix is supported)
Important:

Be careful when using operators that narrow the condition too strictly, such as:
App version = 1.2.1
If your app releases a new version (e.g., 1.2.2), the rule will no longer match, and new installs may be rejected or unverified.

✅ A safer alternative is to use a range or lower bound, such as:
App version ≥ 1.2.1

Always ensure your conditions are forward-compatible with future app versions, unless you are intentionally targeting a specific build.

If you do want to target a very specific build, consider moving that condition to the Pre conditions section.
This helps improve rule readability and long-term maintainability.

Pin/Unpin functionality

You can pin a condition to convert it into a pre condition.
This is a simple way to apply global filters that must be satisfied before any group conditions in the rule are evaluated.
It’s especially helpful when you realize a condition should determine whether the rule should apply at all.

To pin a condition:
Click the pin icon next to the condition in the group. It will move to the Pre conditions section.

To unpin a pre condition:
Click the unpin icon. The condition will return to the group conditions section.

Region and Campaigns match

The 'Region and campaigns match' type rule allows devices and installs from your chosen region and campaigns.

If you want to set up the region and campaigns match rule, follow these steps:

  1. Under Set the channel filter, select the Channel, Campaign, and Adgroup to choose the campaign.
  2. Under Rule conditions, choose multiple regions by setting conditions for Country:
    1. Condition type - Set to Is equal to or Exclude.
    2. Value - Choose a value from the list.
  3. Select Create rule.
Note:

This rule type skips the source of attribution. If there is no attribution from your chosen campaign traffic from your specified region, we don't attribute. The latest fallback is organic.

Example: For a 'Region & Campaigns Match' rule with

  • Campaign ‘Channel’ value: AppLovin
  • Country Value: Japan

Interpretation: For the AppLovin campaign, I want to attribute installs coming from the Japan region.

Behaviour: If there is an install from outside Japan, it will not be attributed to any AppLovin campaign even if the last click (that won the attribution) came from AppLovin.

Adjust searches for the preceding best click. If an eligible click was found, then it is awarded the attribution for the install. If no click was found, then the install is attributed to Organic.

Manage your conversion rule

On the Conversion rules page, you can:

  • View a list of your conversion rules.
  • View the status of the rule and change its status.
  • Select (edit icon) to edit the rule. You can change the rule name, status, type, and its settings.
    • You cannot change the app for which you created the rule.
  • Select (delete icon) to delete the rule.

Reporting

Here you can find details about how Adjust reports conversion rules data in Datascape. This uses the following structure in reports.

Attribution changed to Unverified devices

Campaign structure levelReporting value
Channel
  • Unverified devices
CampaignRule type
    • Store rule,  Region rule or Version Rule
Adgroup
  • Network name with link token that the engagement was originally attributed to.
Creative
  • Campaign that the engagement was originally attributed to.

Attribution changed to Untrusted devices

Campaign structure levelReporting value
Channel
  • Untrusted devices
CampaignRule type
  • Store rule, Region rule or Version Rule
Adgroup
  • Unknown
Creative
  • Unknown

Dimensions

  • Unverified devices
  • Untrusted devices

Metrics

Unverified, Untrusted devices attribution behaviours

  • Installs
    1. Unverified Installs Store Rule
    2. Unverified Installs Region Rule
    3. Unverified Installs Version Rule
    4. Rejected Installs Store Rule
    5. Rejected Installs Region Rule
    6. Rejected Installs Version Rule
  • Reattributions
    1. Unverified Reattributions Store Rule
    2. Unverified Reattributions Region Rule
    3. Unverified Reattributions Version Rule
    4. Rejected Reattributions Store Rule
    5. Rejected Reattributions Region Rule
    6. Rejected Reattributions Version Rule

"Skip the source" attribution behaviour

  1. Unverified engagements region campaign rule
  2. Unverified clicks region campaign rule
  3. Unverified impressions region campaign rule
See also:

Protection dashboard