At a glance: Attribution 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.
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 are reported in the Protect360 dashboard and blocked fraud reports.
- Blocked installs and in-app events: Are not 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.
Post-attribution detection
- Fraud identified after attribution is referred to as post-attribution fraud. Post-attribution fraud can be identified on the day of the install, and up to 7 days after (8 days total).
- 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. |
AppsFlyer identifies abnormal rates of new devices and consequently denylists 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. |
|
Malware identifies an install attribution 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. |
|
|
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. |
|
|
SDK authentication |
Fraudsters send fake SDK messages to simulate valuable user actions. |
|
|
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 article.
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.
| 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 Installs report |
|
|
| Install attribution hijacking | Real-time |
|
|
| Post-attribution | Marked in the Post-Attribution Installs report |
|
|
| Fraudulent in-app event | Real-time | - | Blocked in real-time |
| Post-attribution | - | Marked in the Post-Attribution In-App Events report |
Using Protect360
Dashboard
The Protect360 dashboard displays aggregate fraud data and provides insights relating to fraudulent traffic.
Dashboard views:
Installs: LTV-based 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.
In-app events: Activity-based insights about fraudulent in-app events, 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, Export Data, and Data Locker (a premium feature).
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
Validation Rules enable app owners to set conditions to block certain installs, block attribution (and ensure that installs are attributed to the most recent valid media source), or block in-app events.
Fraud reconciliation with ad networks
With Protect360, advertisers get raw data regarding fraudulent installs and in-app events that ad networks may not have recorded as fraud.
If you discover that an ad network has been sending you traffic from suspicious sources, notify the ad network and ask them to stop sending you traffic from those suspicious sources. Use the raw data installs report column called Attributed Touch Time to verify that no more installs are received from the source after your request to stop it.
You can also use Protect360 data to reconcile with ad networks and receive full or partial refunds for past traffic from suspicious sources.
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.
- It's 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.
- It's 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
| Trait | Remarks |
|---|---|
| Advertiser access | All account users. |
| Ad network access |
|
| Agency access |
Protect360 dashboard and raw data access require advertiser permission. |
| Agency transparency |
Transparent agency: Can see specific media sources Non-transparent agency: Cannot see specific media sources |
| App-specific time zone |
|
| Data freshness | |
| Re-installs | Fraud data for re-installs is only available in raw data. Therefore, there may be discrepancies between the overall numbers in the dashboard and raw data reports. |
| Retargeting |
|
| Limitations |
|
FAQ and tips
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. |
|
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, website banners and landing pages, viral posts on social media, Push notifications, or even QR codes. |
|
What's new in Protect360 V2 compared with V1?
|
|
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 backward compatibility. |
|
Does post-attribution data update retroactively?
|
|
Why does the data look different when selecting specific/different networks in Anomaly insights? When you look at CTIT anomalies and select AF_Baseline as a benchmark, you may see Network A's anomalies. Then, if, for example, you select Network A as a benchmark, you will see other networks' anomalies, but not Network A. This outcome is actually what you should expect. When the trusted AppsFlyer baseline is used, networks with abnormal rates of CTIT display. When the anomalous network is used as the baseline, its installs aren't included as anomalies anymore, but installs from other networks may be considered anomalous relative to it. |
|
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:
|
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:
|
|
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. Similar to the new device ranking, LAT users may be legitimate users. However, a high percentage of them could indicate fraudulent activity. Detecting LAT:
|
|
Detecting click flooding fraud
|
|
Detecting click flooding with CTIT indicators Another indication of click flooding is the even distribution of CTIT. Detecting click flooding CTIT indications:
Use the Anomaly insights page to investigate sources with suspicious CTIT. |
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, a 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
Want to understand more about protection from fraud? Check out this short, informative course on the AppsFlyer Learning Portal.