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.

Conversion Rules tiers

Conversion Rules are available across different tiers, each offering a different level of validation and reporting depth to suit your needs.

Before you begin

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

Requirements

• Users with Admin, Editor, or Custom Editor permissions in Adjust.
• A single or multi-platform app in Adjust.

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.
   • Pause - Your rule is not applied to any attributions.
5. Select the rule type. This determines which conditions and settings are available:
   • Store
   • Region
   • Version
   • Parameter
   • Region and campaigns match
   • Version and campaigns match
6. For Store, Region, Version, and Parameter rules, choose the attribution fallback behaviour — Unverified devices or Untrusted devices — and, if available for your rule type, whether to extend rule validation to post-install activities. Region and campaigns match / Version and campaigns match rules use Skip attribution instead, so this step doesn't apply to them.
7. Under Apply rule to, select your app and, depending on the rule type, the channels, target filters, or campaign segment (channel/campaign/adgroup) the rule is scoped to.
8. Under Rule definition, set up your conditions (If this happens) and choose Accept or Decline (Then do this) to determine which side of the condition gets the fallback treatment.
9. 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. Rejected and unverified results are flagged and visible in Datascape reports and raw data (callbacks and CSV exports). Unlike in live mode, rejected results are not shared with partners, even if partner sharing is configured for rejections. To distinguish test vs. live results, add the {conversion_rule_status} placeholder (test / live) to your setup.

Attribution behaviours

Accept and Decline

Each rule's conditions are evaluated as If this happens (the condition) → Then do this (the action). The action determines which side of the condition is subject to the rule's attribution behaviour:

• Accept — Whatever meets these conditions continues in the normal attribution flow. Whatever does not is subject to the selected attribution behaviour.
• Decline — Whatever meets these conditions is subject to the selected attribution behaviour. Whatever does not continues in the normal attribution flow.

What "subject to the attribution behaviour" means depends on the rule type:

• For Store, Region, Version, and Parameter rules, it means the install is attributed to Unverified devices or Untrusted devices — you choose which.
• For Region and campaigns match and Version and campaigns match rules, it means the source is skipped for that install. This isn't a separate choice — it's simply what these rule types do.

Unverified devices

• Installs from unverified devices are unverified.
• Adjust retains postbacks and aggregated data.
  • Raw data is shared as unverified_install activity for unverified devices.
  • Sources receive standard install callbacks without any change to the install attribution.
  • Cohort reporting is available up to campaign level.
• Unverified devices can be reattributed.

Untrusted devices

• This represents the highest severity level.
• Installs from untrusted devices are rejected.
  • Install postbacks are sent, but the install is marked as not attributed.
  • Sources may receive rejected_install callbacks, which can include fields such as click_id and the rejection reason. This data is provided for diagnostic and fraud-analysis purposes.
  • Cohort reporting is limited to high-level totals only. There is no breakdown by channel, campaign, or other granular dimensions.
• Untrusted devices cannot be reattributed.

Skip attribution

The attribution behaviour for Region and campaigns match and Version and campaigns match rules. Unlike Unverified devices and Untrusted devices, this isn't a choice you make — it's the behaviour these rule types always use.

• The source tied to the skipped side of the condition (see Accept and Decline) is removed from consideration for that install.
• Adjust then searches for the preceding best eligible engagement. If one is found, attribution is awarded to that source instead.
• If no eligible engagement is found, the install is attributed to Organic.

Extend rule validation to post-install activities

Available for Region, Version, and Parameter rules.

Post-install activities are not reattributed. They are bucketed as rejected for the same source the install is attributed to.

Enables rule enforcement on all post-install activities (sessions, events, and ad revenue) across the app. This includes activity from existing users and previously attributed installs.

When this toggle is on, the Accept/Decline description extends to cover post-install activities too:

• Accept + toggle on: Installs that meet these conditions will continue in the attribution flow. Those that do not will be attributed to the selected attribution behaviour. Post-install activities that do not meet these conditions are bucketed as rejected.
• Decline + toggle on: Installs that meet these conditions will be attributed to the selected attribution behaviour. Those that do not will continue in the attribution flow. Post-install activities that meet these conditions are bucketed as rejected.

• If the install was attributed to a valid source (that is, not classified as an Untrusted device):
  • Raw data is shared as rejected_session, rejected_event, or rejected_ad_revenue activity.
  • Rejected activities are exposed in reporting under the Rejected sessions, Rejected events, or Rejected ad revenue buckets.

Apply rule to

Every rule type includes an Apply rule to section where you scope which traffic the rule affects:

• App — the app the rule applies to. This can't be changed after the rule is created.
• Channels — limit the rule to specific channels, or leave as All to apply the rule across every channel.
• Target filters (Version rule type only, optional) — one or more conditions, combined with AND, that scope which traffic the rule's conditions apply to.

For Region and campaigns match and Version and campaigns match rules, Apply rule to shows App, Channel, Campaign, and Adgroup instead, since these rule types scope to a specific campaign segment rather than channels alone.

Rule types

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 your attribution fallback behaviour — Unverified devices or Untrusted devices.
2. Under Apply rule to, select your app and, optionally, limit the rule to specific channels.
3. Under Rule definition, choose the allowed store(s) under If this happens. For single-platform apps, only the corresponding platform stores will be shown.
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 your attribution fallback behaviour — Unverified devices or Untrusted devices. This rule also supports Extend rule validation to post-install activities.

2. Under Apply rule to, select your app and, optionally, limit the rule to specific channels.

3. Under Rule definition, choose multiple regions by setting conditions for Country:

   1. Condition type - Set to Equal to or Not equal to.
   2. Value - Choose a value from the list.

4. Choose Accept or Decline under Then do this.

5. Select Create rule.

Example: A 'Region' rule with

• Condition Type: Equal to
• Country Value: Japan
• Then do this: Accept
• Extend rule validation to post-install activities: Enabled

Interpretation: As a marketer, I want to accept only activities originating from the Japan region.

Behaviour:
Installs originating outside Japan are treated as Unverified, and any post-install activities that do not meet the rule conditions are rejected.

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. Depending on whether the rule is set to Accept or Decline, installs that don't meet the conditions (or that do, for Decline) are attributed to your selected Unverified or Untrusted fallback.

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

1. Choose your attribution fallback behaviour — Unverified devices or Untrusted devices. This rule also supports Extend rule validation to post-install activities.

2. Under Apply rule to, select your app, optionally limit the rule to specific channels, and optionally add one or more Target filters to scope which traffic the rule's conditions apply to.

   For example, to apply this rule only to Android devices in a multi-platform app, add the following target filter:

   • Condition: OS name
   • Condition type: Equal to
   • Value: Android

3. Under Rule definition, add one or more version-based conditions under If this happens. Conditions within a group are combined using AND logic. Use separate groups to apply OR logic.

4. Choose Accept or Decline under Then do this.

5. 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 only allow installs (the rule should not apply to post-install activities) on Android if:

• App version is 2.2.1 or higher and device OS version is 6.0.0 or higher, or
• App version is 2.9.1 or higher and device OS version is 7.1.2 or higher

Attribution fallback behaviour: Untrusted devices
Then do this: Accept
Extend rule validation to post-install activities: Disabled

Target filters: [OS name] [Equal to] [Android]

Rule definition:

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 — the target filter doesn't match, so the rule doesn't apply at all.

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

  • Result: Condition matched (Group 1). Accepted — no rejection.

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

  • Result: Condition didn't match either group. Attribution rejected per the fallback behaviour.

Parameter

The 'Parameter' type rule checks whether specific SDK parameters (for example, product_id) are included in the payload and applies the selected action if they are missing.

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

1. Choose your attribution fallback behaviour — Unverified devices or Untrusted devices. This rule also supports Extend rule validation to post-install activities.
2. Under Apply rule to, select your app and, optionally, limit the rule to specific channels.
3. Under Rule definition, provide the SDK parameter names to check for under If this happens. You can provide multiple parameters — when multiple parameters are defined, all must exist for the activity to pass the check.
4. Choose Accept or Decline under Then do this.
5. Select Create rule.

Example: A 'Parameter' rule with

• Parameter name: product_id
• Then do this: Accept

Interpretation: As a marketer, I want to accept only activities that include the product_id parameter in the payload.

Behaviour:
Installs that do not include the required product_id parameter are treated as Untrusted, and any post-install activities (sessions, events, and ad revenue) that do not include the required product_id parameter are rejected.

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 Apply rule to, select the App, Channel, Campaign, and Adgroup to choose the campaign segment.
2. Under Rule definition, choose multiple regions by setting conditions for Country:
   1. Condition type - Set to Equal to or Not equal to.
   2. Value - Choose a value from the list.
3. Choose Accept or Decline under Then do this.
4. Select Create rule.

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

• Campaign 'Channel' value: Moloco
• Country Value: USA
• Then do this: Accept

Interpretation: For the Moloco campaign, I want to attribute installs coming from the USA.

Behaviour: If there is an install from outside the USA, it will not be attributed to any Moloco campaign even if the last engagement (that won the attribution) came from Moloco. See Skip attribution for how Adjust handles the fallback search.

Version and Campaigns match

The Version and campaigns match rule allows attribution only for installs that match both a specific app version and campaign.

You can use this rule to ensure that only installs from specific app versions are attributed to designated networks. For example:

• Network A should only receive attribution if the app version is 3.0.5.
• Network B should only receive attribution if the app version is 3.0.6 or 3.0.7.
• Network WW should only receive attribution if the app version contains the "_ww" suffix (e.g., 3.0.8_ww).

To set up a Version and Campaigns match rule:

1. Under Apply rule to, select the App, Channel, Campaign, and Adgroup for the campaign you want to match. If using a multi-platform app, also select the platforms the rule should apply to.
2. Under Rule definition, choose a Condition type and a Value:
   • Condition type must be one of the string or semantic versioning condition types.
   • For the value, enter one or more values depending on the selected type.
   • Adjust compares the value with:
     • app_version_short on iOS
     • app_version on all other platforms
3. Choose Accept or Decline under Then do this.
4. Select Create rule.

Example

For a Version & Campaigns Match rule:

• Campaign Channel value: WW
• App Version condition: [Contains] _ww

Interpretation: For the WW channel, I want to attribute only installs that have app versions ending with _ww.

Behaviour: If an install has an app version that does not contain _ww, it will not be attributed to any WW campaign — even if the last engagement came from WW. See Skip attribution for how Adjust handles the fallback search.

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

Attribution changed to Untrusted devices

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. Unverified Installs Parameter Rule
  5. Rejected Installs Store Rule
  6. Rejected Installs Region Rule
  7. Rejected Installs Version Rule
  8. Rejected Installs Parameter Rule
• Reattributions
  1. Unverified Reattributions Store Rule
  2. Unverified Reattributions Region Rule
  3. Unverified Reattributions Version Rule
  4. Unverified Reattributions Parameter Rule
  5. Rejected Reattributions Store Rule
  6. Rejected Reattributions Region Rule
  7. Rejected Reattributions Version Rule
  8. Rejected Reattributions Parameter Rule

Rejected post install activities

1. Rejected sessions region rule
2. Rejected events region rule
3. Rejected ad revenue region rule
4. Rejected sessions version rule
5. Rejected events version rule
6. Rejected ad revenue version rule
7. Rejected sessions parameter rule
8. Rejected events parameter rule
9. Rejected ad revenue parameter rule

Skip attribution — metrics

1. Unverified engagements region campaign rule
2. Unverified clicks region campaign rule
3. Unverified impressions region campaign rule
4. Unverified engagements version campaign rule
5. Unverified clicks version campaign rule
6. Unverified impressions version campaign rule