Protect360 Automatic Fraud Blocking

Introduction

Premium customers using Protect360 are provided with automatic and comprehensive anti-fraud protection both on the single device level and on the general service level.

The Solutions

Set out below are the AppsFlyer’s automatic anti-fraud protection solutions:

Fraud Issue

Issue Description

AppsFlyer’s Solution

Reset ID Fraud

Device ID is constantly reset by the fraudster on the same device(s), to display a large amount of installs.

AppsFlyer creates a blacklist of Site IDs that consistently show irregular behavior of unknown devices.

Install Hijacking 

Fraudsters plant malware on mobile devices that alerts when a download of an app takes place. Instantly a click is sent to AppsFlyer claiming credit for the install.

AppsFlyer blocks attributed clicks with a very quick CTIT* (Click To Install Time).

Click Hijacking 

Malware identifies an install tracking link click and instantly sends another click that credits them if it is attributed.

AppsFlyer blocks attributed clicks occurring very fast* after other clicks for the same app on the same device.

Block Fraudulent Devices Using DeviceRank 

Fraudsters reuse the same mobile devices to commit fraud with different apps.

AppsFlyer’s unparalleled database of mobile devices is the biggest of its kind in the world encompassing over 98% of all smartphones on the planet.
This database allows us to rank all mobile devices globally according to their actions with all client apps. Thus suspicious devices are blocked from being attributed in real time.

IP Blacklists 

Fraudsters usually operate from click farms, which may be identified by their IP addresses for long periods of time.

AppsFlyer blacklists IP addresses suspected of fraud on a daily basis based on up to date data received from 3rd party global provider Digital Element.

SDK Authentication 

Fraudsters send fake SDK messages to simulate valuable user actions.

AppsFlyer uses a proprietary hashing protocol to encrypt internal messages between our SDKs and our web services, preventing fraudsters from mimicking the messages.

Store Validations 

Fraudsters send fake SDK messages to simulate installs or in app purchases so they can claim high CPA fees.  For more information, click here.

AppsFlyer enables install validation on iTunes and in-app purchase validation for both iTunes and Google Play, of any install or in-app purchase that has taken place to prevent attribution of fraudulent activities.

* AppsFlyer withholds the exact time values to protect our clients.

To learn about AppsFlyer's advanced fraud detection techniques please read this.

What Does Fraud Blocking Actually Do?

When AppsFlyer's SDK or servers identify a mobile fraud attempt, they can't stop the physical event from happening. Rather, AppsFlyer blocks the attribution associated with the fraud event, eliminating the fraudsters' gains and motivation. 

Generally, fraud events get the same treatment:

  1. Fraudulent installs are blocked from showing up on the dashboard and raw data report, neither as non-organic nor organic installs. 
  2. Install postbacks are NOT sent to any media sources, but are recorded on the blocked installs raw data report. Supporting networks get postbacks with blocking reasons for internal optimization.
  3. In app events coming from fraudulent installs, or that are considered as fraudulent on their own, are blocked from showing up on the dashboard and raw data report, neither as non-organic nor organic events.
  4. In-app event postbacks are NOT sent to any media sources.
  5. Blocked fraud clicks, installs and in-app events are displayed as part of Protect360's fraud raw data reports.

Saving the Original Attribution

In some cases, however, the fraudsters take advantage of legitimate installs, trying to attribute these installs to themselves, by sending the last clicks before the installs take place.

When it comes to install or click hijacking, AppsFlyer blocks ONLY the fraudulent clicks. Using AppsFlyer's unique multi-touch data, Protect360 reverts to the preceding real clicks data, thus saving the original attribution of the installs, whether organic or otherwise.

In such cases the following occurs:

  1. Original install data (last click before the fraudulent click) is attributed on the dashboard and raw data reports.
  2. Fraudulent click appears on the blocked fraud clicks raw data report
  3. Fraudulent install appears on the blocked fraud installs raw data report
  4. Protect 360's dashboard displays the blocked fraud install
  5. Install postbacks with fraud data are NOT sent to any media sources, but are recorded on the blocked installs raw data report. Supporting networks get postbacks with blocking reasons for internal optimization.
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request
Powered by Zendesk