The first time a publisher tells you that your fill rate dropped by 30% overnight, the cause is rarely a bad SDK update. More often, it's the ads.txt file — or the lack of one. For app developers, ads.txt is a plain-text file hosted on your domain that lists the ad sellers authorized to sell your inventory. When it's missing or misconfigured, demand partners can't verify your supply, and programmatic buyers stop bidding. The result is silent revenue leakage that can persist for weeks. The fix is straightforward and doesn't require a dedicated ad ops team.
What App Ads.txt Actually Does
Ads.txt (Authorized Digital Sellers) is an IAB standard originally designed for web publishers. The app version, app-ads.txt, applies the same idea to mobile apps. You host a file at a URL like that lists every seller account (like AdMob, AppLovin, or ironSource) authorized to sell your ad impressions. Each line includes the seller's domain, seller account ID, and relationship type (direct or reseller).
When a programmatic bid request comes in, the exchange checks the app-ads.txt file to confirm the seller is authorized. If the file is missing, misconfigured, or the seller isn't listed, the exchange either discounts the bid or blocks it entirely. This isn't a theoretical risk — it's a daily occurrence. Many smaller studios only discover the problem when they dig into a sudden drop in eCPM or fill rate.
Why Developers Ignore It — and Why That Costs Money
The most common reason developers skip app-ads.txt is simple: it's not a visible part of the app binary. It lives on your web domain, and if you don't have a domain attached to your developer account, you might not even know it exists. But ad networks and exchanges check it constantly. Without it, your inventory is treated as unverified, which often means lower bids or no bids at all from premium buyers.
Another reason is confusion about where to host the file. For Android, you host it on your website's root domain. For iOS, the same file is hosted on your app's domain or your developer website. If you have multiple apps, you can host one file per domain, but each app must reference the correct domain. A simple typo in a seller ID or a missing line for one ad network can invalidate the entire file.
Step-by-Step: Setting Up App Ads.txt Correctly
Here is a practical checklist for a typical studio with three to five ad networks:
- Find your seller IDs. Log into each ad network's dashboard (AdMob, AppLovin, Unity Ads, etc.) and locate your publisher or seller ID. This isn't the same as your app's bundle ID.
- Create the file. Open a plain-text editor and add one line per network. Use the format:
domain, accountID, DIRECTfor direct relationships, anddomain, accountID, RESELLERfor resellers (like mediation partners). - Host it. Upload the file to the root of your domain (e.g.,
). For iOS, you may also need to host it on your app's marketing site. - Verify. Use a tool like the IAB's ads.txt validator or your ad network's built-in checker. Confirm that each line is correct and that the file is publicly accessible.
- Monitor. Re-check the file after any ad network change, domain migration, or when you add a new mediation partner.
One common mistake is using a redirect. The file must be served directly, not via a 301 redirect, or most exchanges will ignore it. Also, ensure there are no extra spaces, tabs, or BOM (byte order mark) characters that can break parsing.
Common Pitfalls and How to Avoid Them
- Using the wrong seller ID. Each network has a specific ID format. Copy-paste directly from the dashboard, never type it manually.
- Forgetting to update after adding a network. If you add a new mediation partner, you must add its seller line to the file immediately. Otherwise, that partner's demand will be severely limited.
- Hosting on the wrong domain. If your app uses a custom domain for deep linking (e.g.,
links.yourgame.com), that is not the right place. Use the primary domain associated with your developer account. - Not checking for HTTPS. The file must be served over HTTPS. If your domain has an invalid SSL certificate, the file will be ignored.
How App Ads.txt Fights Ad Fraud
Ad fraud is not just about bots clicking on ads. In the programmatic space, a common scheme is domain spoofing — where a fraudster sends a bid request that looks like it comes from your app, but the traffic is fake. App ads.txt gives buyers a way to verify that the request actually originates from you. If your file lists only your direct seller accounts, any request from an unlisted seller is flagged as suspicious and blocked.
For a small studio, this is a low-effort, high-impact fraud prevention measure. Unlike fraud detection SDKs that require ongoing maintenance, app-ads.txt is a static file that works in the background. It doesn't replace fraud detection, but it closes the most common loophole that bad actors exploit.
When You Need More Than the Basics
If your app is distributed through multiple stores (Google Play, Samsung Galaxy Store, Amazon Appstore), you need to host separate app-ads.txt files for each store's domain. Google Play uses your website domain, while Amazon requires hosting on your developer website. The same file can be used, but it must be accessible at the correct URLs for each store.
For studios with several apps, consider consolidating seller IDs into a single file and referencing the same file from all app listings. This reduces the chance of drift, but be careful: if one app has a different set of ad networks, you must list all authorized sellers for that app, not just the common ones.
Monitoring and Auditing Your File
Setting up app-ads.txt is not a one-time task. Ad networks occasionally change their seller domains or account formats. A quarterly audit is a good practice. Check each line against your current ad network dashboards, and remove any seller you no longer work with. If you sold your app or transferred ownership, update the file immediately to prevent the new owner from being locked out of their own supply.
Also, keep an eye on your ad network's reporting for "unauthorized" or "unverified" impressions. A sudden spike in those metrics is a red flag that your file is broken or that someone is spoofing your app's inventory. Investigate promptly.
What About Mediation and Header Bidding?
Mediation platforms like AdMob Mediation or MAX often act as resellers. In that case, you must list them as RESELLER in your file, along with their seller ID. If you use a custom in-app bidding setup, each bidder must be listed. The key is to match exactly what your ad stack expects. A mismatch between your file and your mediation configuration can cause demand loss.
When using multiple mediation partners, it is wise to keep a spreadsheet that maps each network to its seller ID and relationship type. This becomes your single source of truth when troubleshooting or onboarding a new partner.
Final Practical Step for Your Next Sprint
Before you close this article, do one thing: open your ad network dashboard and find your seller ID. Write it down. Then, check if you already have an app-ads.txt file hosted on your domain. If not, create a simple file with that one line and upload it. That single action can restore bid density and reduce fraud risk within hours. Then, add a recurring reminder to your calendar to audit the file every quarter — because in ad monetization, small technical details are where the real money is made or lost.
