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 post-attribution detection.

p360_intro_2.jpg

Related reading: Dashboards | Raw data | Validation rules | Introductory guide for marketers to mobile ad fraud

Protect360 overview

Protect360:

  • 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.

The table below outlines the various types of fraudulent installs and in-app events, and what happens when the Protect360 engine blocks them in real-time, or detects them post-attribution.

Protect360 fraud detection and outcomes
Fraud type Detection time What happens to install What happens to in-app event
Fake install Real-time Blocked in real-time Blocked in real-time
Post-attribution Marked in the post-attribution report
  • Before detection: marked in the post-in-app report
  • After detection: blocked in real-time
Install attribution hijacking Real-time
  • Blocked in real-time
  • Attribution is corrected to the last valid source
  • Appear in the blocked events report
  • Attributed to the same valid source as the install
Post-attribution Marked in the post-attribution report
  • Before detection: marked in the post-in-app report
  • After detection: marked in the post-in-app report (until 30 days after fraud detection)
Fraudulent in-app event Real-time - Blocked in real-time
Post-attribution - Marked in the post-in-app report

Using Protect360

Dashboard

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. 
Limitations
  • 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

FAQ and tips

FAQ

FAQ

How is the Estimated savings widget calculated?

For networks that support sharing cost data you get an accurate estimation of the savings.

For networks that don't support that AppsFlyer uses the average eCPI coming from the entire group of verified installs from all sources that have cost data. In case your app still has no source with cost data you are prompted to enter an estimated eCPI manually when you enter the dashboard.

Media sources granted access to the Protect360 from the advertiser are unable to see any estimated savings data.

Does Protect360 work against fraud coming from custom attribution links?

Definitely! Protect360 detects and blocks fraud coming from custom attribution links, in addition to ad networks. That means you are also protected if you have campaigns of owned media, such as with influencers, email and SMS campaigns, web site banners and landing pages, viral posts on social media, Push notifications or even QR codes.

What's new in Protect360 V2 compared with V1?

  1. There are 3 main changes in the P360 V2.0:
    Post-Attribution fraud - wherever we present blocked installs, we also show Post-Attribution fraud installs. Post-Attribution is also available as a raw data report.
  2. Anomaly Insights - A new section called “Anomaly Insights” was added, in which advertisers can analyze anomalies via visualization tools. Its replacing the 2 charts on the old “Advanced Detection” tab.
  3. Centralization of all the fraud data - the “advanced detection” tab was removed and instead we present all the information in 1 tab.

Why isn't the post-attribution raw data available in the Export Data page?

Post-attribution reports are on the account level per media source, In order to make the reconciliation process easier. The Export Data page is on the single app level, and still contains the Blocked fraud data on the app level, for backwards compatibility.

Does post-attribution data update retroactively?

  • Installs - install data on the overview page and all other reports outside Protect360 dashboard, does not update retroactively.
  • In-app events - once the post-attribution protection layer identifies an install as fake, following in-app events coming from this install are being blocked. Previous in-app events do not update retroactively.

When selecting specific networks in Anomaly insights, the data looks different?

I looked at the CTIT anomalies and selected AF_Baseline as benchmark. It showed me one network's anomalies (first screenshot below). Then I selected the same network as benchmark, expecting to see no anomalies, but now there are other ones (second screenshot). Why?

This outcome is actually what you should expect. When the trusted baseline is used, the network shows abnormal rate of CTIT in the 24-39 seconds range. These installs are "subtracted" from the normal distribution, which means that regular traffic should have some "abnormal" spikes compared with the problematic traffic of the specific network.

Is abnormal organic traffic actually fraudulent?

It's possible that abnormal spikes in organic traffic are actually fraudulent. In general, if you see organic traffic in AppsFlyer, which you have reasons to believe is actually fraudulent, it could be one of the 3 following cases:

  • Failed attribution fraud: fraudster's clicks failed to receive attribution, e.g., click flooding with the last click taking place beyond the click lookback window.
  • Non-attribution fraud: user performs fraud, that is not related to attribution, e.g. using fraud to collect items in strategy games.
  • SDK integration issues: check that your in-app events are sent correctly, i.e. at the right time in the flow and with correct event parameter values.

Benchmarks and tips

Benchmarks and tips

Detecting new devices fraud

Fraudsters may mask their devices by frequently resetting the main IDs of their devices, i.e. IDFA for iOS and GAID for Android.

Fortunately, AppsFlyer identifies over 98% of mobile devices globally.

Therefore, a high percentage of unknown new devices is a strong indication of fraud by click farms, unless intentionally targeting new devices.

Detecting new devices:

  1. In Protect360 go to the Identified fraud breakdown table.
  2. Scroll right to the Device farm indicators - new devices columns.
  3. Click on the Installs % column name to sort the table in descending order of new device ratio.
  4. New device fraud benchmarks:
    • Suspect sources with 100+ installs, which have over 60% new devices ratio.
    • Sources with relatively more installs, are also suspicious with lower new device ratio, e.g. source with 1000 installs is suspicious as fraud with 40% ratio.
    • For borderline sources, compare the loyal users ratio with the general loyal users ratio, found in the Aggregated performance report table in the dashboard overview page. A relative low percentage is a strong indication of fraud.
Note: Campaigns of pre-installed apps usually have extremely high rates of new devices, as these may be among the very first apps that users launch when activating their new devices. Therefore, for pre-installed apps, new device fraud is unlikely, even with high new devices rates.

Detecting LAT fraud

LAT (Limited Ad Tracking) users select to opt out of exposing their device ID, IDFA or GAID, to advertisers. Approximately 15% of iOS users and 10% of Android users take this choice.

Similarly to the new device ranking, LAT users may be legitimate users. However, a high percentage of them could indicate fraudulent activity.

Detecting LAT:

  1. In Protect360 go to the Identified fraud breakdown table.
  2. Scroll right to the Device farm indicators - LAT devices columns.
  3. Click on the Installs % column name to sort the table in descending order of LAT device ratio.
  4. LAT devices fraud benchmarks:
  • Suspect sources with 100+ installs, which have over 60% new devices ratio.
  • Sources with relatively more installs, are also suspicious with lower new device ratio, e.g. source with 1000 installs is suspicious as fraud with 40% ratio.
  • For borderline sources, compare the loyal users ratio with the general loyal users ratio, found in the Aggregated performance report table in the dashboard overview page. A relative low percentage is a strong indication of fraud.

Detecting click flooding fraud

  1. Using click flooding, fraudsters send millions of clicks with real device IDs, hoping to register as the last click for real users. Sources with this type of fraud have very low conversion rates, but high-quality users, since these are real users.

    Detecting click flooding:

    1. In Protect360 go to the Identified fraud breakdown table.
    2. Scroll right to the Click flooding indicators columns.
    3. Click on the Conversion rate column name to sort the table in ascending order of conversion rate.
    4. Click flooding fraud benchmarks:
    • Normal Conversion Rates are between 0.5% to 35%.
      Suspect sources whose conversion rate are abnormally low, or that have 25% or less of the average conversion rate of the app. You can find this KPI in the Aggregated performance report table in the dashboard overview page. 
    • For borderline sources, compare the Assists % with the average assists ratio. You can see the normal assists ratio in the assists widget, in the dashboard overview page.
      Sources whose assists ratio is 50% higher than the average assists ratio of the app are considered suspicious.
      Note that the more sources are used by an app, the higher are its Contribution rates.

Detecting click flooding with CTIT indicators

Another indication of click flooding, is even distribution of CTIT.
Usually, around 70% of normal installs take place within 1 hour from the ad engagement.
With click flooding, there's no connection between the fake engagement and the actual install. This leads to much more than 30% of fraud installs, which have longer than 1 hour CTIT. 

Detecting click flooding CTIT indications:

  1. In Protect360 go to the Identified fraud breakdown table.
  2. Scroll right to the Click flooding indicators - CTIT columns.
  3. Click flooding CTIT benchmarks:
  • Normally, Over 60 minutes values should be around 30%. Suspect sources who have more than 50% with this metric.
  • Normally, Over 5 hours values should be around 20%. Suspect sources who have more than 40% with this metric.

Use the Anomaly insights page to investigate sources with suspicious CTIT.

Advanced anti-fraud tips

Advanced anti-fraud tips

Number of installs

Filtering by the number of installs per checked source is important for detecting the biggest fraud sources. Additionally, lower number of installs may not be mathematically significant. Note:

Note: Sources with less than 30 installs, or even 50, are not significant enough to draw conclusions from. Expand the date range or other search criteria to get more significant results.

Change loyal user definition

The default definition for Loyal users is 3 or more launches of the app. It is an important KPI for user engagement, but unfortunately many fraudsters know it and use it to fake high rates of loyal users, thus avoiding suspicion. Avoid being conned by creating and selecting a better, more elaborate loyal user definition.

Analyze your app user quality KPIs such as register, tutorial completion, purchase, multiple sessions. Within the app code send a new loyal user in-app event if a user performs ALL the list of KPIs.

After the first non-organic loyal user event is sent, go to App Settings and select it to indicate loyal users for your app. Expect general loyal user rates to slightly drop and then drastically drop for fraudulent sources.

 Tip

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

Was this article helpful?