Video Ad Serving with Google DFP and the IMA SDK

Video Ad Serving with Google DFP and the IMA SDK

Google's DoubleClick for Publishers (DFP) is a popular ad server that can be used to deliver video advertising.  In this post, we'll take a look at the how Google's video ad serving technology works.  Let's dive in!

Google offers a few different versions of DFP, so it's best that you start by reviewing this feature availability matrix.  If you have long-form content, you're likely going to want some of the "advanced" features, especially "Ad Rules" which lets you determine when ads play in a video, for how long, and as a result of which triggers.

DFP customers also need to have a video player that is integrated with the Google Interactive Media Ads (IMA) SDK.  The IMA SDK does the job of making the ad requests to the DFP back-end, and then renders the ad response while also sending back any analytics that need to be collected.  It's certainly possible to integrate the IMA SDK with your own team, but there are plenty of vendors and open source projects out there that have already done the work.   Keep in mind that you'll need to integrate the SDK for every platform on which you deliver video (i.e. HTML5, iOS, Android), so the development work can add up quickly.  Still, for those die-hard DIY folks out there, Google has plenty of documentation to help you get started.  Here I've implemented some of their sample code showing ad playback in a generic html5 video tag.

The IMA SDK takes control over the playback experience during ad playback, and then relinquishes control back to your player for the content.  Conceptually, you can think of the IMA SDK as a totally separate video ad player that loads like a layer of transparency paper over your content player.  When the pre-roll or first pod is complete the IMA is hidden, and then comes back into view for any mid-rolls or post-rolls.

Some of the special features of that make DFP appealing are only available where the IMA SDK is used.  Conversely, the IMA SDK can play a standard VAST or VPAID ad from any ad server, but the real reason to use it is to access things like TrueView and the Google Ad Exchange.  Reaching the myriad of devices out there is a challenge and not every feature is available on every platform or device.  It's best to read through compatibility matrix found here.


Requesting A Video Ad from DFP

The image below depicts the communications between the video player (the IMA SDK) and the DFP service.  The IMA SDK makes an HTTP request to the DFP ad server.  Appended onto the request are a number of query parameters that carry information that will be used by DFP to decide which ad to return.  This includes the domain on which the player is embedded, the width and height of the player, a video content ID, and even custom metadata.  The URL itself (and all of the appended query parameters) is referred to as the "ad tag."  DFP uses the information it receives to help determine which of the many possible ads it could respond with.


The format of the response that comes back from DFP depends on the value of the output parameter on the ad tag.  This can be set to either vast or vmap.  To enable the ability to have ads at specific cue points along the timeline, you'll need to make sure that ad_rule is set to 1.  There is a helpful page on the DFP support site that lists all of the ad tag parameters and their possible values (see here).   If you're not familiar with VAST and VMAP, they are XML specifications put forth by a standards body called the Interactive Advertising Bureau (IAB).  Here are three examples of ad responses:

output=vmap&ad_rule=1See Response  
output=vast&ad_rule=1See Response
output=vast&ad_rule=0See Response

There are a few interesting things to point out here.  The VAST specification itself does not define the timing of when an ad should be shown, so when you combine ad_rule=1 and output=vast, you get back a response that is in Google's own format, which in turn makes references to the individual VAST tags.  This is why some people refer to the ad response from Google as the "Ad Rule."  The IAB later created VMAP to provide an industry standard way of communicating ad timing information.  Of course, if you're only delivering ads to your own player, the format doesn't really matter since you know the IMA SDK is there to handle the response.


Leveraging Video Metadata to Target Ads

Often times, publishers want to target advertising to certain pieces of content.  It would also be great, for example, if you could show a pet food ad to someone who was watching a video that featured a dog.  You need to pass the video asset metadata along to DFP to aid with the ad decisioning.  There are two ways to go about this.  The first is to store all of your metadata in your video CMS and/or web CMS, and render it out to the page when it loads.

To achieve this, you'll need to have logic in your player that can look for the data as embedded parameters in the HTML or JavaScript that instantiates the player, and then append the data to the ad request URL (the ad tag).

The second approach is to push a copy of your video catalogue and associated video metadata to DFP directly.  This is called Content Ingestion.  In this scenario, you would only need to append the video ID and a CMS ID to the ad tag to tell DFP to lookup the stored values.  In order to transmit the metadata over to DFP, you need to have your video CMS publish an mRSS feed DFP will consume.

DFP will poll your feed on a regular interval..."up to 15 times per hour, and in most cases, is targetable and reportable within 6 minutes of adding to the feed."  That's fine for most publishers, but those in the news publishing business will want any changes to their metadata within the video CMS be updated immediately in DFP, lest they miss out on any impression opportunities during a breaking story.  If that sounds important to you, you'll want to look into using the DFP REST API to pass the updated metadata immediately.

Once you have your video content metadata in DFP, you'll be able to browse through your catalog from within the DFP interface as shown here:

So, there we have it.  We've covered the basics.  In a future post, we'll take a look at Google's DAI solution.