Protect360 anti-fraud guide

At a glance: Attribution related fraud is a significant challenge in the app industry. Fraud drains marketing budgets, pollutes marketing performance data, and can turn successful campaigns into losing ones. Protect360 provides app owners with real-time fraud protection and detection.


Related reading:  Introductory guide for marketers to mobile ad fraud.

Protect360 overview


  • Protects against attribution fraud. It consists of dynamic tools that detect fraud and block fraudulent attribution.
  • Uses AppsFlyer scale, machine learning, and behavioral analysis to provide cover against known and new forms of click/install fraud including bots and behavioral anomalies.
  • Guards marketers from fraud at the device, publisher, and media source levels.
  • Uses a layered approach of real-time fraud blocking and post-attribution fraud identification
  • Does not impact the app user experience. In case of fraud attempts involving real users, app installs complete normally, and only attribution recording is affected.


Real-time blocking

  • In real-time, before attribution, the install is identified as coming from a fraudulent media source and is blocked from attribution.
  • Subsequent in-app events, from the same user, are blocked. 
  • Blocked installs and in-app events both organic and non-organic are:
    • Reported in the Protect360 dashboard and blocked fraud reports.
    • These events aren't included in AppsFlyer attribution and dashboards because they were never attributed. 
  • Blocked install postbacks are sent to media sources, with the blocking reason, enabling them to optimize. 

About blocked events

Post-attribution detection

  • Fraud detected after attribution is referred to as post-attribution fraud. 
  • Once attributed, an install can't be erased. For this reason, post-attribution fraud is handled differently to that of real-time fraud.
  • Fraudulent installs and in-app events identified in retrospect, must be treated as real fraud and not charged for.

Once a source, like an ad network or site ID, is identified as fraudulent:

  • Future clicks from the source are blocked.
  • Past installs:
    • From the start of the current calendar month until the present, are labeled as post-attribution fraud, but not erased from data. As of January 2020, advertiser invoices are credited for the attribution fees of these installs.
    • From before the start of the current month, are not changed.
  • In-app events occurring:
    • Up until the install labeling: labeled as fraud.
    • After the install labeling: labeled as fraud.

Examples of post-attribution fraud:

  • Seemingly regular installs followed by fraudulent signals within in-app events
  • A new form of fraud found
  • Installs which turn out to be fraudulent only after anomaly detection algorithms collect enough statistical data about the installs of any publisher

Common fraud issues and solutions

When AppsFlyer identifies fraud, the attribution event associated with the fraud is blocked. This eliminates fraudster gains and motivation. Note: The app install itself takes place and is not blocked. This means the app user can use the app and generate revenue for the advertiser. 

Blocked fraud clicks, installs, and in-app events are found in Protect360 fraud raw data reports.

The following table describes some fraud types and how Protect360 handles them.

Fraud type  Description AppsFlyer solution

Device ID reset fraud

Device ID is constantly reset by the fraudster on the same physical device, so as to generate  a large number of installs.

The AppsFlyer database of mobile devices is the biggest of its kind in the world encompassing over 98% of all smartphones known. Using this database AppsFlyer can identify abnormal rates of new devices and consequently denylist sources delivering them.

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.

Blocks attributed clicks with a very quick CTIT (Click To Install Time) and based on Google Play Server-Side API.

Click hijacking

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

Blocks attributed clicks occurring very fast after other clicks for the same app on the same device.

Click flooding

Mobile fraud where large numbers of fraudulent clicks are sent, with the purpose of delivering the last-click prior to installs.

Blocks attributed clicks from site IDs with a low conversion rate and long CTIT.

Behavioral anomalies

Mobile fraud where the fraudster generates an inconsistent and abnormal post-install activity.

Our unique scale allows us to track and understand behavioral engagement patterns on multiple levels - such as by app, region, media source and publisher. Non-human behavioral patterns are identified in near real-time, and blocked at the source.

IP denylists

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

  • IP addresses suspected of fraud are denylisted on a daily basis based on up to date data received from third party global provider Digital Element.
  • IP denylist protection is enabled for all apps.

SDK authentication

Fraudsters send fake SDK messages to simulate valuable user actions.

  • A proprietary hashing protocol is used to encrypt messages between SDKs and web services, preventing fraudsters from mimicking the messages.
  • SDK authentication protection is enabled for all apps.

Store validations

Fraudsters send fake SDK messages to simulate installs or in-app purchases so they can claim high CPA fees. Apple store validations.

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.

Note: The exact time values, cited above, are withheld to protect our clients.

Additional blocking reasons are explained in the raw data tab.

Using Protect360


The Protect360 dashboard displays aggregate fraud data and providing insights relating to fraudulent traffic.

Dashboard views: 

Installs: Insights about fraudulent installs, blocked in real-time, and identified post-attribution. You can drill down to further examine the fraud events by using the filtering and grouping options.

Anomalies: Information about media sources that have installs with abnormal click-through-to-install time (CTIT) values, when compared with other trusted sources. 

  • Cross-reference the suspicious installs with your raw installs data and look for suspicious signs such as strange app version numbers, old OS versions, distinctive locations, etc. 
  • Use Validation rules to block installs with short CTIT values. Protect360 automatically blocks installs with very low CTIT values.

Raw data

Raw data about fraud is available via Pull API, Data Locker, and Export Data.

Raw data reports are divided as follows:

  • Blocked reports: Installs, clicks, and in-app events of users whose attribution was blocked and not attributed to any media source at all. 
  • Post-attribution reports:
    • Installs attributed to a media source, but later found to be fraudulent. 
    • In-app events:
      • of installs identified as fraud after being attributed to a media source.
      • judged to be fraudulent without regard to the install itself.
  • Advertisers use these reports to reconcile ad network accounts, for optimization, and to adjust attribution dashboards for post-attribution fraud.  

Validation rules

Rules for target-validation and custom fraud detection (Protect360) enable app owners to ensure that installs are attributed to the most recent valid media source.  If there is no valid media source, the install is attributed to organic. 

Campaign target-validation rules control campaign results. Installs that don't meet campaign targets—are invalid—and attributed as organic installs. 

Protect360 custom fraud rules improve the ability to detect fraud. Protect360 is used to block fraudulent install attributions and correct the attribution of hijacked installs. 

Fraud reconciliation with ad networks

With Protect360, advertisers gain the raw data needed to reconcile fraudulent installs and in-app events with ad networks that may not have recorded fraud.

To reconcile CPI-based campaigns using Protect360:

  • At the start of each month contact the account manager in each ad network where fraud occurred.
  • Collect the relevant fraudulent installs raw data from the Blocked installs and post-attribution installs reports.
  • Share the fraud raw data with the network for reconciliation and optimization of their traffic.
  • Its possible to create a raw data report which includes just the valid installs, but excludes post-attribution fraudulent installs. To do this, you need to download the monthly Attributed UA installs report and exclude all entries from the Post-attribution installs report.

To reconcile CPA/CPE-based campaigns using Protect360:

  • At the start of each month contact the account manager in each ad network where fraud occurred.
  • Collect the relevant fraudulent in-app events raw data from the Blocked in-app events and Post-attribution In-app events reports.
  • Share the fraud raw-data with the network for reconciliation and optimization of their traffic.
  • Its possible to create a raw data report which includes just the valid IAEs, but excludes post-attribution fraudulent events. To do this, you need to download the monthly Attributed UA in-app events report and exclude all entries from the Post-attribution in-app events report. 

Traits and limitations

Traits and limitations

Traits and limitations
Trait Remarks 
Advertiser access All team members.
Ad network access
Agency access
  • Require advertiser permission. Once granted agencies can view the Protect360 dashboard and download post attribution raw data.
Agency transparency  
App-specific time zone
  • App-specific time zone is used in the dashboard provided all apps are set to the same time zone.
  • If apps are not set to the same time zone, then the dashboard defaults to UTC.
Data freshness
  • Protect360 dashboard: Updated Daily.
    The most recent update time, displays below the date range filter in the Dashboard.
  • Reports:
    • Blocked installs and in-app events: Update continuously in near real-time.
    • Post-attribution: Daily using UTC. 
  • Tables limited to maximum 20,000 rows.
  • If you query for a larger data set, some media sources might be excluded. To overcome this limitation, we recommend the following:
    • Query for a smaller dataset - smaller date range, specific apps, and specific media sources
    • Export Protect360 raw data reports
    • Export Protect360 Aggregated Advanced Detection Reports through Pull API


How affected by fraud is your vertical?
Explore our App install fraud benchmarks guide covering a wide range of parameters.

Was this article helpful?