• Advertising
  • Trust and Brand Safety

Fraud in Mobile In-App Advertising: What You Should Know

Team InMobi
Team InMobi
7 min read
Posted on September 16, 2020
Fraud in Mobile In-App Advertising: What You Should Know

While consumer time spent in app keeps rising, some advertisers are still hesitant to devote a significant share of their ad budgets to in-app channels. There are a few reasons why this is the case, but high on the worry list is fraud. Too many advertisers today are worried that their in-app ad budgets will be eaten up by fraud and won’t help their marketing and business goals. 

But are these fears unfounded? Advertisers and agencies worry about fraud in in-app advertising, but much of it is down to perceptions that have not kept pace with reality. While fraud may have been a major problem once upon a time, it is not a major concern anymore with in-app advertising.  

According to the latest reporting from DoubleVerify in their Global Insights Report 2020, fraud rate for mobile apps declined by nearly one-third in just the last one year, decreasing from 2.8% in 2018-2019 to 1.9% in 2019-2020. Even in comparison to other channels, in-app fraud rates have fare relatively well. DoubleVerify estimates that fraud rate on in-app is 42% lower than the fraud rate on desktop. According to another 2019 study, in-app has 25% less fraud than mobile web. 

Why does in-app advertising then have this unfounded reputation to begin with? Back in the very early days of programmatic in-app advertising, fraud in in-app advertising rose because of two reasons.  

For one, in-app ads commanded higher per-impression costs because of the enhanced targeting and creative capabilities for advertisers compared to other digital channels (in particular desktop and mobile web). As a result, fraudsters had a higher payoff when they got away with their fraud attempts. In addition, back when in-app was an emerging channel, it did not have sophisticated quality controls to catch fraud. 

As the in-app advertising matured, ecosystem players have put in substantial preventive measures to catch and block fraud attempts at every step of the impression lifecycle. Even the most complex in-app ad fraud attempts have been uncovered with the help of sophisticated solutions. And yet, advertisers continue to hold back their in-app investments because of their perception that in-app advertising is more prone to fraud 

Understanding the Current State of In-App Ad Fraud 

While in-app ad fraud is far less of an issue now than it was a few years ago, that doesn’t mean it has gone away entirely. After all, credit cards have been around for decades now but credit card fraud still exists – and it’s unlikely that either forms of fraud will ever disappear entirely, unfortunately. 

In-app fraud can be categorized into three main categories:  

  • Bot Fraud – Invalid traffic (IVT) generated by bots that’s designed to look like human traffic 
  • App/Site Fraud – Ad request claiming to be from one app or publisher (typically a popular app), but actually originating from other less popular or premium apps  
  • Other Device/User-Based Fraud – Other app fraud scenarios like ads playing in background (out of view of legitimate users), ad stacking (multiple ads displayed all at once), click injection (unfairly claiming credit for the final click that leads users to install an app), etc. 

Within these, bot fraud is more prevalent on desktop, mobile web and the recently introduced CTV/OTT (connected TV/streaming video) environments. It is difficult for such fraud to be perpetrated in closed app environments, and most supply side partners deploy solutions to counter them.  

While mobile app fraud rates have declined about 32% year-over-year, they are still roughly twice as high as mobile web fraud rates, according to this 2020 report from DoubleVerify, and warrants for advertisers’ attention and a robust supply-side platform (SSP) selection process. 

How Advertisers Can Safeguard Their In-App Ad Budgets from Fraud 

We strongly recommend advertisers to look for the following things in their supply-side platform partners to make sure they are buying fraud free supply: 

  • The SSP should have a large SDK footprint, as SSPs with their own SDK network of publishers typically have controls and guardrails for evaluating traffic quality and ensuring ads are rendered in a viewable environment, which cuts down the risk of bot fraud and device/user-based fraud. 
  • They should have comprehensive pre-bid and post-bid invalid traffic (IVT) solutions to check for all inventory quality. InMobi partners with DoubleVerify for their pre-bid and post-bid solution that scans 100% of InMobi’s inventory before it’s made available for DSPs to bid on. 
  • The SSP should be a part of industry consortiums and communities (like The Trustworthy Accountability Group and the Interactive Advertising Bureau) that are dedicated to fighting fraud across the ecosystem. This participation can be enormously useful, as TAG-certified channels have been proven to have 88% less fraud than non-certified partners. 
  • SSPs should have a robust vetting process for sellers before onboarding them, and the SSP should continue to enforce transparency across supply chain events.  
  • Advertisers need to ensure the SSP of choice has a firm commitment to trust, safety and transparency. Exhaustive app-ads.txt coverage, implementation of sellers.json and support for OpenRTB SupplyChain Object are the checkpoints advertisers need to look for while selecting the SSP. Add internal assessments and regular audits on the SSP side, and advertisers can be assured of clean and fraud free supply. 

Fraud in in-app advertising is not nearly as big of a problem as it was a few years ago, but that doesn’t mean that it can be ignored. Still, by working with the right partners that are committed to stamping out ad fraud and promoting transparency, advertisers can be sure their in-app ad budgets are yielding the best results for them. 

Stay Up to Date

Register to our blog updates newsletter to receive the latest content in your inbox.