Mobile fraud is considered by many to be the most alarming problem within the industry. Fraud drains marketing budgets, pollutes marketing performance data and turns successful campaigns into losing ones.
To combat mobile fraud, AppsFlyer has developed the industry’s most comprehensive, real-time fraud protection and detection solution - the Protect360 platform.
Protect360 is an AppsFlyer premium feature which is an add-on to existing packages. For specific pricing please contact your AppsFlyer CSM or write to firstname.lastname@example.org.
What is Protect360?
Protect360 is AppsFlyer's Enterprise-Grade fraud protection solution. It's a dynamically changing set of tools, which detect and block fraudulent mobile install and post-install events for today’s leading marketers. Using AppsFlyer's unique scale, machine learning and behavioral analysis, Protect360 provides unparalleled coverage against known and new forms of click/install fraud, bots and behavioral anomalies.
Protect360 guards marketers from fraud attempts on the device level, publisher level and on to the media source level.
There are 2 layers of protection serving Protect360's clients: Real-time blocking and Post-attribution.
Real-time fraud blocking
The first layer of anti-fraud protection is a set of tools which automatically blocks sources and devices suspected of fraudulent activities in real-time
For details on what happens with blocked events, go here.
The second layer of anti-fraud protection relates to fraudulent events, which can only be detected after the install and real-time attribution occur.
Although the initial installs pass through as regular installs, by the time AppsFlyer identifies them as fraudulent, they should be treated as real fraud and not charged for.
Once a source (e.g. ad network, site ID, country) is identified as fraudulent:
- All source's future clicks are blocked.
- All its past installs, from the start of the current month until the present, are labeled as post-attribution fraud, but not erased from the raw data.
- All its past installs, before the start of the current month, are not changed.
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 next tabs of this article we describe how to understand and use Protect360's dashboard and raw data. We propose the following guidelines for advertisers using Protect360:
- At the start of each month contact your account manager in each ad network that suffered from fraud. Notify them of the total number of fraudulent installs, blocked and post-attribution.
- Share the frauds raw data with the network for reconciliation and optimization of its traffic. The table below describes where the data for both protection layers is found in AppsFlyer:
|Real-Time Fraud Blocking||Protect360's dashboard||Export Data page|
|Post-Attribution Fraud||Protect360's dashboard||Protect360's dashboard|
Protect360's dashboard presents aggregate fraud data for your entire account. It shows the total fraud inflicted upon your account, split into the 2 categories - blocked in real-time and post attribution.
Protect360's dashboard lets you reach deep insights about fraud traffic in your account with filtering and grouping options. Additionally, it allows you to detect anomalies, which may indicate more fraud in some cases.
The following page describes how to use the Protect360 dashboard.
To enter Protect360's dashboard from anywhere in AppsFlyer's dashboard, click on the Protect360 link in the left menu.
Who can access?
- Advertisers - all team members defined in AppsFlyer can access.
- Ad Networks - the Protect360's dashboard is accessible to ad networks, if the advertiser permits the network to access it. The blocked fraud raw data reports with the media sources data are available to them regardless of permissions.
- Agencies - currently the Protect360's dashboard is not directly available for agencies.
Data in the Protect360 dashboard can be filtered by App Name, Media Source, Geo and date range.
Press the blue arrow to the right of the date filter to open the expanded filtering view.
The expanded view allows you to filter results related to agencies and channels, and also to set the minimum allowed cohort size to show up in the dashboard.
You can choose different dimensions to group the fraud data by and get the specific insights you need:
- Application - compare the total amount of fraud per each of your apps.
- Media Source (default) - compare the handled fraud from each of the media sources used by your apps.
- Media Source + Campaign - compare the handled fraud from all your campaigns across all media sources used by your apps.
- Media Source + Site ID - compare the handled fraud from all publishers (site IDs) across all media sources used by your apps.
- Media Source + Site ID + Campaign - compare the handled fraud from all publishers (site IDs) across all media sources used by your apps, associated with the relevant campaign names.
- Geo - compare the handled fraud from all countries.
Data in the Protect360 Dashboard is calculated daily. The dashboard shows the last data update time below the date range filter. For example:
Identified fraud widgets
The Identified Fraud widgets enable you to see how much money, fraudulent installs and events Protect360 saves for your apps in a glance.
For each displayed KPI you can see a percentage value. This value shows how the presented KPI is in relation to the parallel date range before it. For example, the last 7 days show 19% increase in estimated savings, meaning the previous week before the last 7 days had 19% less fraudulent installs.
Estimated savings widget
The widget breaks down the monetary amounts of identified fraud in your account. It shows you the value of blocked fraud and also the value of post-attribution fraud, to be settled by you with the ad networks. The post-attribution amount for any select filtering may update over the course of a month, so make sure to use it at the beginning of each month, for the previous month.
The Estimated Savings widget shows you an approximation of this amount based on the following formula: Estimated Savings = number of blocked installs X app's average eCPI
For more details on how this amount is calculated read this FAQ.
Total identified fraud widget
This widget breaks down the amount of blocked fraud installs from all various fraud blocking reasons. It also displays the amount of installs identified as fraudulent at post-attribution phase.
Blocked in-app events widget
This widget shows the amount of in-app events, which were blocked by AppsFlyer. The events may have been blocked due to belonging to blocked installs, or due to being marked as suspicious post-attribution events.
Anomaly insights widget
Click the Explore anomalies button to open the anomalies chart page (described below).
Identified fraud breakdown table
The Identified Fraud Breakdown table displays an abundance of information about fraud blocks, post-attribution marking of installs and more indications of fraud per media source.
Table's left half
The table below explains about the columns in the left half of the Identified fraud breakdown table:
|Groupings||By default the table and dashboard are grouped by Media Source. More supported groupings include Campaign, Site ID, GEO, Channel, agency and their combinations.|
|Installs||High level breakdown of blocked and post-attribution fraudulent installs.|
|Total||Total number of installs of the source|
|Blocked||Total number of blocked installs of the source.
By default the table is sorted in descending order by this KPI.
|Blocked %||Blocked installs / total number of installs|
|Post-attribution||Total number of installs of the source marked as fraud post-attribution|
|Post-attribution %||Post-attribution installs / total number of installs|
|Hijacked installs block breakdown||Breakdown of blocked and post-attribution fraudulent last clicks aimed to steal attribution of real app installs|
|Blocked install hijacking||Total number of blocked install hijacking of the source|
|Post-attribution install hijacking||Total number of install hijacking marked as fraud in post-attribution|
|Blocked CTIT anomalies||Total number of installs blocked due to Click Time to Install anomalies|
|Post-attribution CTIT anomalies||Total number of CTIT anomalies marked as fraud in post-attribution|
|Blocked click flood||Total number of installs blocked due to click flooding (fraud attempts to send large numbers of clicks hoping to deliver the last clicks prior to random installs)|
|Post-attribution click flood||Total number of click flooding installs marked as fraud in post-attribution|
|Blocked faked installs breakdown||Breakdown of blocked and post-attribution fraudulent fake installs, usually performed programmatically|
|Blocked site ID blacklist||Total number of installs blocked due to the SiteID appearing on Protect360 blacklist|
|Post-attribution site ID blacklist||Total number of installs marked as fraud due to the SiteID appearing on Protect360 blacklist post-attribution|
|Blocked bots||Number of blocked installation attempts made by automatic bots|
|Post-attribution bots||Number of installs marked as fraud due to identified automatic bots activities post-attribution|
|Blocked behavioral anomalies||Total number of installs blocked due to behavioral anomalies, i.e. abnormal session and in app event performance of users|
|Post-attribution behavioral anomalies||Total number of installs marked as fraud due to behavioral anomalies post-attribution|
|Blocked install validation||Total number of installs blocked due to negative store validation|
Table's right half
|Clicks||Legit and blocked clicks from the source|
|Total||Total number of clicks from the source|
|Blocked||Total number of blocked clicks from the source|
|%||Blocked clicks / total number of clicks|
|In-App Events||Legit and blocked in-app events from the source|
|Total||Total number of in-app events from the source|
|Blocked||Total number of blocked in-app events from the source|
|Percentage||Blocked in-app events / total number of events|
|Blocked Installs Breakdown - Install Hijacking||Total number of installs blocked due to install hijacking based on the Google Play Server-Side API discrepancies|
|Device farm indicators - new devices||Indicators of fraudulent device farm activity, using Device ID Reset fraud|
|Installs||Number of installs from the source, which have a new device ID unrecognized by AppsFlyer|
|Installs %||New devices installs / total number of installs|
|Loyal user %||General KPI indicating whether the users from the source are real or fake|
|Device farm indicators - LAT devices||Indicators of fraudulent device farm activity, using Limited Ad Tracking fraud|
|Installs||Number of installs from the source, which are set for Limited Ad Tracking|
|Installs %||LAT devices installs / total number of installs|
|Loyal user %||General KPI indicating whether the users from the source are real or fake|
|Click flood indicators||User quality KPIs|
|Conversion rate||Low percentage compared with the general app's conversion rate indicates click flooding fraud|
|Assists %||High percentage compared with other media sources (in the Assists widget in the overview page) indicates click flooding fraud|
|Click flood indicators - CTIT||Indications of click flood fraud, based on abnormally high Click to Install Time|
|Over 60 minutes||Normally ~30% of first app launches occur more than 60 minutes after download|
|Over 5 hours||Normally ~20% of first app launches occur more than 5 hours after download|
More table options
- Click Export CSV button to download the table to your desktop in CSV format
- Click the wheel cog icon to:
- Change the order of table columns
- Add or remove the columns described above
- Add or remove any of your app's recently blocked in-app events to the table. For each added in-app event the relevant following columns are displayed:
|Events Counter (Total)||Number of the specific event's blocked occurrences|
|Unique Users||Number of unique users getting the specific event blocked|
Note that uncommon rates of either of these KPIs does not necessarily indicate fraud, as many events get blocked due to fraudulent post-attribution installs.
The amount of events shown is activity and not LTV based, i.e. it's the exact number of event blocks during the specified date range.
The Anomaly insights page lets you detect media sources, which have suspicious Click to Install Time (CTIT) values, when compared with other media sources. This powerful KPI is on the media source level, which enables you to get compensated by the source and consider whether to continue working with it or not.
The following actions are enabled in the page (numbering refers to the screenshot above):
- Select which of your apps to watch in the page.
- Select which countries contribute to the data in the page.
- Select the date range of the data in the page.
- Turn Exclude post-attribution fraud on to see only blocked fraud, or turn it off to see the full fraud insights.
- Select the media source baseline to compare with. The default App Baseline takes into consideration various sources trusted by AppsFlyer, which contribute to your traffic.
- Select the time resolution shown in the graph: seconds, minutes, hours or days.
- Customize the validation rules to exclude installs with illogical CTIT.
Note: the validation rules feature must be enabled for your account to perform this.
- To see more details, hover over the distinctly colored parts in the graph, which indicate detected CTIT anomalies.
- Click to see a visual comparison of CTIT throughout different media sources.
- Click the Protect 360 link to go back to the Identified Fraud page.
The CTIT anomalies breakdown table, at the page bottom, displays all the media sources which have CTIT anomalies. Use it to see data about the number and percentage of installs with abnormal CTIT values. With this table you can also export to CSV, add or remove columns or set their order.
The described tables are limited to maximum 1000 entries. If you query for a larger data set, some media sources might be excluded from it.
To overcome this limitation, we recommend the following:
Fraud issues & solutions
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 table below describes some of the common fraud issues and how Protect360 handles them.
|Fraud Issue||Issue Description||AppsFlyer's Solution|
DeviceID Reset Fraud
Device ID is constantly reset by the fraudster on the same device(s), to display a large amount of installs.
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.
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) and based on Google Play Server-Side API.
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.
Mobile fraud where large numbers of fraudulent clicks are sent, with the purpose of delivering the last-click prior to installs.
AppsFlyer blocks attributed clicks from site IDs with a low conversion rate and long CTIT.
Mobile fraud where the fraudster generates an inconsistent and abnormal post-install activity.
AppsFlyer’s 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.
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.
Note - IP Blacklists protection is automatically enabled for ALL AppsFlyer clients.
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.
Note - SDK authentication protection is automatically enabled for ALL AppsFlyer clients.
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.
Note that AppsFlyer withholds the exact time values cited above to protect our clients.
More blocking reasons are explained in the raw data tab.
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:
- Fraudulent installs are blocked from showing up on the dashboard and raw data report, neither as non-organic nor organic installs. The installs get attributed to the last engagement (or organic) of the user prior to the fraudulent click.
- Install postbacks are recorded in the Blocked installs raw data report. They are ONLY sent to media sources, which support getting postbacks with blocking reasons for internal optimization.
- 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.
- In-app event postbacks are NOT sent to any media sources.
- Blocked fraud clicks, installs and in-app events are displayed as part of Protect360's fraud raw data reports.
Protect360 raw data reports
Clients of AppsFlyer's Protect360 feature can see user-level details of all events that were blocked by AppsFlyer's Protect360. The raw data reports include details of clicks, installs and post-install events.
These reports are a major tool for mobile advertisers for reconciliation with the ad networks and for further optimization. They also enable in-depth analysis of the fraud issues mobile advertisers are facing.
Protect360 offers raw data reports for blocked fraud, and for post-attribution fraud.
Blocked fraud reports
- In Protect360 dashboard, click the Raw data reports button >> select Blocked to see blocked fraud reports.
- You can also reach the blocked fraud reports from the Export Data page.
The following Protect360 reports are available in the Blocked Fraud Reports section in the Export Data page:
- Blocked installs (organic and non-organic) based on all of Protect360's capabilities.
- In-App Events
- Blocked in-app events (organic and non-organic) based on all of our Protect360's capabilities.
- Blocked clicks based on all of Protect360’s capabilities.
- Installation Postbacks
- Provides raw data of blocked installation postbacks sent to the attributed media source.
Post-attribution fraud reports
The post-attribution raw data fraud reports have the same structure (see below) as the blocked fraud reports, so you can safely merge the two kinds of reports.
Each post-attribution raw data fraud report is dedicated to a single media source in a single calendar month. These reports are generated by requests of you or your other team members.
To add or download a post-attribution report:
- In Protect360 dashboard, click the Raw data reports button >> select Post-attribution.
- Select the media source and the calendar month of the report.
- Click Generate report.
- Report generation may take several minutes, depending on the volume of traffic from the media source. You can click Done and return later on to download the ready report.
Note that current month post-attribution reports may update over the course of the current month, up until one week into the beginning of the next month, but then are finalized.
Protect360 reports structure
The Protect360 reports have the same general structure as their parallel user acquisition reports. You can read about the various columns data available in the reports here.
However, the Protect360 reports have unique additional columns, detailing the blocking reasons (Blocked Reason) and sub-reasons (Blocked Sub Reason). The following tables describe these reasons per blocking level.
Click level blocking reasons
On the click level only clicks are blocked, and the attribution process simply ignores them.
|ip_blacklist||Based on a dynamically created list (details)|
|install_store_validation||Discrepancy between Google Referrer values of the install|
|invalid_fingerprint||S2S clicks only - invalid parameters sent by the source (for Fingerprinting matching)|
Install level blocking reasons
On the install level only clicks are blocked, and last valid contributor is attributed. Bots traffic, however, is completely blocked.
Install hijacking happens only on Android.
|ctit_anomalies||---||Click Time to Install too short|
|install_hijacking||referrer_hijack||Fraudsters pushing additional non-legitimate referrers|
|install_hijacking||CTCT_anomalies||Multiple clicks too close to each other|
|install_hijacking||click_after_install_begins||Click injected after "install begins" by new google API|
|Bots||---||Fake traffic by bots|
Site ID level blocking reasons
On the site ID level, fraudulent site IDs traffic is completely blocked.
|behavioral_anomalies||---||Very low post-install in-app event activity ratio, in comparison with the app's benchmarks|
|site_blacklist||high_fraud_rate||Sites with high rate of fraud traffic, with installs fraud characteristics only (but not hijacking)|
|site_blacklist||high_emulator_rate||Sites with high rate of installs originated in emulators|
|site_blacklist||multiple_fraud_signals||Sites with high rate of installs with various suspicious KPIs|
You can pull aggregate Protect360 data from AppsFlyer's servers directly into your back office. To learn about it go here.
How is the Estimated savings widget calculated?
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.
What's new in Protect360 V2 compared with V1?
- 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.
- Anomaly Insights - A new section called “Anomaly Insights” was added, in which advertisers can analyze anomalies via visualization tools. It’s replacing the 2 charts on the old “Advanced Detection” tab.
- 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?
No, the install data on the overview page and all other reports outside Protect360 dashboard, do not update retroactively. Currently, also in-app events related to Post-attribution fraud continue to be attributed to the original fraudulent install.
Selecting specific networks in Anomaly insights
Question: 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). How come?
Answer: 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.