Managing Fraud Rules

Overview

Branch recommends creating fraud rules to block erroneous attribution credit in real-time. While Branch still performs last-click attribution, it will not send the ad network a postback when the attribution is flagged as fraudulent.

This has two benefits:

  • You can see how many fraudulent events come from each ad partner and sub-publisher.
  • You do not have to try to recoup losses from the ad network, because the payout never happened in the first place.

Blocked events are also separated from normal traffic in your Branch dashboard, so you can see all events in one place (the fraud dashboard), while healthy analytics are not distorted by bad traffic.

But not to worry, blocked events are still deep linked, so blocking would not affect the user experience of a real user.

Requirements

  • Using the Universal Ads product
  • Tracking events with the Branch SDK
  • To create new rules and/or enable/disable rules, you must have EDIT access to the Fraud Settings & Data permission.
  • To view rules, you must have VIEW access to the Fraud Settings & Data permission.

Universal Rules

Universal rules block events that violate Branch's universal fraud criteria and are already enabled for your account.

Universal Rules Permanently Enabled

As Branch's Universal Rules cover the most basic and necessary protection against fraud, you cannot disable these rules.

Suspicious IP

Branch automatically blocks events coming from TOR networks.

Fraud Name - IP

Suspicious Persona

This is based on Branch’s cross-platform persona graph. We use proprietary algorithms to dynamically block attributions on browsers and devices showing suspicious behavior.

Fraud Name - PERSONA_FRAUD

Standard Rules

Standard rules block events based on the most common fraud patterns.

Standard rules can be used to block the following events:

  • All Events
  • Clicks
  • Installs
  • Opens
  • Web Session Starts
  • Reinstalls
  • Commerce Event
  • Custom Event

Click Injection

When a malicious app or SDK on a user's Android device tries to insert a fake ad click between when a legitimate app is downloaded and when it is first opened (thus taking unearned credit for that install).

Fraud Name: CLICK_INJECTION

The following filters are available:

  • Ad Name
  • Ad Partner
  • Ad Partner (3p)
  • Ad ID
  • Ad Set ID
  • Ad Set Name
  • Agency ID
  • Agency Name
  • Brand
  • Campaign
  • Campaign ID
  • Channel
  • Creative Name
  • Country
  • Customer Ad Name
  • Customer Ad Set Name
  • Customer Campaign
  • Customer Event Alias
  • Customer Keyword
  • Customer Placement
  • Customer Secondary Publisher
  • Customer Sub Site Name
  • Device Type
  • Environment
  • Feature
  • First Event For User
  • Geo Country Name
  • Geo DMA Code
  • Keyword
  • Last Attributed Touch ID
  • Last Attributed Touch Type
  • Model
  • Name
  • Operating System
  • Placement
  • Platform
  • Reengagement Activity Attributed
  • Region
  • Secondary Publisher
  • Stage
  • Sub Site Name
  • Tags
  • Custom

Country Conflict

The click and the install occur in different countries. Theoretically this could happen for a real user, but it is extremely unlikely. It’s much more likely that the click or install was simulated.

Fraud Name: GEO_CONFLICT

The following filters are available:

  • Country
  • Geo Country Code

Conversion Conflict

Very short click-to-install times are suspicious - this is typically caused by faked clicks taking attribution credit for real installs. We recommend blocking CTI times below 30 seconds, but you can configure it to be up to 60 seconds. On the Branch Fraud Dashboard, you can see CTI time distribution by ad partner to determine if this threshold seems to be working.

Fraud Name: CONVERSION_TIME

The following filters are available:

  • Ad Name
  • Ad Partner
  • Ad Partner (3p)
  • Ad ID
  • Ad Set ID
  • Ad Set Name
  • Agency ID
  • Agency Name
  • Brand
  • Campaign
  • Campaign ID
  • Channel
  • Creative Name
  • Country
  • Customer Ad Name
  • Customer Ad Set Name
  • Customer Campaign
  • Customer Event Alias
  • Customer Keyword
  • Customer Placement
  • Customer Secondary Publisher
  • Customer Sub Site Name
  • Device Type
  • Environment
  • Feature
  • First Event For User
  • Geo Country Name
  • Geo DMA Code
  • Keyword
  • Last Attributed Touch ID
  • Last Attributed Touch Type
  • Model
  • Name
  • Operating System
  • Placement
  • Platform
  • Reengagement Activity Attributed
  • Region
  • Secondary Publisher
  • Stage
  • Sub Site Name
  • Tags
  • Custom

Device Conflict

The device information on the click and the install are different. A real user clicks and installs on the same device, so this is highly suspicious.

Fraud Name: DEVICE_CONFLICT

The following filters are available:

  • Brand
  • Model
  • OS Version
  • OS

Custom Rules

Custom rules block events based on any attribute(s) stored at the event level.

Custom rules can be used to block the following events:

  • All Events
  • Clicks
  • Installs
  • Opens
  • Web Session Starts
  • Reinstalls
  • Commerce Event
  • Custom Event

Event-level Characteristics

We can block on any attribute stored at the event level.

Fraud Name - CUSTOM

Examples:
Device Pattern: For example, “OS version + Country + Model”. It’s common for device farms to use the same devices over and over, making it easy to pick out specific device characteristics to block.

Fraud Rules Consisting only of NOT clauses

If your fraud rule consists only of NOT clauses (like NOT userData.geoCountryCode:"US" AND NOT userData.os:"ANDROID") please add at least one positive constraint, such as "AND Name Exists" as well.

The following filters are available:

  • Ad Name
  • Ad Partner
  • Ad Partner (3p)
  • Ad ID
  • Ad Set ID
  • Ad Set Name
  • Agency ID
  • Agency Name
  • Brand
  • Campaign
  • Campaign ID
  • Channel
  • Creative Name
  • Country
  • Customer Ad Name
  • Customer Ad Set Name
  • Customer Campaign
  • Customer Event Alias
  • Customer Keyword
  • Customer Placement
  • Customer Secondary Publisher
  • Customer Sub Site Name
  • Device Type
  • Environment
  • Feature
  • First Event For User
  • Geo Country Name
  • Geo DMA Code
  • Keyword
  • Last Attributed Touch ID
  • Last Attributed Touch Type
  • Model
  • Name
  • Operating System
  • Placement
  • Platform
  • Reengagement Activity Attributed
  • Region
  • Secondary Publisher
  • Stage
  • Sub Site Name
  • Tags
  • Custom

Once Ever Rules

Once Ever Rules cap events that should only occur once per user.

Once Ever rules can be used to block the following events:

  • Installs
  • Opens
  • Purchases
  • Complete Registrations

Once Ever Capped

To be used only for those events that should only ever occur once per user.

*Fraud Name - ONCE_EVER_CAPPED*

Threshold Rules

Threshold Rules block events for a group when it violates a threshold.

Threshold rules can be used to block the following events:

  • All Events
  • Clicks
  • Installs
  • Opens
  • Web Session Starts
  • Reinstalls
  • Commerce Event
  • Custom Event

Threshold Logic

  • Requires the following inputs:
    • Minimum number of events you want to allow before rule is applied.
    • Ratio of fraudulent indications to overall number of events before the rule is applied.
  • The threshold must be met within a 24hr period for it to be applied.
  • Once the threshold has been met, the rule will be applied to all subsequent events for the following 14 days.

Low Conversion Rate (CTI) Android

The ratio of clicks to installs by sub publisher is low for Android.

Young Persona Rate High

The ratio of installs coming from young personas to the total installs by sub publisher is high.

Adding New Threshold Rules

New types of threshold rules will be added over time. If you need a specific threshold rule for your business, please contact Support to request a new type of threshold rule to be built.

Updated about a month ago

Managing Fraud Rules


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.