What belongs in your app-ads.txt

What belongs in your app-ads.txt

Two small lines might cost you revenue

In “How to read app-ads.txt in mobile advertising,” we covered the fundamental seller lines that make up most of your app-ads.txt file. When you manage multiple partners, it can be hard to know what to keep and what to remove. In fact, two short lines in your file could be costing you demand you never see: MANAGERDOMAIN and INVENTORYPARTNERDOMAIN. Learn why these lines might get flagged by a supply partner and what you should do about it.

What are these and why are they in my app-ads.txt file?

First things first: both MANAGERDOMAIN and INVENTORYPARTNERDOMAIN are legitimate parts of the IAB Tech Lab spec. MANAGERDOMAIN names the company that runs monetization for you when you don’t sell your own inventory, and INVENTORYPARTNERDOMAIN, or IPD, is for apps that show ad inventory owned by another company. Neither is a problem on its own, but both are being copied into files where they don’t belong, and buyers and SSPs are starting to treat that as a quality problem.

MANAGERDOMAIN: one manager per market

MANAGERDOMAIN is an optional line in the spec and is only suggested for use when it’s relevant, for a primary or exclusive monetization partner, such as a sales house. The rule that matters most when using this line is the count. You can declare one global manager and override it for specific countries, but you can’t have more than one manager per country.  

A valid file looks like this:
MANAGERDOMAIN=salespartner.com
MANAGERDOMAIN=frenchpartner.com,
FR

An invalid one looks like this:
‍MANAGERDOMAIN=networkone.com
MANAGERDOMAIN=networktwo.com
MANAGERDOMAIN=networkthree.com

If you sell your own inventory through several partners, which is how most app developers work, you probably don’t need a MANAGERDOMAIN line at all. Declaring a manager is a business decision, not a formality. It hands one partner control over how buyers see your inventory, so don’t add one just because a partner’s integration block includes it.‍

INVENTORYPARTNERDOMAIN: for content you don’t own

If you own your content, IPD is almost certainly unnecessary for you to use. Typical use cases include publishers like streaming apps that license shows from a content partner and then let that partner sell ads inside them. The IPD line in this instance points buyers to the partner’s ads.txt file so they can check who is allowed to sell that inventory. 

But this only works when the partner’s domain is also passed in the bid request. If your app shows your own content, as most publishers do, you likely have no inventory partner. Including an IPD line in that file doesn’t authorize anything. It simply tells buyers your file wasn’t written for your app. 

That said, if you license content from a partner who sells ads in it, you’ll want to keep this line for that partner and remove the rest.

If you publish both CTV and mobile apps, consider listing them under separate developer domains, so each app-ads.txt only carries the lines it needs.

How did they end up in your app-ads.txt file?

The likely culprit is a simple copy and paste. When integrating a new partner, publishers often receive a block of text to add to their app-ads.txt files. Some of these lines may include the partner’s own MANAGERDOMAIN or IPD line alongside its seller lines, and if you’ve got three partners that do this, your file might declare three managers.

Nothing breaks when they’re added, and because everything seems to be in working order, it’s not often they get checked, so the file grows with every new integration. In the app-ads.txt files our crawler read on Oct. 18, we found 267 different MANAGERDOMAIN values and 725 different IPD values. Hundreds of files declare more than one manager.

This might cost you demand

Buyers check your app-ads.txt files before they bid, and they read these declarations as well. A file with several managers can’t be true, as it indicates several companies each control your inventory in the same market. Quality teams are starting to read that as a sign that your app-ads.txt file isn’t maintained, or that someone is claiming a relationship with you they don’t have.

Guidance by The Trade Desk states this rule directly: one ManagerDomain per file per geolocation, as the IAB spec says. Some SSPs are tightening their own checks. This means whenever a buyer or SSP stops trusting a file, the cost lands on every partner selling that app’s inventory, not just one. 

The cost isn’t only about files that break the rules. Even one MANAGERDOMAIN line tells buyers that a single company controls your inventory, so buyers may favor that network and treat every other partner as a secondary route, even though their seller lines are still valid. You won’t see that as a drop in a report. You’ll see it as spend you never received. Removing the extra lines doesn’t touch your seller lines, so every partner you’ve authorized keeps competing for your inventory on equal terms.

Step-by-step actions to take now

If you’re concerned that this may be impacting you, here’s what you should do:

  1. Open the app-ads.txt file on the developer domain listed on your app store page.
  2. Search for MANAGERDOMAIN. If you sell your own inventory, delete every line. Keep one only if you’ve chosen a single company as your exclusive monetization partner, plus one per country where a different company manages it.
  3. Search for INVENTORYPARTNERDOMAIN. If your app doesn’t show content owned and sold by a partner, delete every line.
  4. Leave every seller line (the ones that end in DIRECT or RESELLER) as it is.
  5. Next time a partner sends you lines to add, check them for these two declarations before you paste.

Your BidMachine account manager can work with you to review your file and confirm it’s clean after you update it. Reach out today to get started.