Mobile ad fraud: how to check installs from a new ad network

In September every paid install of the grocery delivery app came from four networks: Meta, TikTok, Google and Apple Ads. The app and the September figures are the same as in the lesson on MMPs in practice, and all the figures are invented. In October the marketer added a fifth source: a small network that shows ads inside other Android apps and charges 250 ₸ per install, less than TikTok. Over 1-14 October the network delivered 4,000 installs for 1,000,000 ₸, and within the first week after install (D7) those users placed 360 first orders. That is 2,778 ₸ per first order, against 4,000 ₸ at Google and 5,000 ₸ on average in September, and the marketer wants to triple the budget. Before you agree, find out who the network actually brought.

Why the SRNs never raised this question

The four September networks are self-reporting networks (SRNs): they have no tracking link, and they claim installs themselves from their own data when the MMP asks them by the device advertising ID (how AppsFlyer works with SRNs). The new network works through an attribution link: it reports every click to AppsFlyer, and AppsFlyer gives the install to the last click inside the window, even if the person clicked a Meta ad earlier, so nearly every scheme below works through those clicks.

A fake person and a stolen install

Adjust splits mobile fraud into two kinds (Adjust's classification). In the first there is no real person: the install and the events are faked. In the second a person installs the app on their own, and a fraudster slips in a click on their behalf to take the attribution. AppsFlyer draws the same line between a fake install and attribution hijacking (Protect360 block reasons).

The key consequence: checking against orders only catches the first kind. In the second, the order is real and the money arrived; only the source is in question, as in the picture. That is why paying per first order (CPA) instead of per install gives no protection against stolen attribution. For the delivery app, faked events are caught by matching first_purchase against the order system by order number, as in the lesson on SDK integration.

CTIT: time from click to install

CTIT (click to install time) is the time from the click that got the install to the first launch of the app. It includes the store, the download and the wait until the person opens the app.

Each vendor has its own benchmarks. In the Protect360 guide, AppsFlyer says that usually about 30% of installs take more than an hour from click to launch, and a placement where over 50% do is suspect. More than five hours: usually about 20%, suspect above 40%. Adjust counted over 85% of installs from normal traffic within the first hour in its own data, and once most of a source's conversions arrive 60 minutes or more after the click, its filter starts rejecting clicks. Since the vendors' norms differ, the more reliable move is to compare one network's placements with each other over the same weeks.

A short CTIT is the trace of a different scheme. Android tells installed apps when a new app is being installed, and a malicious app sends a click after the download has started. Google Play gives the app the time the install began, and a click later than that gives the injection away. According to Adjust, click injection only happens on Android.

If your export has no install start time, CTIT itself is the guide. AppsFlyer does not disclose its own thresholds, so 10 seconds is this lesson's threshold: in that time nobody can get to Google Play, download a grocery delivery app and open it.

The test, placement by placement

For the test, the service turned on AppsFlyer raw data (a paid add-on on the Growth plan): without the click time (Attributed Touch Time) and install time on every row, there is no way to check the network. On every click the network passes af_siteid, the placement ID, meaning the app where the ad was shown (attribution link parameters). The marketer grouped installs by af_siteid and calculated CTIT, sign-ups and D7 first orders for each placement. A sign_up here means a phone number confirmed with an SMS code plus an address inside the delivery zone (event plan).

Across the network, 35% of installs took more than an hour, which by AppsFlyer's benchmark is close to normal. Placement by placement, the picture is different.

1042. A thousand installs, 10 sign-ups and not a single order: 990 devices stopped at the step with the SMS code and the address. Behind such installs there is either nobody at all (a device farm, emulators, spoofed SDK messages) or someone who installed the app for some other reason, such as a bonus in another app. Without Protect360 you cannot tell which, and for payment it makes no difference: for 250,000 ₸ the service got not one customer.

2210. For 70% of installs more than an hour passed from click to launch, against 30% on the network's other placements. Yet 2210 has the best customers in the network: 15% first orders, the same as Google in September. This is what click spamming looks like: the network fires clicks on behalf of a huge number of people, and when one of them installs the app on their own, the last click belongs to the network. In this scheme the people are real; the network just did not bring them. AppsFlyer says outright that such sources have a low click conversion rate but good users, because those users are real.

Next, look at where those installs might have gone missing. Organic Android installs were about 300 over 1-14 September and 150 over 1-14 October. Meta and Google on Android had 2,000 installs together over 1-14 September and 1,650 over 1-14 October, although their October spend did not change: in this example that is an assumption. TikTok is left out: in October its geography and optimisation event changed. Together about 500 installs went missing, and that loss accounts for roughly half of 2210's installs. Two weeks are too few for a conclusion: demand in early October may have differed from September. A test will settle it: switch 2210 off for two weeks and compare the second week, because during the first one installs from old clicks inside the seven-day window are still being counted. Use Attributed Touch Time to confirm that no installs with 2210 clicks arrive after the switch-off, and see whether organic installs and Meta and Google installs on Android come back.

3105. For 55% of installs, less than 10 seconds passed between click and launch. That is the trace of click injection. Sign-ups and orders look normal, 40% and 13%: if this is injection, the people started the install themselves and the network slipped in a click at the last moment. CTIT alone cannot tell you whether the click came after the install began, so the conclusion is likely, not final.

Other placements. 1,600 installs, 30% over an hour, 40% sign-ups and 10% first orders, the same as Meta in September. This looks like ordinary in-app advertising traffic.

Now the money. In the worst case, if 2210 and the fast clicks on 3105 took other sources' customers outright, the network brought not 360 first orders but between 160 (the other placements alone) and 225 (if all of 3105's orders came from ordinary clicks). That makes 4,444 to 6,250 ₸ per first order instead of 2,778 ₸, roughly what Meta costs. If only the 500 installs of 2210 that the loss accounts for turn out to be someone else's, and 3105 is clean, the total is about 285 orders (160 + 60 from 2210's remaining 400 installs + 65), or about 3,500 ₸ per first order. The other placements on their own cost 400,000 ₸ and bring 160 first orders at 2,500 ₸ each: they are the ones worth testing further.

Post-attribution fraud

Protect360 works in two layers (Protect360 guide). The first blocks an install in real time; the second finds fraud after attribution, on the install day and up to 7 days later, and marks the install in the Post-attribution reports. The person's app keeps working either way; only the attribution changes. With Protect360, AppsFlyer advises reconciling with the network at the start of the month using the Blocked and Post-attribution reports.

The delivery service has no Protect360. On the Growth plan AppsFlyer provides Basic fraud protection, while Protect360, post-attribution protection and Validation Rules are marked for the Enterprise plan only (AppsFlyer pricing). So the service reconciles on its own: raw data, af_siteid and D7 orders. Pay the network once a month, once 7 days have passed for the installs from the last day of the month, and never in advance every week: otherwise you pay for installs you will later reject yourself.

At Adjust these filters come together in the Fraud Prevention Suite, a separate paid package. The SDK Signature library usually comes bundled with version 5 of the Adjust SDK, while rejecting unsigned traffic is switched on in the settings.

The contract before the first click

With a network that works through an attribution link, write the terms down before launch:

• Payment covers installs in AppsFlyer except blocked ones and installs from placements switched off under the thresholds. Reconciliation happens once D7 has passed for the month's last installs, and payment follows it.
• Every click carries af_siteid, and the service can switch off any placement at its own discretion.
• Thresholds per placement are named in advance, for example: CTIT over an hour for no more than 50% of installs, per AppsFlyer's benchmark, and a sign_up rate no lower than half the app average. A placement below the sign-up threshold brings people who cannot or will not order.
• The test volume is small enough for the team to review every week, and the budget has a cap.

Exercise: a check plan for your own network

Take an app you work on, or the delivery service from this lesson:

• List the install sources and mark which are SRNs and which work through an MMP link.
• Record a baseline: organic installs per day on each platform for two to four weeks before the test.
• Turn on raw data for the test period (a paid add-on on Growth) and see whether af_siteid arrives with the clicks.
• Once a week, calculate for each placement the share of CTIT under 10 seconds and over an hour, sign_up and D7 first orders.
• Write down the contract terms: what gets paid, when reconciliation happens, which thresholds apply, who can switch off a placement.
• Plan a switch-off test: which placement goes off for two weeks, and which numbers you compare in the second week.

Now a situation. The network's manager replies to your analysis: "Long CTIT on 2210 is normal: people download in the evening and open the app in the morning. And its customers are the best in the network." What do you say?

People really do open the app in the morning, which is why about 30% of installs with CTIT over an hour is normal, and that is exactly the share on the network's other placements. On 2210 it is 70%. The manager's argument can be checked: if habit is the reason, 2210's clicks come in the evening and the installs in the morning. Look at the click times by hour in the raw data and at the share of CTIT over five hours: normal is about 20%, suspect above 40%. Good customers are no argument either: with click spamming the network claims real people who would have come anyway. Organic Android installs over the same weeks fell from 300 to 150, although two weeks cannot name the cause. So reply with a proposal: 2210 goes off for two weeks, and if organic installs and Meta and Google installs on Android come back in the second week, its installs are not paid for. Payment for 2210 waits until the result is in.

Video: the main mechanisms of mobile ad fraud

An overview of the schemes from impact.com.