AdTech Matters – Identity proposals, Safari’s Private Click Measurement and ads.txt & app-ads.txt update for CTV

Every fortnight or so we’ll bring you some technical updates that we feel you’ll find useful.

Today’s topics are the identity proposals we’re seeing submitted to Project Rearc, Safari’s Private Click Measurement efforts and a closer look at the ads.txt & app-ads.txt updates for CTV.

Proposals into Project Rearc

We are now seeing various proposals feeding into Project Rearc to help facilitate the building and testing of the resulting frameworks of standards to come.

Largely these are falling into 3 areas:

• Authenticated Consumers: Highlighting the importance of first-party data strategies, a variety of proposals have been received for Universal ID frameworks, most commonly built from consumer-provided, hashed and encrypted email addresses. Approved and trusted 3rd-parties can execute on behalf of trusted first parties, without enabling unauthorised third-party tracking and/or data collection. For long-term feasibility, any standardised ID solutions will have to be coupled with relevant global tech standards (taxonomies, processes and data transparency), policy discussions, related privacy frameworks and cross-stakeholder industry alignment efforts. Any and all consumer messaging, policies, disclosures and controls must have agreed consistent minimum standards from a global technical perspective – with some localised cultural flexibilities in terms of language, implementation and oversights.

• Anonymous Consumers: Highlighting the increasing importance of contextual, these fully anonymised proposals function by only enabling the passing of content-based and contextual attributes, underpinned by standardised taxonomies, and without any user IDs. This area is fast becoming a driver for innovation in ad technology and is very safe as a general approach for any consumer privacy related concerns.

• Anonymous to all except Publisher/Marketer: A series of proposals are also being received which allow for publishers and marketers to manage and ultimately match consensual users into predetermined interest groups, or cohorts, but without the use of any trackable user IDs. Thereafter there have been a number of different proposals and iterations related to where these data sets will physically reside, whether the data can continue to successfully and safely feed into any machine-learning decisioning and modelling, and where the advertising auctions could physically take place. Many of the earlier suggestions (including Google’s Privacy Sandbox) proposed that these would all be in-device/browser and the more recent are suggesting they be hosted directly by certified publishers or else hosted by trusted and/or benevolent independent third-parties. The acronyms of the majority of these proposals and iterations have mysteriously taken-on a bird theme.

At the philosophical core of all of these proposals, alongside the various mechanical puzzles, are the core topics that have persistently challenged us all – transparency and trust. This is an obligation both internally between everyone involved as well as externally with consumers, legislators and all the affiliated commercial participants across both the buy and sell sides.

For more information on these submissions keep across any updates from us at IAB Australia and read this article on ExchangeWire published just after Xmas. It’s advisable to prioritise your first-party-data capabilities & strategy and keep across the latest trends in contextual targeting. The Data council will be releasing a dedicated Contextual Targeting Handbook in the first half of 2021.

Safari’s Private Click Measurement

Apple continue to push consumer privacy as a key topic for their products and solutions. Last year a proposal was announced to anonymise click data in Safari by reporting back any ad click and conversion data, without identifying the users involved. This will limit how much data the publishers and retailers can access directly and is called Private Click Measurement. The two most recently released previews of the Safari browser introduce this feature, so we can expect the release into Safari sometime very soon.

There are three stages to this process:

• Storing the ad clicks – this is done by the page hosting the ad at the time of a click.
• Matching conversions against the stored clicks – this is done on the website the ad navigated to as a result of the click. Conversions do not have to happen right after a click and do not have to happen on the specific landing page, just the same website.
• Sending out ad click attribution data – this is done by the browser after a conversion matches with an ad click.

Worth noting that the most recent preview release does enable developers to disable PCM if they do not wish their applications to utilise this capability. Apple delaying the ad click and conversion reports by 48hrs will result in advertisers losing any real-time insights into who buys what and when – and the option of buyers easily accessing cross-site cookie pools comprised of active clickers for certain products types in Safari will be no more.

The updates are currently only available in the previews, so keep up-to-date on the latest versions of Safari (there are two, one for Desktop/Laptop computers running macOS and one for Mobile Devices running iOS) regularly visit this page. For more detailed information on this read this blog piece from Apple’s John Wilander and be prepared to test the impact once it’s live.

Recent updates to ads.txt & app-ads.txt

As per a report we published before Xmas, CTV in Australia has recently been a genuine success story from both a consumer engagement perspective and also the resulting video ad spend. So it’s very positive to now see IAB Tech Lab have rolled out an updated version of ads.txt and app-ads.txt for the CTV environment, to help ease any ongoing concerns about fraud and transparency.

The intention is to support CTV / OTT apps in which multiple entities may have ownership rights over ad slots, commonly referred to as ‘inventory sharing’, by including the ability to designate another domain as a trusted partner, and validate the sellers upon a bid request from that partner.

See below for some more detailed guidance for publishers & programmatic vendors.

Publisher Guidance:

Before publishers can adopt app-ads.txt for CTV inventory, they need to adopt the OTT/CTV Store Assigned App Identification Guidelines. Per these guidelines, publishers are required to:

• Pass CTV app store assigned IDs in the app.bundle field of OpenRTB 2.5 or the app.storeid field of OpenRTB 3.0/AdCOM 1.0.
• Pass the store URL of the originating app in app.storeurl field of OpenRTB 2.5 and OpenRTB 3.0/AdCOM 1.0.

App owners should publish their app-ads.txt file on their developer web site, following the app-ads.txt standard. If publishers have already published the app-ads.txt for mobile app inventory, and there are different authorized seller IDs for their CTV app, they should publish a CTV specific app-ads.txt file at a new domain specific for CTV app inventory.

In addition, App Owners should declare within their app-ads.txt file the domain of Inventory Partners who own inventory within the App Owner’s app using the inventorypartnerdomain directive. This should be the domain where the Inventory Partner hosts their ads.txt or appads.txt file. If an app owner would prefer to list inventory partners seller & reseller IDs directly within the app-ads.txt file, rather than leveraging the inventorypartnerdomain directive, this is also supported. Guidance for app publishers passing additional information in bundle fields It has been observed that many CTV app publishers are passing additional information in the bundle ID that may be “lost” as part of this transition. Below is guidance on where this information is more appropriately passed:

1. Channel or Network within an app: content.producer.name
2. VOD vs. Livestream: pass in content.livestream
3. Device make/model: pass in device.make & device.model
4. App store: pass in app.storeurl – (Note: this is already required per the app-ads.txt standard)

SSP/Exchange Guidance:

• SSPs/Exchanges are required to implement the app.ext.inventorypartnerdomain & site.ext.inventorypartnerdomain extensions to support the passing of inventory partner domains for pointers to partner ads.txt files, where an inventory partner exists.
• SSPs/Exchanges should support publishers in providing CTV App IDs according to the OTT/CTV Store Assigned App Identification Guidelines* as well as assist them in passing additional contextual & environment signals (as noted in Publisher Guidance section) via the appropriate existing or extension OpenRTB fields. Failure to comply with the guidelines will prevent the DSP from verifying the app-ads.txt information.

DSP Guidance:

• • DSPs should implement their app-ads.txt crawler according to standardized guidance from CTV app stores (or use a service that adheres to those guidelines).
  • DSPs should implement support for app.ext.inventorypartnerdomain & site.ext.inventorypartnerdomain extensions and check the seller ids in the (app)ads.txt files based on those attributes.

For more information on this standard and the updates please click here