Recognize, Monitor and Tolerate: Discrepancy and Header-Bidding (Tagless Ad Tech)

When I first wrote about ‘tagless’ ad tech (also passionately referred to as header-bidding or pre-bidding) back in late December, my aim was to share some of what I’d learned about the technology as well as gain a better understanding of it myself.

My colleague also wrote a post (here and here) that details the more technical side of this setup.

Over the past nine months we’ve integrated with five partners across three websites and have tested a variety of serving types. We’ve built and have had built thousands of line items and have dealt with a number of challenges (both positive and negative) with this tech.

Read More

I Want My Money – Finance Tips for Working with New Digital Ad Partners

At StudyBreak Media all of our finance procedures are manual. We don’t employ a dedicated accountant and we aren’t big enough for a finance team or, to purchase a tool or platform that allows us to automate any part of our process. However, this doesn’t make the work any less important.

This is also the case for many publishers we’ve met. So, we want to share some specific strategies we’ve implemented that have aided in improving our process in a series we’d like to call “I Want My Money”.

In this first article, we will discuss the steps we take with a new ad partner. Look out for more finance tips in future installments. Read More

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…

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. 


Read More

WTF is a ‘tagless’ solution, and why are there so many tags? (Part 1)

- - Uncategorized - 2 comments
My hope with this post is to discuss the idea of ‘tagless’ ad tech and how it can be beneficial to publishers willing to commit the time and resources for implementation. On the surface, this technology can seem a bit intimidating but it’s actually pretty straight forward and my aim is to help reveal that. 
Time permitting, future posts will also outline basic DFP and tech setup, as well as the overall impact we’ve seen thus far from the partners we’re working with on our properties. 

Read More

18 tips for Maximizing Ad Revenue with Website Design

In previous posts, we’ve written quite a bit about different techniques and strategies publishers can use to maximize ad revenue. One key element that all of these strategies require is a site design that lends to a good user experience with a layout that also maximizes ad revenue and performance.

Whether your sites user sessions are long tail or a single pageview, we’ve put together a list of 18 things to keep in mind with your site’s design that will allow you to maximize your return from your programmatic and static demand partners.

Read More