Protect360—FAQ for partners

The AppsFlyer Protect360 system takes into account various parameters when making decisions on capping ad engagements, including but not limited to the volume of impressions, CVR, detected anomaly rate, normal fluctuations in activity, as well as industry and geographic benchmarks. The algorithm is dynamic and updated on an hourly basis, to take into consideration changing trends.

Once the capping mechanism is triggered, Protect360 blocks the ad network’s impressions for the related app within the current 24-hour cycle. This means that any impressions that occur after the threshold is reached are not recorded by AppsFlyer, nor are they eligible for attribution.

A network can avoid surpassing the threshold by stopping campaigns and publishers with unusually high volumes of ad engagements that do not show any impact on performance results.

We recommend taking a look at these articles:
Impression capping
Capping FAQ

Our click-flood algorithms run at various intervals over the course of the day, and whenever the threshold is crossed, based on internal parameters and logic, the publisher’s ad engagements will be ineligible for attribution.

Please note: Some of our click flood algorithms work across apps, implying that anomalies originating from identical fraudulent sources would be recognized for other advertised apps as well. 

We recommend reading: What is click flooding?

AppsFlyer’s anti-fraud detection applies different methodologies across various protection layers, such as single installs and install clusters. Clusters are being reviewed in various aggregations: by publisher, media source, app, and so on. The fraudulent activity is examined using various statistical algorithms and machine learning algorithms that consider each cluster as a whole. Thus, if a cluster is found fraudulent with high statistical significance, all installs in that cluster are considered fraudulent. It's a well-known fraudster tactic to mix some legitimate installs into high volumes of fraudulent activity in the hope that the fraud will be “diluted” enough to avoid triggering blocking mechanisms.

By default, all incoming installs are considered as LIVE traffic - hence to ensure your test install isn't categorized under the Protect360 algorithms, you would need to follow the steps mentioned in this article to register your device as a test device before performing a test.

Please review the "fraud sub reason" associated with the rejection for better clarity. This data is also available in Protect360 reports and on the Protect360 dashboard, subject to access granted by the respective advertiser.

We recommend reading about Protect360 blocked reasons.

You can view the results of our detection efforts using the Protect360 dashboard and raw data reports, subject to access granted by the respective advertiser.

We recommend taking a look at these articles:
Protect360 Dashboard
Protect360 Raw Data

AppsFlyer provides rejected attribution postbacks to ad networks for every install Protect360 rejects from attribution.

You can enable “rejected postback” by appending “rejected postback” parameters to your postback template by using Integration Management.

Real-time detection before attribution and post-attribution detection both belong to AppsFlyer’s Protect360 anomaly detection mechanism that applies in different time dimensions.

Compared to real-time detection, post-attribution detection relies more on data pointers collected after the install, during which, if anomalies are observed, Protect360 will record anomalous activities and display them under the post-attribution category.

Considering the above, certain detection methods (timestamp_anomalies, behavioral_anomalies, etc.) are more likely to be detected in the post-attribution stage rather than in real time, since the data is inconclusive on the level of an individual install but gains significance when examined for its distribution in statistical analysis.

Learn more about post-attribution detection.