Implementing Header-Bid (Tagless) DFP Ad Solutions – Part 1

Recently we asked Jon Crowell, who heads up development for StudyBreak Media, to break his blog silence. Jon obliged and the result will be a series of posts that cover a few technical specifics regarding ad serving and ‘tagless’ solutions. Jon has developed a number of tools that aid in our ad optimization and we’re excited to get a chance to share a few of his views on the space. 

EDH

There are several steps to implementing header-bid (tagless) ad partners in a DFP ad-serving setup.

First get a DFP account and make ad units.

In order to serve ads through DFP, a website must be linked to a DFP account (you will need your DFP account ID) and ad units must be created in this DFP account.  An ad unit is just a slot on a webpage in which an ad may appear.  If you have many pages on your website, then you can either run the same ad unit on all pages, or make different ad units for each page.  The first approach is simpler, but the second approach gives you the ability to honor special requests, such as to only run certain ads on the homepage, or to run different kinds of ads on a particular page that you know users spend more time on.

Second load gpt.js on the page where you wish to show ads

The website must load DFP’s gpt.js code in its `<HEAD>` section — in order to do this, gpt.js must be downloaded from Google’s servers.  The code to place on your web page that enables all of this to happen can be generated through DFP.  First click on “Inventory” and then on “Generate tags” — the resulting page will let you choose which ad units you’re interested in and will show you what the JavaScript on your page should look like.

Aside: Sync vs. Async: You will be given the option to run a synchronous or an asynchronous gpt.js setup here.  A detailed discussion of the difference between these two options is beyond the scope of this post, but a few words are in order.

The main difference is that when ads are loaded synchronously on a page, the ultimate time it takes to fully display the content on the page will be dependent on how fast the ads load on the page.  If the first thing on your page is an ad at the top, then that ad will have to load before the browser can proceed to displaying the rest of the page.  The problem with this approach is that loading an ad into a particular ad unit slot may involve several network requests and can be quite slow.

Running DFP ads on your site using the asynchronous approach allows your page to load and render faster, but it involves more complexity in terms of setup and implementation and can prevent certain kinds of ads (such as some of the more lucrative ads that slide around and resize themselves, skins etc) from running.

Third, register ad units with DFP and then display ads

Once the gpt.js code is loaded on the page, you have to register the ad units that you are running on that page with DFP.  Here is an example of a simple page for a site that is connected to a DFP account with id 1234567 — it loads the gpt.js code, registers a single 728×90 ad unit with it, and is running ads synchronously:

Screen Shot 2015-03-13 at 6.34.23 PM

The browser will have to execute googletag.display('ad-leaderboard'); (which may take some time as the ad is fetched) before it can move on to rendering the main content — this is the downside of running synchronously.

To be continued in part 2…

Array

3 Comments to Implementing Header-Bid (Tagless) DFP Ad Solutions – Part 1

Leave a Reply

Your email address will not be published. Required fields are marked *