What is App-ads.txt?

App-ads.txt, which stands for Authorized Digital Sellers for Apps, is a text file app publishers place on their developer website. It lists all the companies authorized to sell their ad inventory. This simple file helps prevent ad fraud by allowing buyers to verify the legitimacy of the ad space they are purchasing.

This initiative was developed by the IAB Tech Lab as an extension of the original ads.txt standard. The first version was designed for traditional websites to combat fraud in the desktop and mobile web advertising space. It proved highly effective at increasing transparency.

However, the mobile app ecosystem presented a unique challenge. Unlike a website, a mobile app does not have its own domain where a file can be hosted. This made it difficult for ad buyers to verify the sellers of in-app ad inventory.

App-ads.txt solves this problem by using the developer’s website, which is linked from the app’s store listing on platforms like the Google Play Store and Apple App Store. This creates a clear, verifiable connection between the app and the authorized sellers of its ad space.

The primary purpose of the file is to fight ad fraud, particularly inventory spoofing. This occurs when a fraudster falsely claims to be selling ad space within a popular, high-value app. Advertisers would then unknowingly buy fake impressions, with the money going to the fraudster instead of the actual app publisher.

By implementing app-ads.txt, publishers gain direct control over who can sell their inventory. It gives advertisers and their buying platforms (DSPs) a simple method to confirm they are buying from a legitimate source. This process builds trust and ensures ad revenue flows to the correct developers.

How App-ads.txt Works: The Technical Mechanics

The system operates on a straightforward process of declaration and verification. It connects the app, the publisher’s website, and the advertising systems through a chain of trust. The core of this system is a simple text file with a specific format.

First, the app publisher creates the `app-ads.txt` file. This is a plain text file, not a Word document or PDF. Each line in the file represents a single authorized advertising partner.

The format for each line contains three mandatory fields and one optional field, separated by commas. The structure is: `Domain of the advertising system, Publisher’s Account ID, Type of Account/Relationship, Certification Authority ID (optional)`. An example entry might look like this: `adnetwork.com, pub-0123456789, DIRECT, c987654b321a`.

The publisher must get this exact information from each of their monetization partners. The Publisher ID is unique to the publisher’s account with that specific ad network or exchange. Using an incorrect ID is a common error that can block revenue.

The third field, ‘Type of Account’, is critical. ‘DIRECT’ means the publisher has a direct contract with the advertising system listed. ‘RESELLER’ indicates the publisher has authorized a third party to sell their inventory through that system.

Once created, the file must be uploaded to the root of the developer’s website domain. This is the most crucial step for discoverability. If the developer URL in the app store is `www.coolgames.com`, the file must be accessible at `coolgames.com/app-ads.txt`.

Advertising buyers, primarily Demand-Side Platforms (DSPs), are responsible for the verification step. Their systems are programmed to crawl the developer URL found in an app’s store listing. They specifically look for the `/app-ads.txt` path.

After finding and parsing the file, the DSP stores or caches this information. The entire verification process happens at immense scale, covering millions of apps. This cached list of authorized sellers is then used during the real-time bidding auction.

When an ad opportunity arises in the app, the Supply-Side Platform (SSP) sends a bid request to the DSP. This request contains information about the app and the seller. The DSP then checks the seller’s information against its cached list from the app-ads.txt file.

If the seller in the bid request is on the authorized list, the DSP considers the inventory legitimate and proceeds to bid. If the seller is not on the list, the DSP flags the impression as unauthorized and will not bid. This effectively cuts off fraudulent sellers from the advertising budget.

The Step-by-Step Verification Flow

• Step 1: Publisher Linkage. An app publisher lists their application on a major app store and includes a valid URL for their developer website in the store profile.
• Step 2: File Creation. The publisher gathers the required authorization lines from all their ad monetization partners (SSPs, ad networks, exchanges).
• Step 3: File Hosting. The publisher compiles these lines into a single `app-ads.txt` file and uploads it to the root directory of their developer domain.
• Step 4: Buyer Crawling. Ad buying platforms continuously crawl the developer URLs from app store listings to discover and cache these `app-ads.txt` files.
• Step 5: Bid Request. A user opens the app, triggering an ad request. The ad exchange or SSP sends a bid request to multiple DSPs on behalf of the publisher.
• Step 6: Real-Time Cross-Reference. The DSP receives the bid request, which includes the seller’s ID. It instantly cross-references this ID with the authorized sellers listed in its cached `app-ads.txt` file for that specific app.
• Step 7: Bidding Decision. If the seller’s ID is found in the file, the bid is considered valid, and the DSP may place a bid. If it is not found, the bid request is discarded, and no bid is placed.

App-ads.txt Implementation: Three Case Studies

The practical application of app-ads.txt highlights its importance. Its absence or incorrect implementation can lead to significant revenue loss, while its proper use can protect and grow a publisher’s income. Here are three distinct scenarios.

Scenario A: E-commerce App Monetization

StyleStash, a fashion retail brand, has a popular shopping app. To generate incremental revenue, the app displays advertisements from non-competing lifestyle brands. This monetization stream was performing well until they saw an unexpected drop in revenue.

The problem was a steady decline in their ad CPMs and fill rates from high-value ad partners. Their own analytics showed that impression volumes were stable, but the value per impression was falling. An investigation revealed that fraudsters were spoofing their app’s bundle ID, selling fraudulent ad inventory on the open market using the StyleStash name.

Advertisers thought they were buying space in a premium e-commerce app but were actually getting low-quality, fake impressions. When DSPs detected the low performance, they lowered their bids for anything associated with the StyleStash app, punishing the real inventory along with the fake.

To fix this, the StyleStash monetization team implemented `app-ads.txt`. They contacted their three exclusive SSP partners and got the precise lines to add to their file. They created the file and uploaded it to the root of their main company website, which was the URL listed in their app store profile.

Within two weeks, the change was dramatic. DSPs could now confidently distinguish the legitimate StyleStash inventory from the fraudulent spoofed inventory. They blocked bids on the unauthorized sellers and directed their budgets to the verified supply paths. StyleStash’s CPMs recovered and then grew by 40% as buyer confidence was restored.

Scenario B: B2B SaaS Freemium Model

SyncNotes is a B2B productivity software company offering a freemium app. The free version is supported by in-app ads. For SyncNotes, brand safety was more important than maximizing every fraction of a cent from ad revenue. Their reputation as a professional tool was their top priority.

They began receiving user complaints about low-quality and sometimes inappropriate ads appearing in the app. This was a major issue, as it damaged their professional image and could discourage users from upgrading to the paid tier. The root cause was that their inventory was being resold through multiple, non-transparent ad exchanges.

SyncNotes had no `app-ads.txt` file, which meant they had no control over the long tail of resellers. Any number of unknown entities could be selling their ad space, often bundling it with low-quality inventory that attracted bottom-tier advertisers.

The solution was to take firm control of their supply chain. They created a very strict `app-ads.txt` file. They decided to work only with two `DIRECT` ad exchanges known for their rigorous brand safety filters and high-quality advertisers.

They completely cut out all reseller relationships. After implementing the file, they saw a slight dip in total impressions, as the long tail of resellers was now blocked. However, their average eCPM increased by over 60%. Advertisers were willing to pay a premium for verified, brand-safe inventory in a professional B2B app. User complaints stopped entirely, protecting the brand’s integrity.

Scenario C: Hyper-Casual Mobile Game Publisher

PixelPioneers is a mobile game studio that lives and dies by ad monetization. Their portfolio of hyper-casual games generates billions of impressions monthly. To maximize revenue, they worked with over a dozen ad networks and a complex mediation waterfall.

Because they had no `app-ads.txt` file, their supply chain was completely opaque and a prime target for fraud. Bad actors were spoofing their most popular game title on a massive scale. It was estimated that nearly 25% of the inventory being sold under their game’s name was fraudulent, siphoning millions in ad spend away from the studio.

The first step was a comprehensive audit of all their monetization partners. The finance and ad ops teams worked together to identify every legitimate SSP, ad network, and exchange they used. They requested the `app-ads.txt` entries from each verified partner.

They carefully compiled a complete and accurate `app-ads.txt` file and hosted it on their developer website. This file contained entries for all their `DIRECT` partners as well as the authorized `RESELLER` partners they had approved.

The impact was immediate and profound. The flow of ad spend to fraudulent sellers was cut off almost overnight. The budget that advertisers had intended for PixelPioneers’ games was now reaching them. In the first quarter after implementation, their total ad revenue increased by 30%, adding millions to their bottom line.

The Financial Impact of App-ads.txt

Implementing app-ads.txt is not just a technical best practice; it has a direct and measurable effect on a publisher’s finances. The return on investment for creating and maintaining a simple text file is exceptionally high. The financial benefits come from both recovering lost revenue and increasing the value of existing inventory.

The most immediate benefit is the reclamation of revenue lost to fraud. When fraudsters spoof an app, they are stealing directly from the publisher. If an advertiser spends $100,000 on what they believe is your app’s inventory, but 20% of that is fraudulent, you lose $20,000.

By implementing app-ads.txt, you provide a mechanism for buyers to block that fraudulent 20%. That ad spend doesn’t just disappear; it gets redirected to the available pool of legitimate, verified inventory. This means the publisher can capture a larger share of the advertiser’s total budget.

Beyond fraud prevention, app-ads.txt increases the perceived value of your inventory. In the programmatic marketplace, transparency and trust command higher prices. Buyers are willing to pay higher CPMs for inventory they can verify is authentic and coming from a direct source.

Let’s consider a simple mathematical example. A game publisher generates 20 million ad impressions per month. Without app-ads.txt, their inventory is mixed with fraudulent supply, driving the average CPM down to $1.50 due to buyer uncertainty.

Monthly Revenue: (20,000,000 impressions / 1000) * $1.50 CPM = $30,000

After implementing a clean `app-ads.txt` file, fraud is eliminated. Buyer confidence increases, and they are now willing to pay a premium. The average CPM for this verified inventory rises to $2.00.

New Monthly Revenue: (20,000,000 impressions / 1000) * $2.00 CPM = $40,000

This represents a $10,000 monthly increase, or $120,000 annually, for the publisher. This lift is achieved without needing to generate a single extra impression. It’s purely the result of improving the quality and transparency of the supply chain.

Strategic Nuance and Advanced Tactics

While the basics of app-ads.txt are simple, there are strategic considerations and common misunderstandings that can affect its success. Moving beyond a basic implementation can provide a competitive advantage and further secure your revenue.

Myths vs. Reality

A common myth is that `app-ads.txt` is optional. While app stores do not technically require it for an app to be listed, the economic reality is different. The vast majority of major DSPs and programmatic buyers will not purchase inventory from an app that lacks a valid `app-ads.txt` file. In practice, it is mandatory for any serious monetization strategy.

Another misconception is that a larger file is better. Some publishers believe they should add every possible ad network to their file to maximize demand. This is counterproductive. A bloated file filled with unknown resellers signals a poorly managed and low-quality supply chain to buyers, potentially lowering the value of your inventory.

Finally, many publishers see `app-ads.txt` as a ‘set it and forget it’ task. The file is a living document that must reflect your current business relationships. If you stop working with an ad network but leave them in your file, you are creating a security risk. If you add a new network but forget to update the file, you are blocking your own legitimate revenue.

Advanced Tips for Optimization

Go beyond the basics by performing quarterly audits of your `app-ads.txt` file. Cross-reference every line in the file with your active monetization partners and SDKs. Remove any entries for companies you no longer have a direct relationship with. This keeps your supply chain clean and secure.

Publishers should also use the IAB’s other transparency tools for reverse verification. Check the `sellers.json` file of your SSPs and exchanges. This file is their public declaration of all the publishers they work with. You should ensure your company name and publisher ID are listed correctly, confirming the relationship from their side.

Pay close attention to your developer URL. A common point of failure is a mismatch between the website listed in the app store and the domain where the `app-ads.txt` file is hosted. Ensure you own and control the domain listed, and correctly handle redirects from ‘www’ to the root domain, as crawlers will check the root.

Abisola

Meet Abisola! As the content manager at ClickPatrol, she’s the go-to expert on all things fake traffic. From bot clicks to ad fraud, Abisola knows how to spot, stop, and educate others about the sneaky tactics that inflate numbers but don’t bring real results.

View all posts by Abisola (Abisola)