App-ads.txt Snippet
What App Developers and Publishers Need To Do
- Provide a domain in your app store metadata.
- Create a file called app-ads.txt listing all the monetization partners you work with and upload it to your domain.
- Then you will need to add the Smaato Exchange partners from the Smaato Snippet.
- That’s it! With the app store metadata pointing to your domain, interested parties can periodically crawl through your list of monetization partners to ensure they’re buying your inventory through trusted exchanges.
Smaato SPX Snippet Generator
App developers and publishers with an SPX account can use the App-ads.txt Snippet Generator to easily copy or download the .txt file from SPX.
How To Use The Snippet Generator
- First, log in to SPX.
- Then go to the dropdown menu located next to “User Account Email” in the top right of the dashboard.
- Select App-ads.txt Snippet from the menu
- From there you will find the Snippet Generator where you can copy or download the Smaato listed partner
- Then upload the Smaato list to your app-ads.txt file.
- And that’s it! Now you are ready to send requests and receive bids from your validated monetization partners in the Exchange.
The Background
Authorized Digital Sellers (ads.txt) is an initiative originated in 2017 by the IAB Tech Lab. This initiative increases transparency in the ecosystem of programmatic advertising by eliminating the chances of unauthorized buying and selling transactions. Authorized Digital Sellers for Apps (app-ads.txt) extends the ads.txt standard to support mobile apps distributed through online app stores. This is done by linking an ads.txt file with the app developer websites and posted to the app store listings.
Smaato supports the IAB Tech Lab initiative for ads.txt/app-ads.txt. For this, we are designing and implementing a snippet generator into our SPX platform to allow for easy adoption by our publishers. We currently working the release and will inform everyone shortly about this.
| FIELD | NAME | DESCRIPTION | EXAMPLE |
|---|---|---|---|
|
|
The domain name of the advertising system |
(Required) The canonical domain name of the SSP, exchange, header wrapper, et.c system that bidders connect to. This may be the operational domain of the system, if that is different than the parent corporate domain, to facilitate WHOIS and reverse IP lookups to establish clear ownership of the delegate system. Ideally, the SSP or Exchange publishes a document detailing what domain name to use. |
smaato.com |
|
|
Publisher’s Account ID |
(Required) The identifier associated with the seller or reseller accounts within the advertising system in field #1. This must contain the same value used in transactions (i.e. OpenRTB bid requests) in the field specified by the SSP/exchange. Typically, in OpenRTB, this is publisher.id. For OpenDirect it is typically the publisher’s organization ID. |
1100000000 |
|
|
Type of Account/Relationship |
(Required) An enumeration of the type of account. A value of ‘DIRECT’ indicates that the publisher (content owner) directly controls the account indicated in field #2 on the system in field #1. This tends to mean a direct business contract between the Publisher and the advertising system. A value of ‘RESELLER’ indicates that the Publisher has authorized another entity to control the account indicated in field #2 and resell their ad space via the system in field #1. Other types may be added in the future. Note that this field should be treated as case insensitive when interpreting the data. |
DIRECT or RESELLER |
|
|
Certification Authority ID |
(Optional) An ID that uniquely identifies the advertising system within a certification authority (this ID maps to the entity listed in field #1). A current certification authority is the Trustworthy Accountability Group (aka TAG), and the TAGID would be included here [11]. |
07bcf65f187117b |
App-Ads.txt Example
smaato.com, 1100027488, DIRECT, 07bcf65f187117b4
smaato.com, 1100004890, DIRECT, 07bcf65f187117b4
adcolony.com, 496220845654deec, RESELLER, 1ad675c9de6b5176
appnexus.com, 2764, RESELLER
appnexus.com, 8790, RESELLER, f5ab79cb980f11d1
...
Supported Documentation
|
IAB App-ads.txt Specifications (for Apps): https://iabtechlab.com/wp-content/uploads/2019/03/app-ads.txt-v1.0-final-.pdf IAB Ads.txt Specifications (for Web): |
App-ads.txt FAQ:
What if a publisher doesn’t add an (app-)ads.txt file to their domain?
Authorized seller verifiers (such as 42 matters) will not be able to apply crawlers to verify the publisher’s buyers or sellers in the exchange. As for demand platforms, they will not be able to verify that the offered impressions come from legitimate/authorized sources (SSP) and will most likely not continue spending on the app inventory of the publisher.
What if the Publisher adds an empty (app-)ads.txt file?
From the IAB: Some publishers may choose to not authorize any advertising system by publishing an empty ads.txt file, indicating that no advertising system is authorized to buy and sell ads on the website. For systems to properly read and interpret the empty file (differentiating between web servers returning error pages for the /ads.txt URL), at least one properly formatted line must be included which adheres to the format specification described above. For files that do not otherwise contain authorized advertising system records, use the following “placeholder” record to indicate that the file adheres to the ads.txt specification: placeholder.example.com, placeholder, DIRECT, placeholder
Last Modified: November 25, 2021 at 5:49 pm