Ad serving insights: Ad invocation codes and placement tags

Ad invocation codes (called also placement tags or ad codes) are a bit different from web trackers covered in an earlier post. Their main task is to load a creative (an ad) into the placement on a website or in an app. Additionally, they usually are responsible for cookie management, impression tracking, ad rotation, visibility tracking and other tasks.

There are three main types of ad codes used in web display advertising:

JavaScript tags,
iframe tags,
SafeFrame tags.

Image tags were widely in use as well (and still are seen in mobile web advertising quite often), but they are getting pushed out by the above methods and SDKs (in app advertising). They keep to be supported by some ad servers as a fallback method e.g. when JavaScript is not available (however due to a lot of non-human bot traffic, if this use is very limited).

Method #1 – Ad placement JavaScript tags

This method is very straightforward – publisher places a JavaScript ad invocation code directly into html code of the page (in a div prepared for displaying certain size of ads called ad slot) and when a visitor navigates to the page, the browser go through the following workflow.

A sample workflow of ad server using JavaScript placement codes.

Browser starts loading a page, e.g. http://example-publisher.com/,
Ad invocation code placed on the page loads an external static ad tracker code (e.g. ad.example.com/ad.js) and initiates the ad tracker object passing publisher and/or placement ID,
Ad tracker makes a request to the ad server querying for an ad markup (also called creative tag) to be loaded into the ad slot,
Ad server responds with the ad markup code (before it’s returned ad server executes all targeting/campaign matching logic),
Markup code returned is either:
- another ad invocation tag from other ad server or ad network (going back to point 2) – this happens pretty often e.g. when there is no ad to serve, usually inventory is filled with a 3rd party ad networks like AdWords or SSPs placing the impression on RTB exchanges,
- actual creative (image/object/html tag linking to CDN to fetch assets from),
JavaScript code makes a request to the ad server confirming the impression.
JavaScript executes additional logic / 3rd party scripts such as:
- setting a cookie used for capping, re-targeting and post impression tracking,
- executing ad visibility / ad verification codes,
- setting timer for rotating an ad (upon certain amount of time in view, ad is replaced with another one loaded from the ad server).

The big disadvantage of the JavaScript method is that the advertiser gets the direct access to the publisher website, including possibility of manipulating DOM objects, first-party cookies etc., hence it can lead to inserting a code that breaks the page or a malicious script that steals data from visitors.

As it may not be a problem when the inventory is sold directly and served from a trusted ad server, but when it comes to putting inventory on sale on exchanges, or an advertiser requires placing his tags, it may be good to re-think the decision of allowing JavaScript ad tags.

Method #2 – Iframe tags

The iframe method of placing ads is great for the publisher as it isolates the ads displayed and prevent their code to interfere with the DOM tree of the website. It also speeds up loading of the ads, as the browser starts loading them instantly after reaching the iframe tag (as opposed to waiting for the JavaScript static ad tracker code to be loaded).

Another advantage is that web browsers comply to the same origin policy which prevents accessing the publisher domain information (especially the parent frame) from a 3rd party domain script (in this context – the ad tracker).

So why isn’t it the only method used?

The main issue with the iframe tags is that they cannot embed expandable/resizable banners and rich media ads. They also make much harder tracking ad visibility and running ad verification services.

There is a workaround called a frame buster, but it requires the publisher placing the frame buster code on his domain for every ad network he wants to support.

How does a frame buster work?

A frame buster is an html file with JavaScript code placed on publisher domain.

A sample workflow of ad server using iframe tags with a frame buster:

Browser starts loading a page, e.g. http://example-publisher.com/,
Iframe placed on the page loads a resource from the ad server domain, e.g. adserve.example.org – publisher and/or placement ID are passed in the location URL (in GET parameters),
Iframe html resource loaded from the ad server, embeds the frame buster file from publisher domain (in our case example-publisher.com) in the iframe setting up bi-directional communication e.g. via easyXDM or similar method,
The frame buster iframe is now controlled by the code from ad server’s iframe, but it’s in the publisher’s domain so there are no longer restrictions of the same origin policy (the script may access the publisher domain, modify DOM tree and do everything it needs to support e.g. an expandable ad format),
Remaining steps continue as in JavaScript ad placement workflow – the ad tracker script is loaded, it makes a request to the ad server querying for an ad markup to be loaded into the ad slot etc.

If are looking for an example implementation, see the list of popular ad network framebusters or a sample xdm implementation on stackoverflow.

Method #3 – SafeFrame standard

SafeFrame standard announced by IAB is a try to address problems with iframe and JavaScript tags implementation.

In short, the SafeFrame is based on the three core components:

SafeFrame Tags (JavaScript) placed on a publisher websites,
SafeFrame Host serving SafeFrame Tags that create iframes on publisher websites and expose APIs to iframes to interact with publisher websites,
External Party Ad server serving ads into SafeFrames using APIs to interact with publisher websites (e.g. getting information from the publisher website, resizing ads, tracking visibility etc.).

As the SafeFrame is a topic for another post, I am not going to cover it in more detail from technical perspective (for more information, see the SafeFrame information page).

It’s very promising standard that is worth keeping an eye on. However, the standard has still several problems serious problems mentioned in this review. To summarise them quickly, the main issues are:

malicious SafeFrame Host may fake the information,
SafeFrames cannot be nested,
they may not be used for free due to patents hold by comScore.

Other notes

An ad tracker may be a way complex and do much more than I mentioned in this post. Some of these activities include: cookie respawning, monitoring engagement of the user with the ad, or how much of the video ad user watched, monitoring the ad visibility or finally rotate the ad (request another ad for the user from the ad server and replace currently displayed ad) after certain amount of time.

Recently there is a lot of discussion around viewable ads as well as ads shown above the fold (that are visible for the user without scrolling through the page). These ads are much more effective, but it’s also worth to note that on cluttered with content pages, viewable ads not necessarily have much better results.