Three new ways to find fraud using post-install data
Aberrant in-app engagement is one of the most important and frequently misunderstood mobile app install fraud signals.
As an anti-fraud data scientist, my team looks at both pre-install information as well as post-install engagement insights to identify and block bots, device farms, and non-human behavioral anomalies. However, smart marketers realize just how important it is to understand their fraud benchmarks and define their fraud terms with networks.
Today, I would like to share three ways you can identify and address fraud using your post-install engagement data.
Please note that while marketers with Protect360 now have the events/installs rate in the Advanced Detection report, this metric is also available to all AppsFlyer customers in the Overview Dashboard.
Not yet working with AppsFlyer? Just download your raw data reports to divide your installs by a specific in-app event count to built your events/installs rate KPI.
Scenario 1: The overzealous fraudster
Though mobile fraudsters are always getting smarter, post-install engagement is considerably harder to fake.
Consider the data set below.
This fraudster’s traffic delivers extremely high-quality users. This is often too good to be true.
While it is highly unlikely that 100% of their installs completed a tutorial, it is extremely unlikely that 95% of their installs also completed level one.
To validate this activity, we can compare this publisher with first-party traffic from a highly reputable media source.
This publisher is outperforming a top source’s first-party traffic by 4x. This could be a bot script, a device farm, or possibly mislabeled incentivized traffic, but it is almost certainly fraud.
Scenario 2: The flat funnel
Using the same approach, let’s consider a typical post-install user journey.
As you can see, the majority of users who have downloaded this shopping app will click on at least one item.
However, only one-third of those users will add the item to their cart, and just over half of those users will continue to register for the shopping platform before completing a purchase.
Now let’s consider the publisher below.
When we compare this events/installs rate funnel with the publisher below, we can clearly see that something is off.
In this case, the fraudster looks to be limiting its in-app activity, trying to simulate good, but realistic engagement rates.
However, with limited insight into this advertiser’s engagement patterns, the fraud clearly stands out.
If your measurement partner is using an Open Source of insecure SDK, this could be an SDK spoofing bot. If you are using a more secure SDK, this is fraud is likely coming from a simulator or device farm.
Get the latest marketing news and expert insights delivered to your inbox
Scenario 3: The limits of in-app engagement
Many types of mobile ad fraud, including bots, rely on weak SDK authentication (security). Weak solutions such as inserting a “signature” into SDK calls can be compromised in minutes – simply record a few open source SDK calls, identify the signature, and insert it into your own bot SDK calls.
However, strong SDK hashing makes it very difficult for fraud bots to simulate many types of in-app events.
Consider the publisher below.
In this extreme situation, the fraudulent bot managed to simulate a real click and install, but the bot was unable to simulate in-app events.
This is a telltale sign of bot fraud, often SDK spoofing that has been limited by strong SDK encryption.
In this case, the fraudulent bot was able to successfully fire one in-app event, but not any others.
This heavily lopsided engagement is almost always indicative of non-human traffic.
Sometimes, a fraudulent publisher will mix in some “real” traffic to try to hide their mostly bot-driven activity. In the example above, Publisher 1 shows a lopsided post-install engagement pattern, but they aren’t quite at the zero events/installs rate.
By benchmarking their performance against the app’s average performance trend, or a trusted media source, we can clearly see that this traffic is indeed, highly suspicious.
What you should do
Here are my five tips for marketers:
- Set clear fraud terms with all of your media sources. This will help avoid lengthy reconciliation negotiations down the line.
- Pay attention to your in-app engagement patterns and raw data reports using the methods outlined in this post. If you see something suspicious, bring it up with your attribution provider and media source partners.
- Stick with secure SDK providers. One-off solutions like signatures are easily compromised and require that you keep your SDK integration updated each time you are breached.
- Keep your measurement SDKs up-to-date to ensure that you have the latest security measures applied.
- When selecting a fraud provider, look for someone with deep knowledge of the mobile industry, a broad mobile data set and the ability to block fraud in real-time.
