Buyers
How buyers verify mobile app supply
By Stoqlab Research · Updated · 6 min read
A DSP receiving an in-app bid request has a few milliseconds to decide whether the impression is what it claims to be. The checks it can run against public data are well defined. This guide walks through them in the order the data connects, and is plain about what each one proves.
1. What the request claims
An in-app OpenRTB request carries, among other things:
app.bundle: the app's bundle ID or store ID;app.storeurl: the store listing URL, which the IAB Tech Lab app-ads.txt specification asks sellers to send;app.publisher.id: the seller account on the ad system that sent the request;source.schain: the SupplyChain object, every seller that handled the request.
2. Store listing → developer website
The verifier maps the store and bundle ID to the developer website in the listing, which is where the app-ads.txt lives. The specification asks verifiers to key this on store + bundle or store ID (not the full store URL, which has many variants) and to refresh it no more than weekly. If the app is not in the store any more, or the listing has no website, the chain of trust stops here.
3. Is the seller authorised?
The app's app-ads.txt must contain a line with the request's ad system domain and account ID. No line, no authorisation. This one check is what defeats simple spoofing, where someone sells impressions under a popular app's bundle ID through their own account.
4. Who is the seller?
The account is looked up in the ad system's sellers.json: is it listed, is it a PUBLISHER or an INTERMEDIARY, does the type fit DIRECT or RESELLER in the file, and does a PUBLISHER's domain match the app's developer domain or OWNERDOMAIN? A confidential entry passes the first test and tells nothing about the rest.
5. The whole path
Each node of the schain is checked the same way: listed in its system's sellers.json, and (after the first node) authorised as a RESELLER in the app's file. A complete chain whose first node is the app owner's DIRECT account, with few hops, is what supply path optimization looks for. Incomplete chains, unknown nodes and long reseller chains are where buyers cut.
6. What changes over time
Files change. A partner closes an account, a publisher drops a reseller, an app is removed from the store but its file stays online. Checks against a snapshot weeks old miss all of that, so verifiers re-crawl and keep history. Stoqlab re-reads files on the schedule described in the methodology and keeps every version.
What none of this proves
- That the traffic is human. Authorised inventory still needs invalid-traffic screening.
- That the impression was rendered where claimed. That needs measurement in the app.
- That a seller did not rewrite an account ID. The specifications name this limitation themselves.
Public files settle authorisation and identity. Combined with history, they are also the cheapest early warning when a path changes. For a hands-on walk-through of one app, read How to read a supply path, or look up any account with the seller ID lookup.