This guide is part of a series of Programmatic Guides that IAB Tech Lab is providing to address the many technical components involved in executing programmatic ad campaigns. This guide focuses on the use cases involved in a programmatic campaign for connected TV (CTV). And since CTV often works with partners in server-side ad insertion (SSAI), special callouts highlight additional information where working with SSAI is concerned.

This guide is not all-inclusive; rather, it outlines a set of use cases and provides details that are relevant to each use case. Each use case is summarized in a Quick Start Overview and then later in the guide, covered in more detail. Links to additional resources and relevant Tech Lab standards for more details are included for each use case.

The goal of this document is to provide guidance for optimizing programmatic effectiveness in the supply chain for CTV campaigns using available resources developed by IAB Tech Lab and beyond. The guidance in this document addresses challenges faced in CTV with the following parties:

• Publisher or player app
• Ad server
• Server-side ad insertion (SSAI)
• Programmatic Platforms (DSP, SSP, exchanges)
• Measurement verification providers
• Content providers
• Other ad tech vendors offering services in CTV

Digital video continues to mature as a medium for advertising, while the connected television (CTV) market has only begun to leverage the programmatic ad technology initially developed for digital video. Programmatic CTV opens new opportunities for expanding reach into homes across screens and devices. Traditional television has lacked the level of functionality and insight that became the norm across web browsers and mobile apps. Now, with CTV and advances in technology and improvements to standards, the industry has seen increasing parity in capabilities between CTV and digital video. Some of the challenges in CTV, however, lie in delivery, addressability, measurement, and fraud.

This guide summarizes the best practices for using the most recent ad technologies for achieving the best results in CTV advertising. As a guide, it highlights key considerations and directs you to more in-depth information where needed. We’ve broken down the technical components of a CTV campaign into the following use cases:

• Delivery
• Targeting
• Measurement & Verification
• Interactivity
• Ad Fraud
• Brand Safety

These use cases are summarized at a high level in the following section, and then each use case is broken down into more details.

Audience

This guide is intended for individuals that work in the buying, selling, and development of video advertising in CTV. Ad tech professionals who work with publisher players, ad servers, ad creative developers, measurement & verification providers, as well as demand side platforms & exchanges, media buyers, ad trafficking and operations, partner integration/onboarding engineers and Product Development can all benefit from the guidance offered in this documentation. The content is somewhat technical as it references different specifications and guidance documentation, but anyone who works with systems that handle video ad transactions should find the details useful.

Background

The first television was introduced in 1928. It took until the 1980s for cable set top boxes to become mainstream. And it wasn’t until recent years that smart TVs (connected TVs) became mainstream. However, before CTV, we had the Internet, and shortly thereafter, digital video.

With programmatic ad-serving technology, digital video saw exponential growth. Since the initial launch of IAB Tech Lab’s Video Ad Serving Template (VAST) in 2008, digital video could begin to scale ad sales in the same way website publishers could with their display ads. With improvements to VAST and the addition of other technologies, ad tech for digital video became more sophisticated, and digital video quality improved.

With the explosion of devices that enabled consumers to watch their favorite videos anywhere, connected TVs became the next step in bringing that sophisticated ad tech to prime-time screens in people’s living rooms. But ad tech for CTV is still catching up. The good news is that much of the ad tech developed for digital video can also work in CTV.

As existing standards are updated to support CTV, and new standards are considered, this guide offers the best way to address the same challenges in CTV programmatic campaigns that first emerged as digital video matured. From the functional challenges of delivering assets to targeting and measurement to concerns over brand safety and ad fraud, the technical standards that have fueled the growth of digital video can also help CTV to scale and grow.

Preface on SSAI

With SSAI, a client media player on the user device (client) no longer has to make ad server calls to deliver an ad. This is ideal for midroll, live streaming, and broadcast scenarios such as a news or sporting event where the latency of loading and unloading a player/ad on the client can cause errors and result in a poor user experience. Instead, an SSAI provider makes the ad requests on the client’s behalf, which has passed along details about the viewing session such as location, device type, and other data that can be useful in selecting the most relevant ads. After an ad has been selected, the SSAI provider matches the ad quality to that of the content and stitches the ad into the content stream, which is seamlessly delivered to the client player in a single stream. VAST 4 supports the increasingly common “ad-stitching” method for stitching linear ads into a video or audio content stream and sending it to players on client devices. While VAST 4 has specific items for SSAI, some developers still use VAST 3 to execute. For version-specific ads from advertisers, VAST 2, 3 or 4 all work today.

1. Message Sent to Stitching Service: The publisher sends a message for VOD or stream start signal for live stream, to the ad-stitching service.
2. Request Ads via Ad Call: The ad-stitching service makes a request to the ad server. For VOD, this is typically VMAP or In-line VMAP with VAST to the main ad decision software. For live stream this is a formatted ADS ad call for the single break.
3. Send VAST: The ad server responds with a VAST tag with a mezzanine file, and ready-to-serve files. SSAI vendors download the highest bitrate available and get it ready. If the ad stitching service has already received the creative for a previous request and has transcoded the mezzanine file, it moves on to step 5. If the VAST tag response is a Wrapper tag then the ad-stitching service should extract the inner InLine response using the same precedence logic as a client-side media player.
4. *Extract Mezzanine and Transcode: The ad-stitching service pulls the unique creative identifier from the VAST tag. If the creative has never been used in the system, the mezzanine file is extracted and transcoded. In this scenario, the ad is skipped and the next available ad is played instead. VAST error code 407 is sent.
5. Select Transcoded: If the creative in the VAST tag from step 3 matches the unique creative identifier for an ad that has already been transcoded, the ad-stitching service selects the pre-transcoded file already in the system.

Video Assets Delivery

Quality: As advertisers look to extend their digital video campaigns to include CTV, one of the primary considerations is the screen size on which ads are viewed. Larger screens mean that higher asset quality and overall consumer experience are even more important. In addition, CTV ad delivery and the need to support various devices have led to a deeper focus on Server-Side Ad Insertion (SSAI). For asset submission in CTV, and especially when working with SSAI, a mezzanine file is required. A mezzanine file is encoded at the highest possible quality and used to encode ready-to-serve ads at lower resolutions and smaller file size. Guidelines for creative file submission are outlined the Digital Video Ad Formats Guidelines.

Ad Request: VAST has historically been an ad response format, with the ad request left as an integration exercise. With VAST 4.1, a standard set of macros can be used to communicate information about the impression and player environment in the ad request. This enables ad servers to generate the best possible VAST response for any impression and reduce delivery errors. We recommend the use of [Macros and CATS]

Campaign Tracking: Another challenge in video ad delivery has been the lack of the ability to uniquely identify a creative asset across different media or screens. This is useful for reporting, caching creative assets, and frequency capping. We recommend advertisers provide [Universal AdID]

Separation of Media from Executable Code: The complexity of digital video has given rise to the need to separate the linear video file from any executable code like creative interactive API files or measurement scripts. While the VAST media file nodes has accepted various media files in the past, interactive APIs may not always be executed. In VPAID, the code and the media file are bundled together, resulting in latency and making it impossible to serve an ad through SSAI. Hence, with VAST 4.x, the deprecation of VPAID was announced in favor of providing separate locations for interactive and measurement scripts that ensure the media file is always easily accessible from the VAST tag. We recommend advertisers and their partners provide media files and executable codes separately to be included in VAST verification and creative nodes [VPAID deprecation]

{ 
	"id": "1234567893", 
	"at": 2, "tmax": 120, 
	"imp": [ 
		{
		"id": "1", "bidfloor": 0.03, 
		"video": { 
			"w": 640, "h": 480, "pos": 1, 
			"startdelay": 0, "minduration": 5, "maxduration": 30,
			"maxextended": 30, "minbitrate": 300, "maxbitrate": 1500,
			"api": [ 1, 2 ], 
			"protocols": [ 2, 3 ], 
			"mimes": [ 
				"video/x-flv", 
				"video/mp4", 
				"application/x-shockwave-flash", 
				"application/javascript" 
			], 
			"linearity": 1, 
			"boxingallowed": 1, 
			"playbackmethod": [ 1, 3 ], 
			"delivery": [ 2 ], 
			"battr": [ 13, 14 ], 
			"companionad": [ 
				{ 
					"id": "1234567893-1", 
					"w": 300, "h": 250, "pos": 1, 
					"battr": [ 13, 14 ], 
					"expdir": [ 2, 4 ] 
				}, 
				{ 
					"id": "1234567893-2", 
					"w": 728, "h": 90, 
					"pos": 1, 
					"battr": [ 13, 14 ] 
				} 
			], 
			"companiontype": [ 1, 2 ] 
		} 
	} 
], 

"site": { 
	"id": "1345135123", "name": "Site ABCD", 
	"domain": "siteabcd.com", 
	"cat": [ "IAB2-1", "IAB2-2" ], 
	"page": "http://siteabcd.com/page.htm", 
	"ref": "http://referringsite.com/referringpage.htm", "privacypolicy": 1, 
	"publisher": { 
		"id": "pub12345", "name": "Publisher A" 
	}, 
	"content": { 
		"id": "1234567", 
		"series": "All About Cars", 
		"season": "2", 
		"episode": 23, 
		"title": "Car Show", 
		"cat": [ "IAB2-2" ], 
		"keywords": "keyword-a,keyword-b,keyword-c" 
	} 
}, 

"device": { 
	"ip": "64.124.253.1", 
	"ua": "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16",
	"os": "OS X", 
	"flashver": "10.1", "js": 1 
},

"user": { 
	"id": "456789876567897654678987656789", 
	"buyeruid": "545678765467876567898765678987654", 
	"data": [ 
		{ 
			"id": "6", "name": "Data Provider 1", 
			"segment": [ 
				{ 
					"id": "12341318394918", "name": "auto intenders" 
				}, 
				{ 
					"id": "1234131839491234", "name": "auto enthusiasts" 
				} 
			] 
		} 
		] 
	} 
}

IFA

In traditional browser environments, ad platforms rely on semi-persistent HTTP cookies to identify a user. This is used to deliver targeted ads as well as to control the ad frequency and ad rotation. Due to the wide variety of different Smart TV, Connected Device and other over the top television (OTT) platforms, it cannot be guaranteed that devices support the traditional cookie-based semi-persistent or audience management for ad-related activities. Without device or audience management, the same creative can serve more frequently than expected and frustrate audiences.

It is recommended that device manufacturers, app publishers, and ad servers/measurement platforms implement an Identifier for Advertising (IFA) and send the following three parameters as part of any ad request:

1. An Identifier For Advertising (ifa)
2. An associated IFA type (ifa_type)
3. Limit Ad Tracking (lmt) – an opt-out to respect the users’ privacy choices.

Example usage within ad requests:

https://adserver.example.com/adrequest?Ifa=01234567-89ab-cdef-gh01-23456789abcd &ifa_type=ppid&lmt=0

https://adserver.example.com/adrequest?lmt=1

https://adserver.example.com/adrequest?Ifa=00000000-0000-0000-0000- 000000000000&ifa_type=rida&lmt=1

https://adserver.example.com/adrequest?Ifa=00000000-34sd-gfss-sd54- 12345678abcd&ifa_type=sspid&lmt=1

https://adserver.example.com/adrequest?Ifa=12340000-34sd-gfss-sd54-88223678xcdf&ifa_type=sessionid&lmt=1

Guidelines for App Publishers

Guidelines for Ad and Measurement Platforms

User Agent Guidelines

Accurate device information – type, operating system (OS), client software, and other data – is crucial in the advertising ecosystem. It allows for precise targeting, better creative delivery, analytics, and measurement, among other things. Knowing the screen size and other capabilities enables the best creative to be sent to the device. Reliable device identification in connected TV (CTV) / over-the-top (OTT) is essential for measurement because TV screen inventory is considered more valuable than inventory on other devices.

“content”: {
…
“cat”: [“333”, “337”, ”1009”,”1014”,”1028”,”1068”,”1215”],
“cattax”: “2.1”,
…
 } 

CONTENTCAT = “333”,”337”,”1009”,”1014”,”1028”,”1068”,”1215”

VAST Tracking

VAST enables tracking by specifying a number of specialized elements that map to media playback events, such as start or completion, user interactions, verification measurements, etc. Each element contains a url of a server-side resource, which historically has been a 1x1 pixel image, but may also be a script or document. Calls to these resources are counted by the ad server or other measurement vendor to tally up the total for a specific event.

Headers in Server-to-Server (S2S) Ad Requests

With client-side ad tracking, the player (client ) sends tracking included in the VAST tag and uses cookies to determine which device executed the ad. However, in server-side ad-stitching, the player may not be able to process ad tracking, and the ad-stitching service cannot access cookies used in traditional client-side tracking. Instead, the ad-stitching service must identify devices where ads play by a combination of other methods.

To avoid being mistaken as fraudulent traffic, ad stitching providers must include with their ad tracking requests the following HTTP headers:

• X-Device-IP

  set to the IP address of the device on whose behalf this request is being made.

• X-Device-User-Agent

  set to the User-Agent of the client on whose behalf the request is being made.

• X-Device-Referer

  set to the Referer header value that the client would have used when making a request itself.

• X-Device-Accept-Language

  set to the Accept-Language header value that the client would have used when making a request itself.

• X-Device-Requested-With

  set to the X-Requested-With header value that the client would have used when making a request itself.

X-Device-

VPAID Deprecation and the Move to Open Measurement

A key reason some video publishers have avoided using VAST, has been lack of quality control. Along with the IAB Video Player-Ad Interface Definition (VPAID), VAST can deliver ads programmatically or include ads with complex interactions. If a player isn't programmed to accept VPAID ads, the ad cannot be executed. Even when the player does accept VPAID ads, performance may be slow and cause latency in load times. In the meantime, the audience experiences a delay or a malfunction in their viewing experience. Additionally verification vendors have been known to use VPAID for measurement verification instead of using it for ad interaction as VPAID was intended. This has made measurement a challenge in environments where VPAID is not compatible such as with SSAI.

<AdVerifications>

<ViewableImpression>

<InteractiveCreative>

Handling MediaFile Nodes During the Transition from VPAID

For VAST tag creators (both direct as well as wrapped tags)

APIFRAMEWORKS

1. When a request indicates OMID support and the ad is configured to user OMID script(s), include the AdVerifications node (or extensions node with type AdVerifications for the VAST versions before 4.1) to include verification scripts.
2. If VPAID support is indicated in the request and the tag creator requires VPAID support (for interactivity or ad blocking), include the following in the VAST tag.
1. The AdVerifications node (or extensions node with type AdVerifications for pre VAST 4.1)
2. The VPAID file type MediaFile node (for Blocking or Interactivity)
3. If OMID/VPAID support status is not known and there is no hard requirement on VPAID use from the buyer, ensure that the VAST tag contains all 3 of the following so that the publisher has all resources available:
1. The AdVerifications node (or extensions node with type AdVerifications for pre VAST 4.1)
2. The VPAID file type MediaFile node (for Blocking or Interactivity)
3. One or more non-VPAID (video creative) MediaFile nodes.

For Publishers

1. If OMID is supported, run the AdVerifications node (for Open Measurement) - and the video creative MediaFile
2. If OMID is not supported but VPAID is supported and VPAID MediaFile node is available in VAST tag, run VPAID
3. If OMID and VPAID are supported, run both AdVerifications node and VPAID
4. If OMID and VPAID not supported, run one of the non-VPAID MediaFile nodes.

Open Measurement

With the introduction of the AdVerification node in VAST 4.0, it became possible to reference verification resources while removing them from the critical rendering path. But VAST 4.0 was incomplete – a new API was required to describe how this new integration should actually work.

Macros

The following VAST macros were created to support OM integrations.

OM Web Video SDK

Open Measurement for CTV

VPAID: Video Player-Ad Interface Definition

See sections on VPAID Deprecation & SIMID.

SIMID: Secure Interactive Media Interface Definition

SIMID is a standard for providing rich interactivity in the context of streaming audio and video (media) ads. While the Video Ad Serving Template (VAST) standard addresses how publishers discover various metadata assets related to an ad campaign, SIMID addresses how the publisher’s media player should communicate and interface with a rich interactive layer and vice versa. As such, one can think of the SIMID creative as one of the assets listed in a VAST document.

<InteractiveCreativeFile>

<InteractiveCreativeFile>

<MediaFiles>

Example

	
<MediaFiles>
    <MediaFile>https://example.com/mediafile.mp4</MediaFile>
    <InteractiveCreativeFile type="text/html" apiFramework="SIMID" variableDuration="true">
        <![CDATA[https://adserver.com/ads/creative.html]]>
    </InteractiveCreativeFile>
</MediaFiles>

Player and Creative Communication

VAST Interactive Template

While interactive video ads command a premium, they are not supported on all platforms or by all publishers. While this is partly due to concerns around VPAID, which are being addressed by VAST4 and the replacement for VPAID, the execution of unknown code may never be allowed in many cases. To address this, VAST 4.1 introduces the concept of “VAST Interactive Templates”. These are interactive experiences that only require some visual assets (images, css, etc.) and some instructions/metadata in the VAST tag. The publisher implements the interactive code and uses the metadata to run the interactive ad.

Companion as End-Card

<CompanionAds>

<Companion>

Additional Interactive Templates

Macros

VAST player macros enable publisher’s media players to provide additional data points into ad requests. They cover passing details such as the user agent and app that the VAST ad is serving into.

Marking Macro Values as Unknown or Unavailable

SSAI Macro Guidance

While the IAB Tech Lab has an official list of 50+ macros, it’s technically not possible to support all macros in any given HTTP request simply due to length limitations. To help guide SSAI providers and the industry toward an optimal set of macros, the below list has been curated for sharing basic user agent, environment, and content details that are critical to verification partners and buyers.

Recommended Device & Environment Macros

[APPBUNDLE]
[STOREID]
[STOREURL]
[DOMAIN]
[ADTYPE]
[PAGEURL]
[DEVICEIP]
[DEVICEUA]

Recommended Content Macros

[CONTENTURI]
[CONTENTID]

Recommended SSAI / Media Player Specific Macros

[SERVERUA]
[SERVERSIDE]
[CLIENTUA]
[PLAYBACKMETHODS]
[PLAYERSTATE]

Content Taxonomy & Suitability Framework

The IAB Tech Lab Content Taxonomy 2.x provides a “common language” that all parties—publishers, Server-Side Providers (SSPs), Demand-Side Providers (DSPs), verification vendors, and advertisers—can use and understand when describing the content of a page, app, or other user environment. The content taxonomy is useful in two main use cases—contextual targeting and brand safety/suitability.

Content Taxonomy Usage Guidance for Buyers

Implementation Guidance for Ad Verification Vendors

Recommendations:

• Ad verification vendors should apply any relevant Content Taxonomy categories to a given piece of content, and/or any of the 11 brand safety categories.
• Ad Verification vendors should apply a risk level whenever any of the 11 core brand safety category labels are applied to a piece of content.
• It is possible to have multiple brand safety category labels (and appropriate risk levels with each brand safety category label) associated with a given piece of content.
• As of v2.2, ad verification vendors are not required to apply risk levels to topic categories other than the 11 core Brand Safety categories in the Content Taxonomy.
• As indicated above, the descriptions for the categories at various risk levels are from the GARM/4As APB Framework.
• In addition to brand safety, ad verification vendors might also provide more information about the topic context using the other categories on the content taxonomy.

Implementation Guidance for DSPs

1. A user interface to allow buyers to define their acceptable “risk tolerance” levels (high/med/low) for the 11 core brand safety categories as they set up their campaigns.
2. A workflow where they accept the content URL from the publisher/SSP and pass it along to an ad verification vendor.
3. Use the response from the ad verification vendor (as described above) to decide which pieces of content match the buyer’s brand safety risk tolerance for that brand.

Implementation Guidance for Publishers & SSPs

1. Floor content: The key guidance to publishers and SSPs is that they should strongly consider preventing the presence of content that would receive a “Floor” risk level in association with any of the 11 Brand Safety categories. Barring that, at a minimum they should consider not monetizing or allowing advertising on any such content.

2. Providing context: When making ad requests, publishers and SSPs should tag each piece of content with the relevant content categories from the Content Taxonomy and provide those in the OpenRTB or VAST bid request (as described in section 2). It is very likely that the buy side platforms will want to perform their own analysis using ad verification vendors of the content categories, as well as the floor & suitability checks. So, Publishers/SSPs should also provide the URL of the content, so that the ad verification vendors can perform their checks.

For more detailed information refer to the full Content Taxonomy and the Implementation Guide.

Ads.Cert – Signed Bid Requests

The principle of signed bid requests is that Publishers (ie publisher software) should add a signature at the origination of the real time bidding transaction. This provides a traceable path to verify critical data of the inventory such as domain, IP, format, etc. Publishers will benefit from this anti-fraud measure in knowing that their inventory is securely passed for sale. Advertisers and buyers will benefit from this by reviewing the supply authentication to gain confidence in where the inventory is coming from in the real time bidding transaction.

ads.txt & app-ads.txt

The ads.txt specification focuses on protecting advertising inventory hosted by the website publishing the ads.txt file. And the app-ads.txt specification describes an extension of the original ads.txt standard to meet the requirements for software applications distributed through mobile app stores, connected television app stores, and other distribution channels of this nature by obtaining the app developer’s website URL from an app listing page in an app store.

CTT/OTT Inventory Sharing

In OTT, these situations often arise from relationships such as content distribution (MVPDs or vMVPDs) or as a result of various carriage agreements (TV Everywhere). Ultimately, nearly all relationships can be simplified into the case where “some business entity, other than the app/site owner, has ownership over some ad space within the app/site and the right to sell that inventory.”

Example Use Case A: Programmer Owned App

App: Programmer A App (app bundle ID: 12345)
Developer URL domain for the app: devsite.programmerA.com
Seller/Publisher: Programmer A (publisher ID: abcde)
Content Producer: Programmer A

sellers.json and SupplyChain Object (OpenRTB)

The IAB Tech Lab has introduced two technical specifications aimed at increasing trust of the supply chain, specifically on the supply-side of real-time bidding and programmatic buying. The first, sellers.json, enables buyers to verify the entities who are either direct sellers of, or intermediaries in the selected digital advertising opportunity for purchase. The second, the OpenRTB SupplyChain object, allows buyers to see all parties who are selling or reselling a given bid request.

https://{advertising_system_domain}/sellers.json