app-ads.txt on Amazon, Samsung and Huawei Stores

Publishing the same Android app on more than one store is common, and so is forgetting about app-ads.txt on the extra listings. Each store has its own listing and its own developer details, and buyers who see traffic from that store check against whatever website that listing names.

The good news is that the mechanics barely change. If your file already works for Google Play, most of the work is done. The parts that differ are where each store keeps the developer website, how quickly listing changes go live, and whether your ad network can link an app to that store at all.

Store consoles change often and the smaller stores document app-ads.txt less thoroughly than Google and Apple do. Where this guide describes a console, treat it as a pointer and confirm the current fields in the store's own documentation.

The principle that applies everywhere

Every store works on the same idea set out in the IAB Tech Lab specification on the ads.txt page. The public store listing names a developer website. A crawler takes the host from that website, requests /app-ads.txt from its root and stores the list of authorised sellers. When a bid request arrives for an app from that store, buyers check the seller against the list.

So for any store, three things have to line up:

1. The public listing shows a developer website on a domain you control.
2. That domain serves a valid app-ads.txt file at its root.
3. The file contains the right line for every network selling that app's inventory.

If you hold on to that chain, you can work out any store's setup even when its console has changed.

What is the same as Google Play, and what differs

The last row matters most. AdMob and many mediation platforms verify app-ads.txt against a store listing they know about. If your network cannot link an app to a given store, it may not show a verification status for that listing, even though buyers can still read your file. The AdMob help centre lists the stores AdMob currently supports for linking.

Amazon Appstore checklist

Amazon listings are managed in the Amazon Developer Console, reached from the Amazon developer site. Developer details shown to customers come from your account and app listing settings.

• Find where your developer or company website is set, and confirm it is your own domain.
• Check the public listing in a browser to make sure the website appears as you expect.
• If you reuse your Play build, confirm which networks in it actually serve on Amazon devices.
• Add every serving network's lines to the shared file.
• After any change, recheck the live listing once it has been processed.

Amazon has narrowed where its Appstore is offered in recent years, with the focus on its own Fire devices. Check that your listing still reaches the devices you are monetising before you spend time on the setup.

Samsung Galaxy Store checklist

Samsung listings are managed in the Galaxy Store Seller Portal, which you reach from Samsung's seller site. Your seller profile and app information hold the contact details shown on the listing.

• Find the website field in your seller or app information and set it to your own root domain.
• Confirm the public Galaxy Store page shows that website.
• Note whether editing listing details triggers a new review, so you can plan timing.
• Check whether each network in your stack supports Galaxy Store traffic and add its lines.
• Recheck the file and listing after any update.

Huawei AppGallery checklist

Huawei listings are managed in AppGallery Connect, through the Huawei developer site. The developer information on your account and app listing is what customers and crawlers see.

• Locate the developer website field and point it at your own domain.
• Confirm the live AppGallery page shows that website.
• Check which ad networks can serve on the devices you target. Google's mobile ad SDKs depend on Google Play services, which many recent Huawei phones do not have, so your stack may differ from your Play build.
• If you use Huawei's own ad platform or another network for these users, add whatever lines it asks for.
• Recheck after each listing update.

Because the networks serving on Huawei devices may differ, it is worth comparing their benchmarks before you commit. In our tables, InMobi's Tier 3 rewarded eCPM is about $1.50 against AdMob's $1.40, while AdMob leads in Tier 1 at $12.00 against $9.00. The InMobi guide covers when that kind of regional strength pays off.

Using one file for every store

The simplest structure for a multi-store app is a single website and a single file. Point every store listing at the same domain, and keep one app-ads.txt that includes every network serving any of your listings.

That file might then hold:

• Your AdMob line, used on Play and possibly elsewhere.
• Lines for each mediation partner, as published by your mediation platform.
• Lines for any store-specific network you added for a particular audience.

Buyers only check the lines relevant to the seller in front of them, so extra lines for a network that only serves on one store do no harm. Label each block with a # comment so you remember why it is there. Our mediation guide explains how adding partners changes your auction.

Timing and testing

Each store reviews listing changes at its own pace, and every buyer's crawler runs on its own schedule. Allow several days for a change to settle across all stores and buyers, rather than expecting overnight results.

To test, open each public listing, follow the website link, then load /app-ads.txt on that domain in a private browser window. If any step fails, fix that link in the chain before anything else.

Is it worth the effort?

For many apps, the extra stores are a small share of installs. Even so, the setup is a one-off, and an unverified listing can lose buyers on every impression it serves. Model a modest extra audience in the home calculator or the AdMob revenue calculator, and check the mobile eCPM benchmarks for the regions those stores serve. The full setup for the main stores is in app-ads.txt for Google Play and app-ads.txt for the Apple App Store, and our methodology explains where the benchmark figures come from.