Well, sort of.

In case you missed it, Google Chrome and the Privacy Sandbox team posted an update today (July 22nd), proposing a different approach to user choice “instead of deprecating third-party cookies”.

So that’s it folks. We can forget the Privacy Sandbox, turn off the alternative ID solutions, and shred those first-party data strategies… because the cookie lives on! 

The reality is something quite different. The outlook for the future isn’t changing, the path to get there just may be a little smoother without a drop-dead date for the cookie and the chaos that may have caused.

See, the problem all along has been about user choice and respecting privacy rights. That’s still in view here, as Chrome is going to be making it easier for users to make informed choices and opt out of cookie-based targeting – an approach some of us at Freestar have argued would have been a better starting point years ago. And there’s a reason Chrome isn’t ditching the Privacy Sandbox, as they still see the need for “privacy-preserving alternatives”.

The relative market coverage of third-party cookies will only continue to decline over time. Privacy regulations continue to come in focus across the globe, where user choice can already prevent the use of third-party cookies. I haven’t seen any announcement about Safari bringing back cookies, have you? We’re also bringing up a generation that is more tech-savvy than ever and capable of ensuring their rights are respected in a technical arena. And that doesn’t even get into the shortcomings of the third-party cookie itself as it doesn’t solve for cross-device identity.

We’ve already posted about the huge opportunity that exists now in cookie-challenged environments, where publishers can recover significant revenue by improving the accessibility and addressability of this inventory for buyers.

So the industry MUST continue to progress on developing privacy-friendly advertising solutions that will operate in the absence of third-party cookies. Otherwise, advertisers will be competing with a shrinking subset of users in Chrome and missing out on the positive outcomes that premium audiences in cookieless environments and emerging channels can deliver.

Freestar will continue to invest in solutions that respect user privacy preferences and drive value for publishers and advertisers across all browsers – with or without cookies. We will still lead innovation across our strategic pillars: Supporting first-party data, testing alternative identity solutions, and advocating for publishers in industry working groups.

The post The Cookie Lives On… Sort Of first appeared on Freestar.

The IAB Tech Lab developed standards to address these concerns. Ads.txt was introduced in 2017 (and updated in 2022), with companion specs for Sellers.json and SupplyChain released in 2019. Together, these solutions help provide both publishers and buyers with far greater transparency and control over the entities involved in facilitating programmatic advertising transactions.

Ads.txt FAQs

1. What is the purpose of an ads.txt file?

The “Authorized digital sellers” (ads.txt) specification was created to improve transparency in the digital advertising ecosystem. It publicly lists who publishers have authorized to sell their inventory. 

The purpose of ads.txt is to limit ad fraud, which has been estimated to cost the ad industry billions of dollars annually. This type of fraud exists in a variety of ways, but the most common is domain spoofing. Domain spoofing can occur when someone other than the publisher maliciously takes control of the ad units on the page, or intentionally misrepresents inventory by substituting information provided to buyers in bid requests. The ads.txt initiative seeks to quickly identify fake sellers.

2. Where can I find my ads.txt file?

Put your domain into a browser, and at the very end add /ads.txt, e.g. domain.com/ads.txt.

For mobile apps, the ads.txt file needs to be hosted on your developer URL with /app-ads.txt appended, e.g. mobileapp.com/app-ads.txt.

3. I see a bunch of ad tech vendors, like Undertone and Triplelift, does that mean they’re purchasing my ads?

Advertisers are still the ones purchasing the inventory at the end of the day, but vendors listed in your ads.txt file are the SSPs or exchanges that are allowed to sell or resell your ad inventory. 

4. How does an ads.txt file impact my overall revenue?

Demand Side Platforms (DSPs) are validating that SSP accounts have been authorized by you in your ads.txt file before they will transact on your inventory. Without an accurate, up-to-date ads.txt file, buyers will not participate and SSPs will be severely limited or unable to generate revenue for you.

5. Is a longer ads.txt file indicative of a more optimized ad stack?

Not necessarily, and in some cases, it may even mean the opposite. If multiple SSPs are reselling inventory, there may be unnecessary intermediaries taking a cut of the advertiser’s spend, leaving a smaller slice of the pie for you, the publisher.

On the other hand, a longer ads.txt file could just be a result of finding the right mix of SSPs and exchanges that can provide value for unique segments of your inventory, such as video, native, or AMP ads.

6. How do I update my ads.txt file?

If you are maintaining your own ads.txt file, work with your direct partners and vendors to be sure you are including the relevant ads.txt lines for your site, and publish changes to the file hosted on your domain.

Or if you work with a partner like Freestar, you could set up a redirect with your domain hosting provider to point your domain’s ads.txt to a file that is dynamically updated and managed by Freestar on your behalf, while still including information that is specific to your company and site.

7. How often should I update my ads.txt file? What does the “last updated” comment mean in Freestar’s dynamic ads.txt?

Your ads.txt file should be updated whenever you add or remove monetization partners for your property. 

Freestar’s solution for hosting your ads.txt file includes a “last updated date”, to let you know when we have made changes on our end. If you are already integrated with Freestar’s dynamic ads.txt, these changes will be automatically pushed out to your file.

Keeping your ads.txt file up to date will ensure you don’t miss out on any revenue from new monetization partners and opportunities!

8. What is the meaning of the “#” character in an ads.txt file?

Any information that follows a “#” character in the same line of an ads.txt file is to be treated as a comment only, and not meant to be consumed by data crawlers.

These comments can be useful for keeping your ads.txt file organized, for example, by grouping multiple lines together by specific partners or integration types.

9. What does the “ownerdomain” line mean and who should be listed there?

This field is new in the ads.txt 1.1 specification released by the IAB this year (2022). The ownerdomain specifies the business domain of whoever owns the site and is displaying the ads.txt file.

This may just be the website domain if you own and operate a single site, but if you have multiple sites or are under a parent media company, you’ll need to use your corporate or flagship domain. For example, in the ads.txt file of espn.com, the ownerdomain is disney.com.

10. What does the “managerdomain” line mean, and why is it Freestar?

Another new addition in the ads.txt 1.1 specification, the managerdomain field is to list the primary monetization partner of the publisher’s ad inventory. This field isn’t mandatory and should be used only when relevant.

Declaring Freestar as your partner here is like a stamp of approval, so buyers can confidently transact on your inventory through our technology and know that we’re making it available to them on your behalf.

11. Do the new fields in ads.txt 1.1 also apply to app-ads.txt?

Yes, the IAB’s specification indicates that the new ownerdomain and managerdomain fields are also applicable to app-ads.txt for declaring inventory ownership and monetization partnerships for app inventory.

12. Why should I keep my ads.txt lines to only the partners I am working with?

One of the primary purposes of ads.txt is to authorize the SSPs and exchanges that are permitted to sell or resell your ad inventory, and to make it difficult for shady partners to fraudulently profit from the value of your brand. The best way to do this is to understand and approve what each vendor line in your ads.txt file represents.

Buyers are looking to mitigate complexity and find supply paths that are most efficient for them (Supply Path Optimization), but managing your ads.txt file effectively is critical to ensuring available pathways are the ones that provide the most benefit for you too (Demand Path Optimization).

You may work with a partner that asks you to add multiple lines for them, and in some cases, this may be legitimate. For example, by partnering with Freestar, you may be trusting us to make recommendations about the SSPs and exchanges that can help you monetize across multiple channels and ad formats (We even offer to host your ads.txt file for you, so we can include the necessary ads.txt lines for the partnerships we manage on your behalf). However, it’s ok to ask questions to ascertain the value of any vendor that you’re asked to authorize, and if someone you’re not partnered with asks you to include something in your file for them, chances are you shouldn’t do it.

13. What is a reseller ID?

Each vendor line in an ads.txt file contains 3 required fields:

1. The domain name of the advertising system
2. The account ID within that advertising system through which the publisher’s inventory will be transacted on
3. The type of account relationship, signifying whether the publisher directly controls the account specified in the 2nd field, or has otherwise authorized another entity to control it as a reseller

The intention of the third field is to differentiate between an account that provides direct access to the publisher’s inventory and an account that accesses the same inventory through an additional “hop” or intermediary in the flow of payments.

For example, if SSP A was a direct partner of a publisher, the publisher would authorize their account ID with SSP A as direct:

sspA.com, 123, DIRECT

However, if SSP A also forwarded or resold requests to SSP B, the publisher may authorize SSP A’s account ID with SSP B as a reseller:

sspB.com, 456, RESELLER

14. How does ads.txt work alongside sellers.json and schain?

The IAB improved upon the transparency that ads.txt offered by introducing companion specifications for sellers (SSPs/exchanges) to declare their accounts in a json format (Sellers.json), and pass details about the sourcing of the inventory in their requests to buyers (SupplyChain). These specifications work alongside ads.txt to ensure only valid inventory passes through the ecosystem.

For example, if “Example Publisher” has an account ID of “123” with  “SSP A”:

1. The ads.txt file for “Example Publisher” should include:

ownerdomain=examplepublisher.com
SSP A, 123, DIRECT

2. The sellers.json file for “SSP A” should include:

"seller_id": "123",
"name": "Example Publisher",
"domain": "examplepublisher.com",
"seller_type": "PUBLISHER"

3. The schain (SupplyChain) for a bid request from “SSP A” to upstream buyers should include:

"asi":"sspA.com",
"sid":"123",
"hp":1

When all 3 of the above components align, the transaction is considered authorized and valid. Otherwise, buyers should reject the request as unauthorized.

Conclusion

To maximize your display revenue, we recommend keeping your ads.txt file up to date at all times. Finding a trusted monetization partner who is constantly optimizing on your behalf is one of the best things you can do for your business.

If you have questions on monetization with Freestar, please contact marketing@freestar.com.

The post Everything You Should Be Asking About Ads.txt first appeared on Freestar.