Implement validation rules to prevent fraud

• For installs: Validation rules, depending on the selected action, either block the attribution and correct to the last valid media source, or block the attribution completely.
• For in-app events: Validation rules block the attribution of the in-app event. 

• See the following table showing the validation rule block type outcomes.
   

  	Block type	Description	Where install data can be viewed	In-app events that follow
  Installs	Block attribution and correct to last valid media source	Selected when you consider the install real, but your conditions determine which sources should or shouldn’t be attributed for it. Attribution is corrected, and the install is attributed to the last valid media source. If no valid media source is identified, the install is marked as organic.	AppsFlyer dashboards and raw data reports as a regular install (attributed to the last valid media source) With Protect360 Premium plan: Protect 360 installs dashboard Protect360 installs raw data report (with the blocked media source) Without Protect360 Premium plan: Protect360 installs raw data report (with the blocked media source)	Has the same corrected attribution as the install Data available with Protect360 Premium plan: With corrected attribution in AppsFlyer dashboards and reports as a regular IAE With blocked media source in the Protect360 IAE dashboard and Protect360 blocked IAE raw data report
  	Mark installs as invalid and don't attribute them	Selected when installs that are invalid based on the rule’s conditions are considered fake. The install is not attributed at all (neither as non-organic nor organic)	With Protect360 Premium plan: Protect 360 installs dashboard Protect360 installs raw data report (with the blocked media source) Without Protect360 Premium plan: Protect360 installs raw data report (with the blocked media source)	Blocked Data available with Protect360 Premium plan in Protect360 IAE dashboard and blocked IAE raw data report
  In-app events	Block attribution	Selected when in-app events that are invalid based on the rule’s conditions are considered fake.	With Protect360 Premium plan: Protect360 IAE dashboard Protect360 in-app events raw data report Without Protect360 Premium plan: N/A	Data available with Protect360 Premium plan in Protect360 IAE dashboard and blocked in-app events raw data report
  	Remove from AppsFlyer entirely	Recommended for use when there are in-app events that you don't need any data for. AppsFlyer does not record these events at all.

• Ad networks and agencies can only view data if the advertiser gives them the required permissions.
• When an install attribution is blocked or attributed to a valid media source in real-time, a rejected postback is instantly sent to the blocked ad network, to streamline your reconciliation flow. When attribution is blocked and corrected to the last valid media source, a postback is also sent to the last valid ad network.
• When an in-app event attribution is blocked, a rejection postback is instantly sent to the blocked ad network.
  Note:
  • A postback is only sent if the ad network set to receive it is integrated with AppsFlyer to receive postbacks.
  • Postbacks and rejected postbacks reports are available on the export page.
  • Learn more about postbacks and rejected postbacks.
• Install and IAE attribution blocking, only affects how and where data is reported in AppsFlyer. They do not prevent app usage by your end-users.
  • If needed, you can use the blocked install and blocked IAE raw data reports (available via export, pull API, and data locker), to get the list of app users to be disabled.
• Blocked installs/IAE reports and rejected postbacks contain the name of the rules that blocked the installs/IAE under the block reason. See the multiple rules section if there is more than one rule.
  • When installs/in-app events are blocked by the Protect360 anti-fraud engine, even if there is also a validation rule, the Protect360 reasons are displayed.
• Rules can result in reporting discrepancies between AppsFlyer and SRNs like Meta ads and Google Adwords as they deploy their own logic to validate installs.

• Multiple validation rules can run on the same install/IAE. This happens when the install meets the conditions of multiple rules.
• The install/IAE is classified as invalid when it does not comply with the conditions of any of the rules separately.
• In raw data reports and rejected postbacks, the block reason value field contains the names of all the rules that classify the install or in-app event as invalid.
• Multiple rules for the same install are sequenced to run in the following order, based on the block types of the rules:

The Sources section is where you define the traffic sources of the installs the rule applies to.

There are three primary options: 

• All traffic: Includes both organic and non-organic installs. Source information is unavailable for organic installs. This option includes all media sources, including those added in the future.
  Example: Apply a rule to all traffic with app version lower than X.

• All traffic of Non-organic: Applies to all agency and non-agency non-organic traffic sources, including new sources added later.
  Example: Block non-organic traffic from a specific geo where you don’t run UA or retargeting campaigns.

• Selected traffic of Non-organic: Applies the rule to specific agencies or media sources only. You must manually select or add media sources when editing the rule.
  Example: Block installs from a specific media source if the CTIT is longer than X days.

Additional source options are available for Protect360 customers for installs and in-app events. 

The Conditions section is where you define the conditions that determine when install attributions are blocked, or attributed to the last valid source. 

You can add multiple conditions, and groups of conditions to every rule.

Conditions are defined as per the conditions, operators, and values outlined in the table that follows.

Bulk upload

When selecting the operators In list or not in list inside of conditions that support it, you have the option to bulk upload a CSV file when adding new items.

To do this:

1. Select a condition with an In list or not in list operator.
2. Select In list or not in list from the operator dropdown list.
3. Select Upload CSV file from the Add new items box. 

Note: The CSV file can contain up to 17K values.

Additional condition options are available for Protect360 customers, for installs and in-app events. 

When In-app events is selected in the Events section, then in addition to the regular source options, customers have another source option to define which in-app events their rule applies to. 

The source is defined as per the field, operators, and values outlined in the table that follows.

Note: All other in-app events sources are based on the source of the install the IAE is associated with (for example, agency, media source, campaign, campaign ID, site ID, etc.).

When In-app events is selected in the Events section, customers have additional condition options to define which in-app events their rule applies to. These conditions can be mixed and matched with any of the non-Protect360 conditions listed previously.

Protect360 conditions are defined as per the conditions, operators, and values outlined in the table that follows.

In addition to the regular source options, Protect360 customers have another source option to define which installs their rule applies to. The source is defined as per the field, operators, and values outlined in the table that follows.

Protect360 customers have an additional set of conditions to validate their installs. These conditions can be mixed and matched with any of the non-Protect360 conditions listed previously.

Protect360 conditions are defined as per the conditions, operators, and values outlined in the table that follows.

When In-app events is selected in the Events section, Protect360 customers have additional condition options to define which in-app events their rule applies to. These conditions can be mixed and matched with any of the non-Protect360 conditions listed previously.

Protect360 conditions are defined as per the conditions, operators, and values outlined in the table that follows.

If you add multiple conditions or condition groups to a rule, select the logical relation between them using either: 

• And: Meaning the install complies with all the defined conditions.
• Or: Meaning the install complies with at least one of the defined conditions.

For example, if you want to validate installs based on both platform and OS, you must select and. That way, the defined platform must always accompany the defined OS. If you want to validate installs based on either platform or OS, you must select or.

To view all the rules created in your account:

1. In AppsFlyer, go to Settings > Validation Rules.
   The Validation Rules window opens, with the list of validation rules.
2. Select your preferred table view using the List view/Details view toggle.
3. Filter the rules in the list using the search and the filter options.
   • You can search by rule name, source, condition name, and value.
   • For example, type 7 to find all rules defined for an OS version that contains 7. (e.g.: “2.7.4”, “7.1”, etc.). Or type Canada to find rules defined with Canada in the Geo condition. 

The Validation Rules table shows 25 rules per page by default. You can change the number of rules shown per page to 10, 25, or 50.

Search and filters apply to the full rule set, regardless of the page you’re viewing.

To set up a new rule:

1. In AppsFlyer, go to Settings > Validation Rules.
   The Validation Rules window opens.
2. Click Add Rule.
   The Add new rule window opens.
3. Insert a rule name. Use a unique name that:
   • accurately describes the rule.
   • is not offensive to ad networks, as it displays in the blocked installs report, as well as in the rejected postbacks to ad networks.
4. Complete the rule builder sections.
5. [Optional] Add conditions and/or condition groups, as required. Make sure to select the relevant logic between conditions/condition groups.
6. [Optional] Click Estimate traffic impact to see how your rule will affect traffic.
7. Click Save.

A regular expression pattern is composed of characters for which you want to find a match. Simple patterns are constructed with characters for which you want to find a direct match. When the search for a match requires something more than a direct match, you can include special characters in the pattern.

Examples:

There are two possible reasons:

• Make sure the relevant app/s are selected. If the app isn't selected, values don't display in search results.
• Results display only if the value you are searching for appeared in your traffic during the past 30 days. Additionally, there is a lag of up to 1 day between when the conversion occurs, and when the source or condition displays as a menu option.

If the value does not appear as a search result, you can type the value as free text and press the Enter key on your keyboard.

The Media Sources field options are affected by your Agency selection.

It depends on your use case. Sometimes either option achieves the same results. Other times, both options are necessary.

For example, if in USA you support installs only on OS V10 or later, but in Brazil, you support from V7 and later, you'll need a rule like:

{[Geo = US] and [OS version = 10]} OR {[Geo = Brazil] and [OS version = 7]}

No. Validation rules can block installs, block attribution to an install’s sources (that prevents the media source of a click/impression from receiving attribution), or block in-app events. However, none of these options blocks the actual click, and click KPIs are not affected by executing validation rules.

This means the block was due to the Protect360 engine and not a validation rule. See also multiple rules.

This depends on your Source settings, as described in the table below.

If the rule is not automatically applied, you must edit the rule:

• Change the Agency field to either Agency and non-agency traffic, or select the specific agency.

Use Not in last to allow installs from your most recent app versions and block installs from older versions.

• Not in last X versions: Allows installs from the last X versions of the selected app, and blocks installs from all earlier versions.
   
• Not in last (major) X versions: Use when your versioning includes multiple major version series (for example, 1.x and 2.x). This condition allows the last X versions within each major series, and blocks earlier versions in each series.

Example: Not in last

You have these existing app versions:

• 1.0.01
• 1.0.02
• 1.0.03
• 2.0.01
• 2.0.02
• 2.0.03

A rule defined with Not in last 2 versions:

• Allows: 
  • 2.0.02
  • 2.0.03
     
• Blocks: 
  • 1.0.01
  • 1.0.02
  • 1.0.03
  • 2.0.01

Example: Not in last (major)

Using the same versions list above, a rule defined with Not in last (major) 2 versions:

• Allows: 
  • 1.0.02
  • 1.0.03
  • 2.0.02
  • 2.0.03
     
• Blocks: 
  • 1.0.01
  • 2.0.01

Understand how the condition works with multiple apps

If you select multiple apps in the rule, AppsFlyer evaluates the Not in last condition separately for each app.

For example, if you set Not in last 3 versions and select App A, App B, and App C:

• App A allows its last 3 versions based on App A’s version history.
• App B allows its last 3 versions based on App B’s version history.

App C allows its last 3 versions based on App C’s version history.

Use a validation rule when you want to prevent attribution from impression-based engagements and keep attribution only for valid clicks. If no valid click-based media source is found, the install is attributed as organic. This setup can help address attribution scenarios related to install hijacking.

To configure the rule:

• Under Traffic sources, select All non-organic traffic.

• Under Conditions, select Attribution touch type.

  • Set the operator to In list.

  • Select Impression.

• Under Action, select Block attribution and correct to last valid media source.

Don’t select Mark installs as invalid and don’t attribute them for this use case. That action is intended for installs you consider invalid or fake. If the install is real, but you don’t want to attribute it to impression-based engagement, use Block attribution and correct to last valid media source instead.

Yes. Tagged mode supports all validation rule operators and fields, including And/Or logic, Geo, OS version, SDK version, and Event value.

No. Tagged data isn’t classified as blocked traffic. Tagged traffic maps as Tagged and is considered a subset of valid traffic. It’s visible in valid reports in Data Locker.

Use Data Locker or raw data export reports to view tagged validation rule data. Tagged installs are available in tagged installs reports, and tagged in-app events are available in tagged in-app events reports.

Tagged data isn’t visible in the Protect360 dashboard or Fraud Protection Suite.

Yes. After you review the export data and confirm that the rule works as expected, edit the rule, set Detection status to Implemented, and save the rule. From that moment, the rule actively blocks matching traffic according to the selected rule outcome.

Tagged mode is available for Premium customers. There is no strict limit to the number of rules that can be set to Tagged. As a best practice, review tagged rules and change them to Implemented when you’re confident in the rule accuracy.