Validation Rules for app owners

• 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 two primary options: 

• All traffic: The rule applies to any install, no matter what its source (agency, media source, campaign, organic, etc.). 
  Note: Since this option includes organic installs, no further source info can be selected, and only the block install option is available. This is because it is not possible to block/correct attribution for organic installs.
• Non-organic only: The rule applies to the sources you select, with the fields, operators, and values as described in the table that follows.

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. 

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.

See the estimated impact your validation rules have on traffic, meaning how many blocked installs and blocked attributions are likely to result. 

To see the estimated impact of your validation rule:

1. In AppsFlyer, go to Validation Rules. 
2. Either select an existing rule or click + Add rule and create a new rule with rule sources and conditions.
3. Scroll to the bottom of the rule and click Estimate traffic impact.
   The Rule’s estimated impact window opens. 
4.  Select whether to base the estimated impact on data from the last day or last 7 days.
   • The estimated new blocks, as well as the newly blocked percentage of traffic due to the validation rule, displays.
   • When the rule is defined on only non-organic sources, the estimate displays the impact of the rule versus all your traffic. To see the impact versus only the sources (for example a specific media source or campaign), in the chart legend, deselect Other sources.
     

     

To edit, delete, enable, or disable a rule:

• In the rule list, select the action you want to perform for a specific rule.
  • Under Active: enable or disable the rule.
  • Under Action: edit or delete the rule.

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. If "non-transparent agency" is selected as one of the traffic sources, no media sources display except for Meta ads and X Ads, which even non-transparent agencies need to be transparent about. 

Note: If your rule applies to multiple apps, any agency that is transparent in some of the selected apps, but non-transparent in others -is considered as non-transparent. This means you can't select specific media sources other than Meta ads or X Ads.

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.

Not in last is a condition used when you have one series of app versions that you want to include in the validation rule. Not in last (major) is a condition used when you have more than one series of app versions that you want to include in the validation rule.

Example: 

• You have a series of app versions 1.0 and 2.0
• All your 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" blocks:
  • 2.0.02
  • 2.0.03
• A rule defined with "Not in last (major) 2 versions" blocks:
  • 1.0.02
  • 1.0.03
  • 2.0.02
  • 2.0.03