How to Read
Doubleclick Ad Tags and Ad Tag Variables
Source: www.adopsinsider.com
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.
