Creating more competition is a win-win when it comes to ads
Whether you put ads on a blog to earn a full time income as a blogger or use them to help offset the hosting costs of a community forum, it makes sense to maximize whatever revenue you can from the space you give up to ads.
Many people’s first (and only) experience of generating passive website income with ads is via Adsense and it’s a great system - you add some code snippets to your pages, ads show up to visitors and, if you have sufficient traffic to generate enough views and clicks on them, Google pays you some money each month. If you work hard at SEO to promote your site then it can contribute to the hosting costs or even generate a decent income.
So what if you could generate additional income on top of what Adsense was paying and at the same time, increase what Adsense was paying each month? It almost sounds too good to be true but it isn’t. Here’s how …
Adsense is all about the auction process. The more ads that compete for a slot, the more money you potentially make from it. This is a great video explanation of how the ad auction works
If you’re using Adsense exclusively for site monetization then the only way to increase earnings (beyond site design and good ad placement) is to increase traffic which usually entails writing more & better content and working at Search Engine Optimization and social marketing.
The measure for ad performance is usually expressed in terms of CPM or RPM - Cost or Revenue Per Mille (which means “thousand” - sorry, for some reason we have to use latin now and then).
So, if you have an RPM of $1.50 you earn that for every 1,000 impressions. If you can increase a 5,000 page-view per-day site into a 20,000 page-view per-day site then you should see revenue go from around $7.50 to $30.00.
It almost goes without saying but you really want to be doing that no matter what else you do.
But if you could increase the $1.50 RPM to be $2.00 or $2.50 instead, it would amplify your efforts even more and that’s where Dfp + Prebid.js Header Bidding comes in.
The first part is Dfp which is an ad serving system that Google provides which can serve up custom ads as well as falling back to Adsense. Although it’s slightly more complicated to use than Adsense alone, it does provide many benefits. You can, for example, use it to serve any direct sale ad agreements you might have negotiated with local businesses or ads from agencies other than Adsense.
Which ad is served for any request to Dfp can depend on several factors including targeting tags on the page, the ad slot dimensions and a price priority.
Traditionally, people used these price-priority and targeting tags to be able to serve-out an agency’s ad first based on a higher RPM and then, via the fallback tag, attempt to serve another ad at a lower price if the first agency couldn’t meet the floor price.
This could continue for 2, 3, 4 or more advertisers in a waterfall. The agency with the highest RPM would get the first shot at satisfying an ad request and so on down the chain.
Although this waterfall system works, it is problematic. Not only is it incredibly complicated to setup and configure, it also constantly required adjusting based on the RPM that each advertiser was delivering which was always just the average, not specific to any one ad request. The latency from the multiple requests in series also impacts how quickly ads appear which could really have a negative impact on view-ability - by the time the banner ad at the top of your page has filled for instance, the user may well have scrolled down and the impression not be monetized.
So, Dfp is great but trying to increase ads using a waterfall setup … not so much.
Header bidding solves the problem by requesting all the bids for an ad slot in parallel on the client literally in the page header (so early in the page loading process). Because they are done in parallel, the ad-latency is now based on the slowest response rather than the times of all responses combined (and you can set a timeout).
An ad request is then sent to Dfp as per usual but crucially, at this point, the client might already have a potential ad to serve - the winning bid from the prebid header bidding process. This ad request to Dfp includes the CPM/RPM for the ad so the price-priority feature of Dfp can be used to tell Adsense that it needs to beat this amount to win the auction.
If Adsense beats it then there is a good chance that the amount it had to pay is higher than if there was no minimum. If it doesn’t beat the price, well you already have the guaranteed bid for the winning header bidding ad which is served instead.
You’re maximizing the amount an advertiser has to pay for that ad slot on a per-ad-request basis. No average CPM/RPM to monitor and maintain, no figuring out the best order to chain the ads and it’s easy to add new bidders to the process to further increase auction competition.
Because there is a single request to Dfp instead of the back-and-forth of the waterfall setup, latency is reduced and the ad appears faster which also has a positive effect on ad-unit performance.
Boom - faster ads, higher payout! Not only can your Adsense earnings go up because of the additional auction pressure but you are also now earning additional income from the other ad providers as well.
There’s lots of information about how to setup the client-side of this on the Prebid site. I also blogged previously about using Dfp Light / Glade with Prebid.js to speed up the ad loading via a smaller, lighter script and you can also use the same Dfp setup to serve ads for AMP (Accelerated Mobile Page) content.
But what I found most challenging was the Dfp side of the setup and while the instructions on the Prebid.js site work they are for a manual process which I found rather laborious and error prone. You need to create specific entries for every CPM/RPM amount from $0.01 to $3.00 in $0.01 increments, $3.00 to $8.00 in $0.05 increments and $8.00 to $20.00 in $0.50 increments, each with 3-4 creatives each.
Creating 400+ Dfp Order Line Items with 4 creatives each … manually … using the Dfp UI … is … not fun.
Fortunately, Dfp has an API and in an up-coming blog I’ll show you how use a script to automate the setup and updating of the Dfp ad-server side of things so everything is consistent.