These tags are all essentially the same in structure: they are all requests for content of a certain size and type from a certain URL. The content is either a creative or another ad tag and it may be returned immediately in one step or after multiple steps (an auction, redirects, etc.) each with its own tag. An ad tag may look very long and complicated if information about the ad call is included in the tag itself, or it might be very short and simple if ad call information is stored in the server to which the tag's URL is pointed.

On This Page

How Ad Tags Work

Here's a simple example of how ad tags move through different systems. The example uses one ad server but in reality publishers and advertisers may each have their own ad servers: the publisher to track the impressions and the advertiser to determine which ads to serve.

When the user visits a publisher web site, the browser sends an ad tag to the ad server. This ad tag contains information about the user and the ad placement.

The ad server optionally passes an ad tag to a third-party data provider to retrieve information about user segmenting or contextual targeting.

The ad server then passes an ad tag to the advertisers. Depending on the publisher-advertiser relationship, this may mean simply directly requesting ads for guaranteed buys, or it may involve requesting bids from multiple advertisers and carrying out an auction to determine the most profitable result for the publisher.

The ad server delivers the creative (the ad) to the browser. Typically, this means returning an ad tag with a creative URL, with the creative itself hosted on an independent content server. For more information about creatives, see Creatives: An Overview.

What Does an Ad Tag Look Like?

An ad tag has two parts:

A URL, from which the browser will request content

Some HTML and possibly some JavaScript code. (HTML lets you create static webpage content. JavaScript is designed for performing dynamic tasks.)

The purpose of the code is to tell the browser how to display the ad (or other content) that they get from the URL request. For example, the HTML <iframe> tag tells the browser to open a mini browser window of a specified size inside the current window. This way the ad content cannot expand beyond the size specified and "take over" the screen.

For example, here's an AppNexus ad tag that a publisher would use to auction an impression.

This is what the different parts of the tag are doing:

The HTML <script> </script> and type="text/javascript" tell the browser that JavaScript code will be executed here. The browser needs to be alerted to this so it can process the JavaScript correctly, rather than treating it as HTML.

The URL points to the AppNexus Impression Bus, which processes all requests to the AppNexus platform. /ttj is an AppNexus designation for a JavaScript call, and id=1234 is the ID that AppNexus has assigned to this ad tag. This allows information about the ad tag, such as ad size or reserve price for the ad, to be stored on the Impression Bus rather than on the page itself. This way the information can be changed at any time without requiring a new tag.

When the AppNexus Impression Bus receives the tag, it runs an auction. Something like the following raw JavaScript code is returned to the browser:

This is what the different elements of the JavaScript are doing:

iframe frameborder="0" width="160" height="600" tells the browser to open a 160x600 iframe.

src="http://ad.yieldmanager.com/st?ad_type=iframe&ad_size=160x600&section=560122&m6li=1302146" tells the browser to deposit specific content from the Yield Manager ad server into the iframe. The Yield Manager URL does not point to an actual creative image file, because the Yield Manager ad server makes a dynamic decision about which image to pass to the browser. This URL's query string (everything after the "?") gives Yield Manager information that will help it decide which creative to pass back.

Most people dealing with ad tags (publishers, who need tags to put on their inventory pages, and advertisers, who may use tags to direct a browser to their creative) aren't hand building tags; they are inputting their page information or creatives into their ad server's user interface, which creates a properly formatted ad tag for them.

Further Examples

There are many permutations of ad tag syntax depending on what the tag is doing and whether the ad tag info is on the page or in a server.

A publisher ensures that the ad is an iframe.

A Google AdSense tag

Even though it looks like a piece of the tag is commented out with "!–", this isn't really the case. Some scripting engines, including those for JavaScript, allow the script statements to be enclosed in a comment. Then a browser that doesn't recognize the JavaScript element will ignore the comment, but others will execute it. This particular faux comment is passing information to the Google ad server in order to determine the right ad to show on the page.

A publisher provides alternate content for browsers with JavaScript disabled.

In the NOSCRIPT section, the HREF link is the landing page of the ad and the SRC is the ad itself.

Related Topics

2 Comments

Anonymous

Fundamentally, yes, this is correct. This is often called daisy-chaining. In some systems daisy-chaining can go through even more iterations. This is partly why IFRAMES are preferred for ad-delivery, as this happens in parallel to the rest of the page loading (ie; not having the ads stop page rendering due to the constant redirection of ads within the daisy-chain). Arguably, this is also why RTB/DSP/SSP platforms offer greater user-experience as the older technique of daisy-chaining, where each pass-through of each system usually means less $ value, weher-as in RTB all competing suppliers are contacted at once and the the winning bid is the only returned ad to the page.