Last active
August 8, 2019 06:37
-
-
Save perry-mitchell/1e9a1ef6bd54b7eb8a7a32878583a04c to your computer and use it in GitHub Desktop.
RFC: Ads.txt chaining
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # Sample publisher ads.txt | |
| somenetwork.com, 1234, DIRECT | |
| another.org, 4455abc, RESELLER | |
| # !include https://managednetwork.com/managed.ads.txt.php?id=123 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # Included ads.txt from initial site | |
| advertiser.com, 9999, RESELLER | |
| network.co.uk, 123400, RESELLER |
If you replace $include with #include like this:
#include https://managednetwork.com/managed.ads.txt.php?id=123
it would help to gradually start using this feature without breaking old ads.txt scrapers - they would ignore this line as a comment.
@dec5e Good point! Graceful fallback. It'd still fail of course as the new lines wouldn't be read on older fetchers, but at least parsing wouldn't fail. The only problem with that approach is that regular comments could include the "include" word as part of a regular comment, and then fail. Eg:
# My ads.txt
#
# This ads.txt was generated by some bot, and it should
# include the correct amount of lines
So for cases like that it'd be tricky. Maybe best to still have it prefixed inside the comment?
# My ads.txt
somenetwork.com, 1234, RESELLER
# !include https://site.com/ads.txt
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Justification
Chaining
ads.txtfiles would make managing large amounts of clients much easier, as it's currently very impractical to continually request ads.txt updates from all of our clients. Growing companies such as ours that are regularly adding new network partners face the challenge of reaching out to all of our publishers to get new lines in.Chained
ads.txtfiles would allow us to manage the lines relevant to our partnership for the client. The security behind this is definitely debatable as the publisher is usually in a position of having to trust, somewhat blindly, that the reselling partner is working with honest networks for the selling of their inventory. Chainedads.txtfiles are no different apart from the fact that the reseller can update the lines without the acknowledgement of the publisher. As trust has been passed to the reseller in the management of some portion of the publisher's inventory, the risk of having the lines updated without explicit approval is negligible.Functionality
Through an include statement of some kind, the lines from a remote
ads.txtfile could be requested and included in the processing of the original site. The format of the remoteads.txtfile would of course follow the existing ads.txt specification.The actual syntax isn't important, and the$prefix was simply to denote an instruction, rather than another demand line or comment.The include statement is contained within a comment so that older parsers/fetchers don't break on the statement (thanks @dec5e). The prefix to the include statement,
!, is arbitrary and simply there to denote an instruction rather than a normal comment. A friendly parser might try to only recognise the following pattern, for instance (per-line):Chaining would have to work in a way that many
ads.txtinclude statements could be followed, as networks may utilise the same method of linking. Adsads.txtare handed in an offline manner, in terms of the selling process, it shouldn't matter how many links there are in a chain.