The state of advertising technology is bad. Many publishers struggle with its effects on page speed and find themselves dealing with fraud and hijacks. Readers are more aware of bad ads in the aftermath of the 2016 election. As a result a critical transformation is underway. GDPR and California consumer laws mean user privacy concerns are changing how user data is stored and how sites operate. New methods for building ads into media are on the rise. Publishers have an opportunity now to be involved and even lead the fundamental transformation of ad tech. We wanted to work together at SRCCON on an important component of that evolution.

We have been working on a schema to drive this change internally at the Washington Post, but we know if we hope to have it used and supported by other news organizations, we need it work outside the Post. SRCCON was a great place to workshop our schema and open it to feedback from a variety of stakeholders. Where else could we find a group of eager, smart journalist-, product- and developer-types from diverse backgrounds and newsrooms who were willing to question our ideas?

Problem

We want our ad services to interface with inventory and tools from other publishers. Dynamic Ad Insertion is a server-to-server back-end process to build ads inside media before they are displayed or played by a user, instead of rendering on the front-end after a page or piece of media has loaded. Systems built on DAI do not yet have a methodology locked in to the marketplace, which means there is an opportunity for a publisher-led standard.

To fulfill these needs, a consistent language is necessary between services to handle server-to-server ad operations—a structured data format for content management systems and advertising services to share would allow processes to easily deconstruct advertising content and reconstruct it in different ways, and in different contexts. With that flexibility we could be agile and fast in how and where we apply ads.

XKCD #927 used under Creative Commons

Structure and Initial Planning

Like all of the projects that the Washington Post’s RED team works on, the schema came out of collaboration. Once we knew what we needed to move forward we collaborated with the engineers who worked on our CMS’s schema, ad operations, and sales to determine how we could describe data for the operations we’d have to complete.

At the core of the schema is the ad object, which contains the data to describe a set of ad-creative objects, the type of templates the ads are targeted to, the advertising campaign the ad is attached to, and identifiers for connections to an external ad server. The campaign object contains a number of properties for the targeting object, which contains metadata for excluding ads from pages and what keywords ads might target for placement. The campaign object also contains the product object which describes components of editorial content, like sections or shows, for placement.

Approach

We wanted to present the schema to SRCCON participants in a way that wouldn’t cause most people’s eyes to glaze over. We broke out each trait to a single slide and elaborated on the definitions behind each piece. The session participants—a mix of digital journalists, programmers and product owners—grasped the concepts we were trying to define, and they asked plenty of questions about our logic.

The Targeting property broken down in a slide, portrayed with its position in an ad object and its major properties for discussion.

An example of the Targeting property that was presented in more detail for SRCCON participants to review.

A Few Great Ideas

The meatiest portion of our SRCCON session was when we dove into the ad schema itself and poked at the reasoning behind its properties.

Our schema accurately represented the ad types that our organization typically serves, but we hadn’t considered some of the newer renderings such as 360 ads. We’ve added this type of asset to the schema.

Ariane Bernard, an Arc partner from Le Parisien, mentioned that content adjacency is a struggle in her newsroom. The ad needs to somehow be aware of the content around it and know that it cannot render near certain types of material. We believe we have covered this case in the targeting JSON using the slot and keywords properties, but it is a fair note for implementation on the front end. We also learned that The Atlantic has a kill switch in its CMS that prevents ads from appearing next to sensitive content. Turning ads off rests with the editorial team in this case, whereas at the Post, that control means a call to the Ad Operations team. Again, turning the ad off would be part of the front-end logic, and the fact that the ad was not rendered would also need to be represented in the schema. We will add exclusions to the schema as a separate trait for use on multiple objects.

One interesting suggestion we have incorporated is the idea of a numerical scale for brand safety. We decided to create an optional scaled value of 1 to 10, with 1 corresponding to content on which ads are never allowed, that is part of the keyword property. Each keyword can have a corresponding scaled value. This captures the amount of weight to give to the exclusion by keyword. The value will also be applied at the campaign level, and we see publishers using it primarily for programmatic ad targeting.

We received excellent feedback around how ad creatives operate on the page as well. While we’d previously approached placement on standard general targeting levels like product and date, one of the responses noted that we had not considered ordering within a page. We plan to push forward with incorporating that into the ‘creative’ property. We also heard a need for more explicit methods for incorporating tracking pixels that we’re considering how to implement.

Developers in the room voiced a desire for more automated tools; this included scripts needed for unit testing a schema as valid. The other tool requested—something we hadn’t expected—was mock services, to see how schema statements would be received, processed, and returned by potential services using the standard. This was great feedback for helping adoption of the standard that we otherwise wouldn’t have considered. We plan to take immediate action on one other piece of feedback from Condé Nast’s Blaine Cook, which is to consider how and where we can incorporate terms from the increasingly widely adopted Schema.org standard properties and objects.

After SRCCON

We were not planning to form full consensus on a standard during a single SRCCON session because building one takes time and cycles of responses, but we were able to add several traits that weren’t in our first iteration and hear useful input on elements of the structure. Presenting the schema in our SRCCON session was a good exercise for gathering feedback. The conversations with other publishers have extended past SRCCON, as we’ve continued to ask for and act on alterations and new ideas.

The Post continues to build out new ad formats and a robust infrastructure needed to support a scalable, publisher-led schema. Our internal advertising CMS will use this schema to work with ad units on the site, and we hope to have a production-ready version of the schema by the beginning of 2019. We are actively iterating on the schema and seeking collaboration from other publishers. To contribute to the schema, submit a pull request to https://wapo.st/adschema.

• Share on Twitter
• Share on Facebook