On This Page:

Requests Higher than Impressions.

A troubleshooting guide to help when the number of impressions recorded in the Revive Adserver statistics are significantly lower than the number of requests.

Symptoms

The number of impressions being recorded for advertisers, campaigns and banners and/or websites and zones are significantly lower than the number of requests.

Background

As soon as Revive Adserver has determined which banner will be displayed, this is logged as a request.

When using an Image Tag, No Cookie Image Tag or XML-RPC Tag, Revive Adserver will also log the impression at this point, as there is no other way for these tags to record impressions.

However, when using any other kind of Zone Tag, or when using the website-level Single Page Call Tag, then Revive Adserver uses a "beacon" to record the impression - that is, after the banner has been loaded, an invisible element is loaded in the page which calls back to Revive Adserver to let it know that the banner has been successfully loaded in the web browser.

This is done to provide a more accurate record of the number of banners that are actually loaded (i.e. impressions) vs. the number of requests to load banners (i.e. requests).

Troubleshooting Process

Step 1: Review Single Page Call Tags

If you are using Single Page Call Tags, review your use of the tags. By default, Revive Adserver will load a banner for every zone in the website, even if you're then only displaying some of the zones on the page. This can lead to a high number of requests vs. impressions.

To limit the zones that an SPC Tag will select a banner for, simply add the following code to your page above the SPC Tag:

<script type='text/javascript'><!--// <![CDATA[
    var OA_zones = {
      'zone1' : 1,
      'zone4' : 4
    };
// ]]> --></script>

In the above case, this will limit the SPC tag to simply loading the zones with the name/ID pairs shown.

Step 2: Review Load Performance

Probably the most common reason for a significant difference in requests vs. impressions, however, is banner loading performance. Any banner that takes a long time to load, relative to the rest of the page, is likely to significantly increase the "drop off" rate - that is, the rate of users who visit a website, which results in banner requests being logged, but who then "navigate away" to another page (on the site, or elsewhere) before some (or all) of the banners have actually loaded.

In particular, you should consider looking for:

Large banner creatives, such as very large image files, Flash banners or complex HTML5 banners; and
Banners which are served from 3rd party networks (possibly from a series of chained 3rd party networks), which are slow to load (relative to the rest of the page).

Using a tool such as YSlow, Firebug or one of the many others that provide an analysis of the total page load time can often help you to see and understand the difference in performance between the time required for the web page to load vs. the time required for all the banners to load.

Step 3: Review Server Performance

If you're not selecting banners via an SPC Tag for zones that you never display, and the load performance of your banner creatives is reasonable relative to the load performance of your page, you will need to review the performance of your Revive Adserver installation.

Poor performance on the Revive Adserver server (in general terms - not having enough memory, CPU or disk I/O performance to meet the load demands of the server under load) can result in poor banner creative load time and/or lost data, as the server fails to respond to e.g. impression beacon requests, and users' web browsers time out. This can also lead to "missing" impressions when compared with the request levels.

Step 4: Consider Tag Type

The issue of slow loading banner creatives and/or poor server performance can be particularly exacerbated by the use of the SPC Tag and the Asynchronous JS Tag, because these tags are specifically designed to allow web pages to fully load first, and then load the banners afterwards.

While allowing the page to load first, and then loading banners afterwards is a good thing for the user's experience, if either of the above two issues (slow loading banners and/or poor server performance) exist, then these tags will make the problem much more obvious, as users "navigate away" from pages before banners finish loading.

If you absolutely cannot address the creative load time and/or server performance, you may want to consider using another tag type. This will give the website user a worse experience (that is, an overall slower page load time) in exchange for a higher number of banner impressions.