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

continued from part 1…

Fourth, understand what DFP and gpt.js are doing behind the scenes.

In the example webpage above, gpt.js will make a request to DFP’s servers reporting all the ad units registered on the page.  On the client side, gpt.js will remember which DIV id is associated with each ad unit.  Later, when the call is made to display an ad in a DIV with a particular ID, gpt.js will know which ad unit to make the request on behalf of.  This will allow DFP to find all the line items that target that particular ad unit and rank them to determine which line item should receive the opportunity to serve the ad.

It is worth noting exactly where in the process gpt.js reports the registered ad units to DFP.  This happens in a network request that can be examined using the Chrome Developer Tools, under the “Network” tab.  This tab lists all the various network activity that takes place in the course of loading the website, along with the details of each request.  The first item in the list, of course, is the download of the initial page.  Usually there are a bunch of associated requests made as the page specifies various CSS, JavaScript, and image files that it also needs the browser to download.  Somewhere down the list the request to download gpt.js will be noted.  Below this there will be a request that is actually made by the gpt.js code itself — it will probably be called “ads?gdfp_req” and the domain will be “”.

This request is made in the form of GET request, with many parameters included in the URL.  Here is an (edited and condensed) example, taken from, :

gdfp_req     : 1
correlator   : 3457319691091968
output       : json_html
callback     : googletag.impl.pubads.setAdContentsBySlotForSync
iu_parts     : 1234567,BM_728x90_ATF,BM_300x250_ATF,BM_300x250_BTF,BM_160x600_ATF,BM_160x600_BTF,BM_1x1
enc_prev_ius : /0/1,/0/2,/0/3,/0/4,/0/5,/0/6
prev_iu_szs  : 728x90|970x90|970x250,300x250|160x600|300x600|300x1050|300x500,300x250|160x600|300x600|300x1050|300x500,160x600|300x250|300x600|300x1050|300x500,160x600|300x250|300x600|300x1050|300x500,1x1
prev_scp     : ybot_ad=n|ybot_ad=y&ybot_slot=a-desktop-bx-1&ybot_cpm=175&ybot_size=300x250|ybot_ad=n|ybot_ad=n|ybot_ad=n|ybot_ad=n
cust_params  : O=6_200&sbi_dc=adn.
cookie       : ID=d221d68c155b5968:T=1424805600:S=ALNI_MZKm2TWCJu9j69XliCXkXt9x8fhFg
u_h          : 1080
u_w          : 1920
flash        : 16.0.0
url          :
ga_vid       : 294672459.1424904293
ga_sid       : 1425066603
ga_hid       : 1706938951
ga_fc        : true
dpt          : 1

For brevity’s sake a few parameters were removed from the example above, but some of the ones pertinent to our discussion remain:

  • iu_parts are the ad units (along with the DFP account ID)
  • prev_iu_szs are the sizes of the images that can run in each slot (note that these ad units report that they can accommodate ads of different sizes) — the sizes are in a comma-separated list corresponding to the comma-separated list of ad units.
  • prev_scp are key-values for custom targeting from yieldbot, a header-bid partner.
  • cust_params are key-values for custom targeting from casale and sonobi, both header-bid partners
  • u_h and u_w are the height and width of the browser, so DFP can know something about the context of the web page that the ads will run in
  • flash is the version of Adbobe Flash running in your browser

Fifth, understand line item targeting in DFP

Once DFP has received the notification that ads are ready to serve, it will cause the ad to be delivered by triggering a line item associated with a particular ad network.  Of course multiple line items (representing multiple ad partners) may all target a particular ad unit.  In fact, this is almost always the case in the setups that we run at StudyBreak Media.

So how does DFP determine which line item to give the ad impression to?  Basically, DFP groups together all the line items that could serve an ad impression to the unit in question and then ranks them according to a set of criteria which includes the line item type, whether the frequency cap has been exhausted, the price point at which the line item is set, and so forth.  The line item that comes in first in this ranking is given the ad impression.

Also, it is worth noting that a single line item can target multiple ad units, so it may compete for impressions under many different scenarios.

All DFP line items must be set to target at least one ad unit if they are ever to serve an ad.  However, in addition to targeting an ad unit, further targeting criteria may also be specified.  For instance, a company may wish to run an ad campaign only in Iowa.  In this case, DFP will extract location information from the set of parameters it receives in the ad request and determine whether the user is viewing the website in Iowa or not.  If the line item’s geographical targeting criteria is not met, then it will be excluded from contention.  The same could be done for time of day or browser type or any of several other criteria.

Sixth, understand custom targeting for line items in DFP

While there are several targeting criteria that can be set up in DFP there may be even more targeting criteria that apply only to the particulars of the website you run.  For this reason DFP also provides custom targeting.  Custom targeting is explained in detail here:

A choice quote:

With custom targeting, you can define your own targeting criteria (such as age, gender, or content) that DFP Small Business wouldn’t otherwise be able to determine. For example, you can define custom criteria based on common characteristics of your site visitors that you collect through your website. DFP Small Business can’t determine these criteria, but if, for example, you have user registration data from your site, you can specify demographic information such as gender, age and user interests.

To use custom targeting, you create key-values in DFP, target your line items to them, and then pass the key-values into your ad tags. If a line item targets a key-value, the ad server will only serve it to the ad tags on your website that include that key-value. You can specify up to 20 keys for custom targeting criteria and up to 200 values for each key.

Incidentally, it is against DFP’s terms of service to pass personally-identifiable information through custom targeting.

What some ad networks are now doing is getting their scripts to run on a page and place key-value pairs into that call that gpt.js makes back to DFP.  So, from the perspective of the explanation of custom targeting from Google, the “demographic information” gathered about a particular user is the fact that a particular ad network is willing to pay a particular price to place an ad in a particular unit on the page.

What ad networks are doing is essentially running their own scripts on the webpage in question, evaluating how valuable the ad units on the web page are, making a bid on each ad unit, and then placing this bid information into the custom-targeting criteria that is sent out on the ad call to DFP.  This allows these ad networks to get a chance to see and evaluate a bid at one point earlier in the bidding round than it otherwise would have.

The key-value pairs that these header-bid partners use for custom targeting basically allow them to specify which of their line items they would like to have serve the line item.  Each header-bid ad partner will have set up usually at least a couple dozen different line items at different price points and will choose to have one of these line items compete for the ad impression based on the value that their preview bid has placed on the impression.

Seventh, understand the challenge posed to ad networks by Google AdX

Because Google’s DFP ad server is a dominant player in the industry, Google enjoys a huge competitive advantage: they allow their own ad network, called AdX, a first look at impressions that are served through their DFP ad server.  The publisher (website owner) has the option of turning this integration on or off for any given line item, but because Google’s AdX platform is deep and broad, it is often lucrative for a publisher to keep this integration turned on.

When a line item is set up in DFP to permit bid competition from AdX, it is given a price floor at which bidding in AdX must start.  So a common technique for a publisher to employ is to make a deal with an ad network to sell them impressions at a flat rate of $1.50 CPM, let’s say.  Then they’ll set a line item up in DFP to serve impressions to that ad network, but they’ll put a price of $1.51 as the AdX price floor and allow competition from AdX.  This means that every time an impression would be passed to that line item, AdX has the opportunity to buy it for $1.51 or more.

What this means for the ad network is that they pay a flat rate of $1.50, but they never get impressions worth more than $1.50, which means that their margins are cut.

What is especially galling to the ad networks is that they may have partners lined up who would be willing to pay $4 for some of these impressions, but they’re getting taken by AdX for perhaps as little as $1.51.  They’re essentially getting frozen out of the bidding.

So what they’re doing is getting major websites to let them run their own scripts on their sites.  These ad-network scripts evaluate the impression ahead of time and put a price on it that the ad network would be willing to buy at.  If they know they’d be willing to pay a $3 CPM for the ad, they’ll set the corresponding key-value pair in their header-bid script, which will cause their $3 line item in DFP to be included in the competition for the impression. This raises the price for AdX from $1.50 to $3, preventing AdX from stealing as many good impressions on the cheap.

To be continued in Part 3…


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

Leave a Reply

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