How to Read Doubleclick Ad Tags and Ad Tag Variables

The term ad tag is thrown around quite a bit, and can usually refer to any link involved in the ad serving process, on the publisher, or marketer side. Strictly speaking, Ad Tags are the HTML code a browser uses to fetch an advertisement from an Ad Server – it is a redirect to content rather than content itself.

There are also click tags, action tags, view tags, and other more specific variants to the general ad tag category.  For this particular example, we’ll look at publisher side tag; because our purpose is to show how ad tags help publishers organize their content into targetable products.

Ad Tag Components

So, without further ado, feast your eyes on this example a DoubleClick ad tag:

http://ad.doubleclick.net/ADJ/publisher/zone;topic=abc;sbtpc=def;cat=ghi;kw=xyz;tile=1;slot=728x90.1;sz=728x90;ord=7268140825331981?

An ad tag can tell you quite a bit about how which ad ends up on a page – if you want, navigate to any major publisher and look at the source code; you can probably find a real-life example of a working ad tag. So how can you tell what the ad tag says about the publisher hierarchy and ad targeting? Let’s break it down piece by piece:

http://ad.doubleclick.net/ – this is the host address for the Ad Server – you can see that it is not a publisher’s website, but an independent technology company that has nothing to do with publishing content.  In this example, we’re talking about DoubleClick, the Ad Serving powerhouse that was acquired by Google for $3.1 billion dollars in 2007.

/ADJ – this code defines a specific type of ad call, and what the response can be, i.e., images vs. XML vs. scripts.  For this example, the code ‘ADJ’ is the most common and only returns images, which will serve via JavaScript.  Other responses can include ADF (only image creative in a frame), ADX (only image creative served through streaming technologies), as well as others.

/publisher - this is the site code that DoubleClick uses to distinguish one publisher property from another.  For example, the New York Times owns NYTimes.com, About.com, and Boston.com among other properties.  If they are a client of DoubleClick, the corporation likely pays the bill, but each site would have its own site code so ads could be targeted to a specific paper and not the entire network.

/zone - the zone is akin to a channel level, so the Homepage vs. the Arts page, vs. the Sports page.  These content verticals are likely to attract different advertisers, so it’s important for publishers to be able to target to this kind of granularity.

Zone-Based Hierarchy vs. Topic Based Hierarchy

Here is where tagging logic starts to diverge in DoubleClick.  Some publishers prefer to deeply categorize at the zone level, while others keep moving down the hierarchy to the topic level.  The benefit of using zones over the topic, subtopic, category, or keyword levels that we’ll talk about in just a minute is that the zone is the last level in which you can pull historical reporting.  So you might have sports/baseball or even sports/baseball/nymets so you can pull traffic statistics going back months or years.

The downside with this method is that zones are vertical structures, so if you had multiple verticals on your site that all had a games section, you would have to select each games zone every time you wanted to target all games when traffic the ads, rather than just targeting a single “games” key value.  This sounds easy on paper, but ads up to lots of extra time for your trafficking staff if you have lots of subcategories in each zone.  It would not be difficult to imagine needing 50 zones or more per content vertical to tag to the lowest level of granularity.

That is why most Publishers tag at a higher level, and leave the granularity to the topic variable and below.  A great benefit of granular topic tagging opposed to granular zone tagging aside from being able to use the same topic tag across multiple zones is the ability for topic tags to handle wild cards when trafficking.

This means if you had topic=newyorkmarathon and topic=bostonmarathon, you could simply target topic=*marathon* and ads would automatically fall into both areas.  This makes trafficking much easier, but has the downside of no historical reporting, which can be a challenge for your Yield or Inventory teams.

topic=abc – next in the hierarchy is the topic level. As mentioned above you can use the topic level to tag similar content across zones.  For example, games in multiple content verticals or within them.

sbtpc=def – next in the hierarchy is the subtopic level.  You might use this to target sports games vs. adventure games for example.  Again, you can use this to target across content verticals or within them.

kw=xyz – the keyword segment isn’t really another level in the hierarchy but a way to describe the page for contextual targeting.  The benefit here is multiple keywords are allowed.  These are typically used in guides and directories like a recipe, where you would want to be able to target chicken recipes vs. vegetarian recipes vs. winter recipes, and etc., allowing some overlapping targeting.

tile=1 – the tile variable sets a unique value for each ad call on a specific page.  If there were two or more of the same size ads on a page, separate tile values would prevent the browser from trying to serve the same ad to multiple ad slots at the same time.

slot=728x90.1 – typically defines the location of the ad tag, but is really just another type of key-value.  While this may seem duplicative with the tile value, it isn’t.  For example, tile values are often set dynamically, in the order they appear on the page.  So the first call is tile=1, the second is tile=2, and so on.  But websites use different templates all the time so the homepage may not have as many ad calls as a category page which may have a different number of calls than an article page, so the tile value isn’t designed to be a consistent variable for use in targeting.  The slot however, is.  For example, if a publisher had two of the same ad units on a given page, say a 728×90 unit at the top of the page and a 728×90 at the bottom of the page, the slot value allows them to target specifically to one or the other. That said, the publisher could just as easily set the value of this to anything they want, and it’s common to see sites re-purpose this key value for another purpose, use a text value such as “leaderboard”, or not use it at all.  See Jared’s post in the comment thread below for more detail.

sz=728x90 – defines the ad size of the unit for the ad server logic.  To be clear, this doesn’t restrict the size of the ad in the unit, it just provides a targeting attribute for the ad server.  If a trafficker were to mistakenly target a 300×250 ad to a market segment with a sz=728×90 attribute however, the 300×250 creative would still serve to the 728×90 call, it would just be cut off.  It isn’t uncommon to catch one of these mistakes from time to time as you surf around the web. Additionally, you can actually include multiple values into this attribute, separated by commas.  (Thanks to Jared for correcting!)

ord=7268140825331981 – this number is a random value better known as a cache-buster.  As users move back and forth between pages of content, they often return to pages they’ve seen before, especially navigational pages like the homepage.  Browsers today try to save as much content as possible to speed up load times. 

To prevent browsers from reloading the same ad multiple times (so publishers can maximize revenue and advertisers can get accurate reporting), a random number is tacked on to the end of each ad call so it looks unique to a browser and forces a new series of calls through the ad server.

Source: www.adopsinsider.com