Guidesad servingad invocation codes

Ad Serving Explained: Ad Invocation Codes and Placement Tags

JavaScript tagsiframe tagsSafeFramead markupcreative tagad slotDOM manipulationsame origin policyframe bustereasyXDMad visibility trackingimpression trackingad rotationcookie managementcross-domainIAB

Ad invocation codes — also called placement tags or ad codes — serve a different purpose than standard web trackers. Their primary job is to load a creative (an ad) into a designated placement on a website or in an app. Beyond that, they typically handle cookie management, impression tracking, ad rotation, visibility tracking, and a range of related tasks.

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

JavaScript tags
iframe tags
SafeFrame tags

Image tags were widely used as well (and still appear in mobile web advertising with some regularity), but they are being displaced by the methods above and by SDKs in in-app advertising. Some ad servers retain image tags as a fallback when JavaScript is unavailable, though that use case is increasingly limited due to the volume of non-human bot traffic.

Method #1 — Ad Placement via JavaScript Tags

This approach is straightforward: a publisher places a JavaScript ad invocation code directly into the HTML of the page, inside a div prepared for a specific ad size — commonly called an ad slot. When a visitor loads the page, the browser follows this workflow:

The browser begins loading the page, e.g. http://example-publisher.com/
The ad invocation code on the page loads an external static ad tracker script (e.g. ad.example.com/ad.js) and initializes the ad tracker object, passing a publisher ID and/or placement ID
The ad tracker makes a request to the ad server, querying for an ad markup (also called a creative tag) to render in the ad slot
The ad server executes all targeting and campaign-matching logic, then responds with the ad markup
The returned markup is either:
- Another ad invocation tag from a different ad server or ad network (looping back to step 2) — this happens frequently when no direct campaign is available; inventory is often backfilled via third-party ad networks like AdWords or SSPs placing the impression on RTB exchanges
- Actual creative content (an image, object, or HTML tag that fetches assets from a CDN)
The JavaScript code sends a request to the ad server confirming the impression
The JavaScript executes additional logic and third-party scripts, which may include:
- Setting a cookie used for frequency capping, retargeting, and post-impression tracking
- Running ad visibility or ad verification code
- Setting a timer to rotate the ad (after a defined time in view, the current ad is replaced with a new one fetched from the ad server)

The significant drawback of the JavaScript method is that it gives the advertiser's code direct access to the publisher's website — including the ability to manipulate DOM objects, read and write first-party cookies, and more. This creates real security exposure: a malicious or poorly written script can break the page or exfiltrate visitor data.

This risk is manageable when inventory is sold directly and served from a trusted ad server. However, when inventory is made available on exchanges or an advertiser requests placing their own tags, it is worth carefully reconsidering whether to permit JavaScript ad tags.

Method #2 — Iframe Tags

The iframe approach is generally more favourable for publishers because it isolates ads and prevents their code from interfering with the website's DOM tree. It also tends to speed up ad loading, since the browser begins fetching the iframe resource immediately upon encountering the tag — without waiting for an external static ad tracker script to load first.

There is also a security benefit: browsers enforce the same origin policy, which prevents scripts running on a third-party domain (such as an ad tracker) from accessing information belonging to the publisher's domain, including the parent frame.

So why isn't the iframe method universal?

The core limitation is that iframe tags cannot embed expandable or resizable banners, or rich media ads. They also make ad visibility tracking and ad verification considerably harder to implement.

There is a workaround known as a frame buster, but it requires the publisher to place a frame buster file on their own domain for each ad network they want to support — a meaningful implementation burden.

How a Frame Buster Works

A frame buster is an HTML file containing JavaScript, hosted on the publisher's domain.

Sample workflow using iframe tags with a frame buster:

The browser begins loading the page, e.g. http://example-publisher.com/
The iframe on the page loads a resource from the ad server domain (e.g. adserve.example.org), with publisher and/or placement IDs passed as GET parameters in the URL
The HTML resource loaded from the ad server embeds the frame buster file from the publisher's domain (in this case example-publisher.com) inside the iframe, establishing bi-directional communication — typically via easyXDM or a similar cross-domain messaging approach
The frame buster iframe is now controlled by code from the ad server's iframe, but because it lives on the publisher's domain, the same origin policy no longer restricts it — the script can access the publisher domain, modify the DOM, and do whatever is needed to support formats such as expandable ads
The remaining steps follow the standard JavaScript ad placement workflow: the ad tracker script loads, makes a request to the ad server for ad markup, and so on

For reference implementations, the list of popular ad network framebusters at AdOps Tools and this cross-domain iframe resize example on Stack Overflow are useful starting points.

Method #3 — The SafeFrame Standard

The SafeFrame standard, announced by IAB, was designed to address the shortcomings of both JavaScript and iframe tag implementations.

SafeFrame is built on three core components:

SafeFrame Tags (JavaScript) placed on publisher websites
SafeFrame Host, which serves SafeFrame Tags that create iframes on publisher websites and exposes APIs that allow those iframes to interact with the publisher website
External Party Ad Servers, which serve ads into SafeFrames and use the APIs to interact with the publisher website — for example, to retrieve contextual information, resize ad units, or track visibility

SafeFrame is a subject worthy of its own detailed treatment; the IAB SafeFrame information page is the authoritative reference for the full technical specification.

The standard is promising, but several meaningful problems remain, as outlined in this review by researchers from Spider.io. The main issues are:

A malicious SafeFrame Host can fabricate the information it exposes via the API
SafeFrames cannot be nested
Patents held by comScore may prevent free use of the standard

Additional Capabilities of Ad Trackers

Ad trackers can do considerably more than the core workflow described above. Common extended capabilities include:

Cookie respawning — restoring a deleted cookie using alternative storage mechanisms
User engagement monitoring — tracking how a user interacts with an ad, including how much of a video ad they watched
Ad visibility monitoring — measuring whether the ad was actually in the user's viewport
Ad rotation — requesting a new ad from the ad server and swapping it in after a defined period of display

There is ongoing industry discussion around viewable ads — ads that are visible to the user without scrolling. These tend to be more effective than non-viewable placements, though it is worth noting that on content-cluttered pages, viewable ads do not necessarily produce significantly better results.