app-ads.txt is a text file that app developers place on their website to declare authorized digital sellers of their ad inventory. Introduced by the IAB Tech Lab in 2018, it extends the ads.txt standard from web to mobile apps. Before its arrival, mobile app ad fraud thrived on a simple loophole: a fraudulent ad network could claim to represent a popular app without the developer’s consent, and buyers had no reliable way to verify the claim. The file closes that gap by creating a public, crawlable record of authorized resellers.
The Problem: Mobile Ad Inventory Spoofing
In the mid-2000s, programmatic advertising on the web began to adopt real-time bidding, and with it came the need for transparency. The ads.txt standard, released in 2017, gave web publishers a way to list authorized sellers on their root domain. But mobile apps do not have a root domain in the same sense. An app’s ad inventory is identified by its bundle ID (e.g., com.example.game), and any party can send a bid request claiming that bundle ID. Without a verifiable link between the app and its developer’s domain, fraudsters could spoof inventory from high-value apps, pocketing the difference between what the buyer paid and what the real developer received—often nothing at all.
How app-ads.txt Works
An app-ads.txt file is a plain-text document hosted on the developer’s website at a well-known path: https://[developer-domain]/app-ads.txt. The file contains one or more lines, each with four fields:
- Publisher ID – the app developer’s identifier in the ad system (e.g., an AdMob app ID).
- Ad system domain – the domain of the ad exchange or network (e.g.,
admob.com). - Relationship type – either
DIRECT(the developer works directly with the ad system) orRESELLER(the ad system is authorized by a direct partner). - Certificate authority ID – an optional field that links to a digital certificate for additional verification.
When a demand-side platform (DSP) receives a bid request from a mobile app, it fetches the app-ads.txt file from the developer’s domain. If the ad system listed in the bid request does not appear in the file, or if the relationship type is mismatched, the DSP can reject the impression as potentially fraudulent.
Key Differences from ads.txt
While the concept is similar, app-ads.txt introduces several adaptations for the mobile ecosystem:
- Location: ads.txt sits at the root domain (
/ads.txt); app-ads.txt uses/app-ads.txton the developer’s domain, not the app’s domain (which may not exist). - Publisher ID: ads.txt uses a publisher’s numeric ID from the ad exchange; app-ads.txt often uses the app’s store identifier (e.g., Apple App Store ID or Google Play package name).
- Multiple apps: a single app-ads.txt file can cover all apps from one developer by listing each app’s publisher ID on separate lines.
- Verification mechanism: because mobile app bundle IDs are not tied to domains, the file relies on the developer’s domain being correctly associated with the app in app store listings (a process called “domain verification”).
From Click Fraud to Inventory Verification: A Historical Thread
Readers of this blog will recognize a familiar pattern: the fight against ad fraud has always depended on pattern recognition and signal analysis. In the early 2000s, click fraud was detected by analyzing statistical anomalies in click-through rates—an early application of machine learning to advertising data. By the mid-2000s, researchers at conferences like WWW and KDD were publishing papers on bot detection using traffic patterns, user-agent strings, and IP geolocation. These methods laid the groundwork for the automated crawling and verification systems that today fetch and parse app-ads.txt files at scale.
The file itself is a simple text document, but its enforcement requires robust document processing pipelines. Crawlers must handle redirects, cache headers, and edge cases like missing files or malformed entries. The IAB Tech Lab provides a validator tool, but many ad platforms have built their own verification systems that treat the file as a ground-truth signal in a noisy ecosystem.
Implementation Challenges and Best Practices
Adopting app-ads.txt is straightforward in theory but can be tricky in practice. Small developers often host their apps on multiple ad networks and may forget to update the file when adding or removing partners. Larger studios with dozens of apps must maintain a single file that correctly maps each app to its authorized sellers. A common mistake is using the wrong publisher ID format—some ad systems expect a numeric ID, others a string. The IAB maintains a list of recommended ad system domains, but not all networks follow the naming convention.
Another challenge is domain verification: the app store listing must include the developer’s website URL, and that URL must match the domain where app-ads.txt is hosted. If the store listing says example.com but the file lives on www.example.com, the verification fails. This is a classic example of how a seemingly trivial formatting issue can break an entire transparency mechanism.
Why This Matters for the History of Pattern Recognition
app-ads.txt is not a machine learning model, but it is a direct descendant of the transparency movement that began with the IAB’s ads.txt standard. The file’s design reflects lessons learned from two decades of ad fraud: that no amount of algorithmic detection can replace a simple, publicly verifiable declaration of intent. In the mid-2000s, researchers working on document image analysis and OCR were solving similar problems of extracting structured data from unstructured sources. The app-ads.txt file is, in essence, a structured document that machines must parse reliably—a problem that those same researchers helped solve.
For a concrete example, consider a developer of a puzzle game with the domain puzzlegame.example. They list their authorized sellers as admob.com (DIRECT) and unityads.com (RESELLER via AdMob). When a DSP receives a bid request claiming to be from that puzzle game but listing an unapproved network like fraudnetwork.com, the DSP fetches , sees no entry for that domain, and rejects the bid. This simple check prevents millions of dollars in fraudulent transactions each year.