Ads are generally delivered to user by two method
- server-initiated
- client-initiated
Server initiated:
Ad counting uses the site’s web content server for making requests, formatting and re-directing content.
Client-initiated:
ad counting relies on the user’s browser to perform these activities (in this case the term“client”refers to an Internet ‘user’ browser).
Inview impression counting used client initiated ad serving because server initiated will record impression though user actually preview the creative or not (creative load at Below the fold “BTF”)
The following details are key components of the Guideline:
A valid ad impression may only be counted when an ad counter receives and responds to
an HTTP request for a tracking asset from a client. The count must happen after the initiation of retrieval of underlying page content. Permissible implementation techniques include (but are not limited to) HTTP requests generated by <IMG>, <IFRAME>, or <SCRIPT SRC>.For client-side ad serving, the ad content itself could be treated as the tracking asset and the ad server itself could do the ad counting.
The response by the ad counter includes but is not limited to:
- Delivery of a“beacon,”which may be defined as any piece of content designated as a tracking asset. Beacons will commonly be in the form of a 1×1 pixel image, but the Guideline does not apply any restrictions to the actual media-type or content-type employed by a beacon response.
- Delivery of a“302”redirect or html/javascript (which doubles as a tracking asset) to any location, and
- Delivery of ad content
The ad counter must employ standard headers on the response, in order to minimize the
potential of caching. The standard headers will include the following:
• Expiry
• Cache-Control
Caching Guidelines
Cache busting techniques are required for all sites and ad-serving organizations. The following techniques are acceptable:
1. HTTP Header Controls
2. Random Number assignment techniques to identify unique serving occurrences of pages/ads.
Compound tracking:
Tracking assets (“beacon”or tracker) it can register multiple ads that in diffrent location present on the page.
This only can be manage only if we put the assets at the end so that all ads will get load first then tracker being called.
for example if have used single asset for 728×90,300×250,160×600 ad then place asset after 160 so that it will insure that 728×90 and 300×250 ad is loaded.This kind of tracker is called as “compound tracking”
How to implement compound tracking
- As a recommendation, sites should ensure that every measured ad call is unique to the browser.
- There are many valid techniques available to do this, (including the generation of random strings directly by the server, or by using JavaScript statements to generate random values in beacon calls).
- Compound tracking make sure that all grouped ads load prior to counting, for example through placing the tracking asset at the end of the HTML string.
- Use of compound tracking necessitates that the ad group can only be counted if reasonable assurance exists that all grouped ads load prior to counting, for example through placing the tracking asset at the end of the HTML string.
Other Ad-Impression Considerations
- Robot filtration guidelines are presented later in this document. Appropriate filtration of robotic activity is critical to accurate measurement of ad impressions.
- Media companies and ad serving organizations should fully disclose their ad impression recording process to buyers and other users of the ad impression count data.
