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.


What is Protect360?

Protect360 is a fraud protection solution to prevent attribution related fraud. It consists of dynamic tools able to detect fraud and block fraudulent attribution.

By using AppsFlyer scale, machine learning, and behavioral analysis, Protect360 provides coverage against known and new forms of click/install fraud including bots and behavioral anomalies. 

Protect360 guards marketers from fraud attempts at the device, publisher, and media source levels.

The following layers of protection are provided:

  • Real-time fraud blocking
  • Post-attribution

Real-time fraud blocking

The first layer of anti-fraud protection is to block the attribution of fraudulent media sources in real-time.

Note: End-users experience is not affected by Protect360. In case of fraud attempts over real users, the app installs are carried through normally, and only the attribution data is affected. 

About blocked events

Post-attribution fraud

The second layer of anti-fraud protection relates to fraudulent events, which can only be detected after the install and real-time attribution occur. 

After Protect360 identifies installs as fraudulent in retrospect, they can't be erased, but need to be treated as real fraud and not charged for.

Once a source, like an ad network, site ID, or country 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 the data. As of January 2020, advertiser invoices are credited for attribution fees of these installs.
  • Past installs from before the start of the current month, are not changed.
  • In-app events occurring up until the install labeling are not changed.
  • In-app events occurring after the install labeling are labeled as fraud.

Examples for post-attribution fraud:

  • Seemingly regular installs followed by fraudulent signals within in-app events
  • 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

How to use Protect360?

In the remaining tabs of this article we explain how Protect360 works, how to use the Protect360 dashboard, and how to benefit from raw data. Use the following guidelines in implementing Protect360:

  • At the start of each month contact the account manager in each ad network where fraud occurred.
  • Notify them of the number of fraudulent installs: blocked and post-attribution.
  • Share the fraud raw data with the network for reconciliation and optimization of their traffic.

The table below describes where the data for both protection layers is found in AppsFlyer:

  Aggregate Raw Data
Real-time fraud Blocking Protect360 dashboard Export Data page
Post-attribution fraud Protect360 dashboard Protect360 dashboard
  • The Anomalies insight page offers information about media sources that have installs with abnormal CTIT values, when compared with other trusted sources.
    Visit the page to investigate these anomalies. Cross-reference the suspected installs with your raw installs data and look for suspicious signs such as weird 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.


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

Was this article helpful?