Our system is centered on the discovery and management of abnormal activity. Some of examples of abnormal activity in this context include:
- A higher than average click through rate (CTR) or eCPM
- Frequent clicks from the same devices, IP addresses and IP ranges
- Short clicks, meaning a click coming from the same device or IP address in a short period of time
- Automated scripts designed to click on ads
- Click farms, in which groups of individuals are paid to click on ads
All of this activity is against Appodeal policy, and we make it our mission to root out such activity as quickly and effectively as possible.
So, how do we do it?
Let’s take a closer look at our fraud detection system.
Linking to AdMob
Apps are filtered before being set up with ad networks. Users are required to link to their own AdMob accounts, and we do not work with users who cannot link to or serve ads via AdMob. We rely on their filters to enhance the quality our apps with the first 1000 impressions always going to AdMob.
Apps that are not present in Google Play, the App Store, or Amazon Underground are limited to 2000 impressions a day, meaning they can not serve more than 2000 impressions without a presence in one of the aforementioned stores.
Inside SDK Protection
The Appodeal SDK boasts interior protection against fraud with the following core components.
Ads Viewability Check
In order to count an impression and send stats to the server, a viewability parameter is used. Each ad element must:
- Be shown on the screen at least 2 seconds
- Take up 80% of its real size
- Be in a visual part of the app
Background Processes Check
When an app goes to background, the SDK controls the processes of waterfall reload and the sending of stats by pausing.
Max Requests QPM (Quantity Per Minutes)
For ad networks and DSP, there is a limitation regarding the allowed number of requests from the SDK. This parameter is managed by DSP itself.
It is impossible to send duplicate clicks stats by shown ad units.
Visual Control
We check all apps that get more than 1000 impressions daily. We monitor which ads are requested, which ads are shown, and if the request stats from the apps are the same.
Request Response Ad Index
This index calculates and predicts the real time to load ads and requests for waterfall . If the interval decreases, we suspend it as there are too many ad requests. Then, we compare it with the impressions stats.
Disabling Banner Refresh and Stopping SDK Activity
We disable banner refresh when the app goes to background.
We also stop all SDK activity if the user is banned for fraud. After the user had been banned by server for fraud, the server notifies the SDK, and the SDK stops making ad requests or showing ads.
Fraud Detection Channels and Manual Analysis
Fraudulent apps feed into 2 detection channels in Slack.
Information about the app’s location of clicks, device ID, IP address, ad type, and click through rate (CTR) can be found here. From there, our team runs each abnormal app ID, or app identification number, through a series of tests in our Structured Query Language (SQL). This SQL was built by our team to pull data from our dashboard and produce information into this query.
The App ID is entered into the SQL along with the language used to decipher the amount of clicks, which IP address the clicks are coming from, and which device IDs the clicks are coming from.
We also test the ad type. We break down the information in a way that allows us to see how many clicks are coming from each ad format we offer (interstitial, video, banner, native). While tracking real-time impressions and clicks traffic, if we detect suspicious devices with aggressive fraudulent traffic, they are automatically blocked.
From there, we look for abnormal activity. This might look like a user producing 200-300 clicks from the same IP address and device after averaging 20 to 40 clicks in the past. In this scenario, one of our team members will download the app from the store and test the placement of ads to determine what caused the increase in clicks.
We have seen cases where the app owner places their ads in a spot where they are most likely to be clicked on, which interferes with the game or purpose of the app. In this case, we will warn the user, and he or she will have 5 to 7 days to change their placement and format. If the customer can substantiate the source of fraud traffic (eg. active testing applications), we do not block the application.
We analyze impressions and clicks for fraud activity, detect fraudulent click traffic, and calculate the fraud through rate (FTR) in relation to fraudulent clicks divided by all clicks.
Furthermore, when we suspect that a high FTR is due to an ad format or placement, the manager will contact the user, and suggest the removal or adjustment of the ad to decrease the FTR. If no actions are taken within 7 days or the user refuses to cooperate and fraud remains persistent, the app is blocked.
Clicks from an IP subnet can point to suspicious activity. However, in some cases IPs are not from one subnet. We can resolve the IP address by getting more information through a WHOIS service.
This service reveals who is the provider of a given IP address, even when a VPN is used. Different ip addresses may be revealed as having the same VPN provider, which falls into the category of suspicious activity.
We also check for bot clicks, which happen when a user employs third-party bots to click ads on their app. Take for example a botnet we dealt with in November of last year. Our team found all all 49K impressions coming from one single ip address only with 17 devices producing an average of 2850 impressions each.
App CFC (CallsFreeCalls), app_id = 3575. exchange clicks for phone calls. 2015-08-02 ip 69.116.107.24 made 3791 clicks. App blocked.
Fraudulent clicks are easily detected by the amount of clicks counted on the SQL and also by timing the intervals between each click. These users are banned right away without warning.
We’ve also encountered cases where publishers have offered a service or some other type of incentive in exchange for ad clicks. As you’ll see in the histogram below, almost all of the clicks made in this occurrence were made in short intervals, with half of the clicks having less than a 15-second interval.
Bottom line: In cases of absolute fraud, we remove the user in question right away.
