Validation Rules for app owners

At a glance: Validation rules are an ZendeskConnect premium feature that add a custom layer of protection against wrongly-targeted campaigns and fraud. The rules enable app owners to control which installs and in-app events are blocked, or which installs are attributed to the most recent valid source.

Overview

• Validation rules are defined in the rule builder using customized conditions and logic that filter and select which app installs or in-app events to keep or block. 
• Rules are based on a variety of parameters for multiple use cases, including:
  • Untargeted installs for your campaign (wrong geo, OS version, etc.)
  • Installs that do not meet the insertion order signed with the ad network
  • Hijacked installs by fraudulent networks
  • Fake installs or in-app events sent from bots, emulators, or device farms
• Rules defined for in-app events only take effect on IAEs associated with installs that were not previously blocked.
• Rules that include an ad network are visible to that ad network's personnel (but they cannot see other ad networks included in the rule). This is in the interest of transparency, and to help ad networks better understand the performance of the traffic they provide.
• The rules run in realtime and take immediate action. Learn more in the outcome section.
• Additional validation rule options are available to Protect360 customers, on top of the automatic Protect360 fraud blocking and detection. These conditions are known to help in the detection of various install-hijacking, fake install, and fake in-app event fraud types.
  Note: Validation Rules only validate installs/in-app events that were not identified as fraud by Protect360.

Outcomes

• For installs: Validation rules, depending on the selected action, either block the attribution to invalid sources, or block the install.
• For in-app events: Validation rules block the in-app event. 
• See the following table for details.
  

  Validation rule block type outcomes

  	Block type	Description	Where install data can be viewed	In-app events that follow
  Installs	Block attribution	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.	ZendeskConnect 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 ZendeskConnect dashboards and reports as a regular IAE With blocked media source in the Protect360 IAE dashboard and Protect360 blocked IAE raw data report
  	Blocked install	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 in-app event	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 ZendeskConnect entirely	Recommended for use when there are in-app events that you don't need any data for. ZendeskConnect 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 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 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 ZendeskConnect to receive postbacks.
  • Postbacks and rejected postbacks reports are available on the export page.
  • Learn more about postbacks and rejected postbacks.
• Install and attribution blocking, as well as IAE blocking, only affect how and where data is reported in ZendeskConnect. 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/IAEs 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 ZendeskConnect and SRNs like Facebook Ads and Google Adwords as they deploy their own logic to validate installs.

Multiple rules

• 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 as invalid. The block sub reason contains the name of the first rule to run.
• Multiple rules for the same install are sequenced to run in the following order, based on the block types of the rules:

Rule/block types	Order
Block installs	Random
Block attribution	Random
Block in-app event	Random
Remove from ZendeskConnect entirely and anything else	Removed from ZendeskConnect. Other rules are ignored.
Block installs and block attribution	Block install rules (in random order) Block attribution rules (in random order)
Block installs and block attribution with Protect360 engine and validation rules	Block installs from Protect360 engine Block install from validation rules Block attribution from Protect360 engine Block attribution from validation rules
Block in-app events with Protect360 engine and validation rules	Block IAE from Protect360 engine Block IAE from validation rules

Rule builder

The rule builder user interface is designed for interactive rule building. Tip! Familiarize and experiment with the rule builder before reviewing this article in detail.

The rule builder contains the following sections: 

Rule builder sections

Section	Remarks
Events	Event type for which the rule is applied: Installs or in-app events. Apps for which the rule is applied: A single app, multiple apps, or all apps in the account. Selection affects the options available in the following sections (agency, media source, campaign, etc.)
Sources	Traffic source for which the rule is applied. See also Protect360 sources
Considered	Decide if the defined conditions determine installs are invalid or valid. Invalid: Installs/sources meeting the defined conditions are considered invalid. The selected action is taken on all of them. Valid: Installs are considered valid, but all installs that DO NOT meet the specified conditions are considered invalid.
Conditions	Conditions that determine install validity based on various parameters, as well as your selection in the "considered as" section. See also Protect360 conditions
Action	For installs: Select what to do with the installs meeting the specified conditions.  Block attribution and correct it to last valid media source. Block installs and don’t attribute any source. For in-app events: Select what to do with the installs meeting the specified conditions.  Block in-app events. This option is only available for Protect360 subscribers. Remove from ZendeskConnect entirely. See Outcomes for more information.

Install sources

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. 

Field	Operator	Value	Remarks
Agency	In	Agency and non-agency traffic Non-agency traffic Transparent agencies (menu) Non-transparent agencies (menu)	If your apps are integrated with agencies, this field is mandatory since it affects the media source field options. If none of your apps is integrated with agencies, the field does not display. Non-transparent agencies: These are agencies that do not share their traffic sources. When "non-transparent agencies" or "agency and non-agency traffic" is selected, specific media sources cannot be selected. Facebook Ads and Twitter are still available for selection when non-transparent agencies are selected, since they always require agencies to share them as sources. Transparent agencies: These are agencies that specify their media sources. Agencies that are transparent for only some of your selected apps, display in the non-transparent agencies menu.
Media source	In list Not in list Equals Doesn't equal Contains Doesn't contain Starts with Ends with Matches regular expression	Search for desired value. Select from menu.  Free text (for values that don’t exist in your search results).	Menu is based on: Selected apps and agencies. Traffic of the past 30 days, ordered by traffic volume. Free text must be typed exactly as it appears in raw data.
Campaign	In list Not in list Equals Doesn't equal Contains Doesn't contain Starts with Ends with Is empty Isn't empty Matches regular expression	Search for desired value. Select value from menu. Free text (for values that don’t exist in your search results).
Ad ID		Free text only. Possible to add multiple values separated by spaces.
Ad set ID
Ad set name

Install conditions

The Conditions section is where you define the conditions that determine when installs 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.

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

Condition	Operator	Value	Remarks
Campaign	Equals Doesn't equal Doesn't contain Contains Starts with Ends with In list Not in list Matches regular expression Is empty Isn't empty	Search for desired value. Select value from menu. Free text (for values that don’t exist in your search results).	Menu is based on: Selected apps and agencies. Traffic of the past 30 days, ordered by traffic frequency. Free text must be typed exactly as it appears in raw data.
Ad ID		Free text only. Possible to add multiple values separated by spaces.
Ad set ID
Ad set name
Device type
Geo	In list Not in list Equals Doesn't equal	Search required value (based on country name, country code, state, or city). Select value from menu.
Platform		Select value from menu.
OS version	Lower than Lower than or equals Greater than Greater than or equals Equals Doesn't equal Is between In list Not in list	Search for desired value. Select from menu.  Free text (for values that don’t exist in your search results).
Lookback days	Lower than Lower than or equals Greater than Greater than or equals Is between	Free text: A single numeric value.	Refers to the impression/click lookback window in days. Ensures you don’t pay for installs with an attribution link that was modified to allow a longer attribution period. Does not replace the configuration of the lookback window in your attribution link. [Recommended] Use in combination with the attribution touch type condition (available with Protect360)
Is preinstalled	Yes No	No value (operator is the value)	Validates all types of preinstalls: Factory preinstalls, meaning an app that comes on the device as part of the OS. Offered preinstalls, meaning an app promoted and offered to users as soon as the device is initialized. This is done by media sources designated for preinstalls. For installs with multiple clicks/ sources, this condition validates whether one of the sources is a preinstall.
Is deeplink			An empty deep link field in raw data is considered to be Is deeplink = No

In-app event sources

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, site ID, etc.).

Field	Operator	Value	Remarks
Event name	In list Not in list Equals Doesn’t equal Contains Doesn’t contain Starts with Ends with Is empty Isn’t empty Matches regular expression	Search for desired value. Select value from menu.  Free text (for values that don’t exist in your search results).	Free text must be typed exactly as it appears in raw data.

In-app event conditions

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.

Condition	Operator	Value	Remarks
Event name	In list Not in list Equals Doesn’t equal Contains Doesn’t contain Starts with Ends with Is empty Isn’t empty Matches regular expression	Search for desired value. Select value from menu.  Free text (for values that don’t exist in your search results).	Free text must be typed exactly as it appears in raw data.

Protect360 install and in-app event sources

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.

Field	Operator	Value	Remarks
Site ID	In list Not in list Equals Doesn’t equal Contains Doesn’t contain Starts with Ends with Is empty Isn’t empty Matches regular expression	Free text only. Possible to add multiple values separated by spaces.	Free text must be typed exactly as it appears in raw data.

Protect360 install conditions

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.

Condition	Operator	Value	Remarks
CTIT (Click Time to Install Time)	Lower than Lower than or equals Greater than Greater than or equals Is between	Free text: A single numeric value.	Only use this field if you are certain of a specific CTIT (usually in a specific geo). Otherwise, you may cause false-positive blocked installs. Note: The Protect360 anti-fraud engine has built-in sophisticated ways to identify complex CTIT anomalies due to attribution hijacking, click flooding, fake installs by bots, and more. Consider using this field together with the following fields: Is pre-installed Is deeplink Geo
Customer user ID (CUID)	Equals Doesn't equal Doesn't contain Contains Starts with Doesn’t start with Ends with Doesn’t end with In list Not in list Matches regular expression Is empty Isn't empty	Free text only. Possible to add multiple values separated by spaces.	Menu is based on traffic of the past 30 days, ordered by traffic frequency. Free text must be typed exactly as it appears in raw data.
App version	Lower than Lower than or equals Greater than Greater than or equals Equals Doesn't equal Is Between In list Not in list	Search for desired value. Select value from menu.  Free text (for values that don’t exist in your search results).
SDK version
Installer/Store	In list Not in list Equals Doesn’t equal	Select value from menu: Google Play Other stores Out of store	In the event that a user's device does not provide the installer/store parameter to ZendeskConnect, the rule does not take effect.
Attribution touch type		Click Impression	[Recommended] Use in combination with the lookback days condition. To simply not attribute for impressions, you can turn off view-through attribution.

Protect360 in-app event conditions

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.

Condition	Operator	Value	Remarks
Event source	In list Not in list Equals Doesn’t equal Contains Doesn’t contain Starts with Ends with Is empty Isn’t empty Matches regular expression	Search for desired value. Select value from menu.  Free text (for values that don’t exist in your search results).	Free text must be typed exactly as it appears in raw data.
Event value		Free text only. Possible to add multiple values separated by spaces.
Install to event time (in seconds)	Lower than Greater than or equals Is between	Free text. A single numeric value.	Based on your app’s flow, you decide the valid time to pass between the app install and an IAE. Example: Time to reach level 5, time to first-time-deposit (FTD), time to checkout, etc. Time is in seconds, but you can validate minutes, hours, or days using the seconds equivalent.

Logic between conditions and condition groups

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.

Procedures

View rule list

To view all the rules created in your account:

1. In ZendeskConnect, go to Configuration > 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. 

Add rule

To set up a new rule:

1. In ZendeskConnect, go to Configuration > 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.

View validation rule impact

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

 Note

• The validation rule estimator is accessible to advertisers only. Partners do not have access.
• Estimates are available for rules related to installs, not rules related to in-app events.
• The estimate also displays what applies to the rule, but is already blocked by Protect360 fraud protection, another validation rule, or, if the estimated rule is not new, then traffic blocked by its previous setting.

To see the estimated impact of your validation rule:

1. In ZendeskConnect, 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.
     

     

Edit or delete a rule

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.

Validation rules API

Developers can use the Validation rules API to programmatically get rules, create rules, update rules, and update rule status.

• Get rules: Provides a list of all your validation rules with details regarding all the rule conditions.
• Create rule: Create a new rule with specific conditions.
• Update rule: Change/edit the conditions of an existing rule. 
• Update rule status: Enable, disable, or delete an existing rule.

FAQ

What is a "regular expression"?

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:

Regular expression	Description
^abc	Starts with abc
xyz$	Ends with xyz
^abc.*xyz$	Starts with abc and ends with xyz
^abc.*(?<!xyz)$	Starts with abc and doesn’t end with xyz
^([0-9]{2})	Starts with 2 digits
\"example_param\":\"[5|6]	Specified parameter's value begins with 5 or 6.
^.{0}$|^\{\}$	Is empty, or is only {}

Why doesn't the source or condition display as a suggested value when I search for it?

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.

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.

Why do my media source options only include Facebook Ads and Twitter?

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 Facebook Ads and Twitter, 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 Facebook Ads or Twitter.

Is it necessary to have "and/or" both within specific conditions and between condition groups?

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]}

Do validation rules block clicks?

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.

Looking at the raw data, I see that installs I expected to be blocked by validation rules have a different block reason than my rule name. Why is that?

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

Do existing rules automatically apply for newly-integrated agency traffic?

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.

Source setting	Agency field selection	Is rule applied if rule was created before any agency integration with one of your apps?	Is rule applied if rule was created after at least one agency integration with one of your apps?
All traffic	N/R	Yes	Yes
Non-organic only	N/R	No	N/R
	Agency and non-agency traffic	N/R	Yes
	Non-agency traffic and/or specific agencies	N/R	No

Traits

Trait	Description
Team access	Account admin must give team members permission to view, add, and edit Validation Rules.
User acquisition	Validation rules apply to installs, re-installs, and re-attributions (when the app was removed from the device). They do not apply in cases of re-engagement, meaning when the app is still on the device.
Automatic rule deactivation	If you create rules: using Protect360 sources or conditions, and then your Protect360 license or trial expires, the rules are automatically deactivated. for transparent agencies traffic, and one or more of the agencies becomes non-transparent, the rule is automatically deactivated.