The ad tag for the new Google Ad Manager is fascinating. The typical advertising service setup is one ad tag per advertisement, where each ad tag on the page pulls in a single ad. Three ads on your page, three separate ad calls. With Ad Manager, Google’s gone a single-ad-call, multiple-ads model. Three ads on your page, just one call to the server. Ballsy, very ballsy – because, while this is no doubt powerful, it’s an implementation nightmare for publishers working with dynamic systems that assemble pages on the fly. This is not going to be AdSense-easy to set up.
The main heavy-lifting part of the ad tag goes in the page’s header. It pulls in a JS file that enables several functions, called from the header. First, GS_googleAddAdSenseService with your publisher ID (presumably because I’m letting AdSense compete for remnant.) Then, a call to GS_googleEnableAllServices() – which makes me wonder what services Google will add in the future besides ‘AdSenseService’. Then, each of the ad slots on the page are added, one after the other, through GA_googleAddSlot function calls, and finally, GA_googleFetchAds() is called. Remember, this is all in the header of the page, far away from where the ad is actually served. In the body of the page itself, where each ad is supposed to appear, a GA_googleFillSlot function call is made, which presumably takes one of the ads fetched by the GA_googleFetchAds() call and inserts it into the correct spot on the page.
So aside from the main JS file, which doesn’t change and can be cached in a CDN, it seems there’s only one call made to Google’s servers – GA_googleFetchAds() – which fetches every ad required for the page. This is great for capacity, and in fact it’s how a lot of server-side ad serving systems work. It also enables some fancy things, like ad deduplication between slots or coordinated ads (where multiple ad slots on the page are filled by the same advertiser in an organized fashion.) However, it requires the header of the page to be aware of each and every ad slot in the body of the page. So if you want to add an ad slot, you have to modify both the body of the page, getting the GA_googleFillSlot call in the right place, and the header of the page, adding the GA_googleAddSlot function call. And this is very much a problem for sites that are dynamically assembled, but in general have a static and unchanging header. Do enough publishers have enough command over their CMS to effectively modify the JS in the header on the fly to account for the changing content on the page? Hell, I’m not even sure I can replicate my current setup in it, where I only show certain ad slots on blog posts over a month old.
I’ve just started exploring the Google Ad Manager – haven’t set up placements yet, for example – so perhaps I’m missing something, and maybe there’s an ‘unsophisticated publisher’ way to do this. But right now I’m just fascinated. They’ve put out something nifty and powerful, but I think there’s a more than small chance it’s too powerful to be distributed broadly, and it’ll bite them in the butt a bit. We shall see.
{ 4 comments… read them below or add one }
I like what I see here Greg. I like that it is overly complex for selfish reasons. Farewell from Cam, sorry I never got to know you more. Keep up the great blog!
Isn’t a potential concern with this approach the requirement to serve creative third-party requested by many advertisers (i.e., serve out of advertiser’s ad server) — in these cases the publisher has no control over the advertiser’s code, some of which still does document.write()s straight into the page.
So I wonder if they’re going to start pushing an open toolkit for rich ad unit production for implementation within ad manager.
Personally I think I still see the whole Google Ad Manager thing as a potentially gross conflict of interest for established publishers.
Bosko – document.write directly into the publisher’s DOM is a huge security issue for any ad system that allows third-party tags to be trafficked in and then served, including Google’s.
Interesting, though – I believe Google’s implementation might make one of the standard ways to protect pubishers, wrapping ads in an IFRAME, unable to work, since the tag in the body is dependent on the tag in the head.
Greg – I agree that document.write()ing third-party tags are generally bad for publisher security (access to publisher DOM), but:
- they’re (still) used; a lot of publishers who don’t have established accreditation processes simply stick tags in their pages at the location where they expect ads to appear, without providing DIVs to anchor onto, nor IFRAMEs. Sad but true.
- IFRAMEs, while great, don’t unilaterally prevent third-parties from touching the publisher’s DOM. In particular, when dealing with lots of implementations of expandable units delivered within IFRAMEs, you gotta have a way of busting out of the IFRAME on expand, and that implies having a mechanism to play with the IFRAME parent’s DOM (i.e., the publisher DOM).
In general, I think that there is an implicit trust relationship between publishers and their direct advertisers. Ad units delivered through generic third-party ad network tags are a different story, but those are rarely rich units anyway and can likely safely be isolated in IFRAMEs.
This trust relationship, it’s worth mentioning, exists between publishers and other “service providers” too, so it’s not reserved solely to advertising. For example, if I stick del.icio.us’ mp3 player tag code in my page, I’m theoretically opening myself up to the possibility of a compromise of del.icio.us affecting my site as well.
Thanks for the post… I’ll be watching for additional insights.