OpenX Tips

If you have read The Guru’s article on how the banner delivery process works in the OpenX ad server, then you may have noticed that when a banner is delivered, two items of data are logged — a request, and an impression¹.

Understanding the difference between requests and impressions is important, and once understood, can provide you with some interesting insight into your OpenX banner delivery performance.

Requests and impressions in the OpenX database

Before diving into the difference between requests and impressions, it’s useful to understand where requests and impressions are logged.

If you are running OpenX 2.4 or OpenX 2.6, then requests are logged into the “data_raw_ad_request” table², while impressions are logged into the “data_raw_ad_impression” table.

If you are running OpenX 2.8, then requests are logged into the “data_bkt_r” table, while impressions are logged into the “data_bkt_m” table.

If you have never done so before, log into your OpenX database now, and take a quick look at the contents of these tables — but be careful! These tables, especially in the older OpenX 2.4 and OpenX 2.6 versions, can become very large, so running SQL commands on these tables may take a very long time and may even impact the performance of your server. As a result, it is generally worth limiting the number of rows you look at when you inspect these tables. For example, you might use the following commands³:

OpenX 2.4 & OpenX 2.6

SELECT * FROM data_raw_ad_request ORDER BY date_time DESC LIMIT 20;

SELECT * FROM data_raw_ad_impression ORDER BY date_time DESC LIMIT 20;

OpenX 2.8

SELECT * FROM data_bkt_r ORDER BY interval_start DESC LIMIT 20;

SELECT * FROM data_bkt_m ORDER BY interval_start DESC LIMIT 20;

You should see some of your logged request and impression data.

If you are not seeing any request or impression data at all, have you delivered any banners recently? Try delivering some banners, and see if you can now see requests and impressions logged.

If you see impression data, but no request data, and you are using OpenX 2.4 or OpenX 2.6, do you have request logging enabled? Check:

• In OpenX 2.4: While logged in to OpenX as the administrator account, go to Settings, Main Settings, Statistics and Maintenance Settings, and check if the “Log an Ad Request every time an advertisement is requested” setting is enabled.
• In OpenX 2.6: While “working as” the “Administrator account”⁴, go to My Account, Global Settings, Banner Logging Settings, and check if the “Log a request every time a banner is requested” setting is enabled.

Please be aware, however, that as OpenX 2.4 and OpenX 2.6 don’t have the newer, faster logging system that was introduced in OpenX 2.8, enabling request logging on an OpenX 2.4 or OpenX 2.6 system is likely to add significant additional load to your server. Think carefully before deciding to enabling this setting, and ensure that you monitor your OpenX server carefully after to make sure that the server’s performance is still okay.

Requests and impressions in the OpenX user interface

Now that you’ve seen the request and impression data in the OpenX database, and confirmed that it is being logged, it makes sense to ensure that this data can be seen in the OpenX user interface. By default, impression data will be viewable in the OpenX user interface, but request data is not viewable. To enable the ability to view request data in the user interface:

• In OpenX 2.4: While logged in to OpenX as the administrator account, go to Settings, Main Settings, Interface Defaults. Here you find a list of the various columns OpenX can display in the user interface’s various statistics screens. If it is not enabled, and you would like view requests in the statistics screens, check the “Show Requests column” setting for those account types you would like to be able to see requests.
• In OpenX 2.6: While “working as” the “Administrator account”⁵, go to My Account, Account Preferences, User Interface Preferences. Here you will find a list of the various columns OpenX can display in the user interface’s various statistics screens. If it is not enabled, and you would like to view requests in the statistics screens, check the “Requests” setting. You can also change the order in which the viewable columns are displayed by changing the “Column Rank” numbers.
• In OpenX 2.8: While “working as” the “Administrator account”⁶, go to My Account, Preferences, User Interface Preferences. Here you will find a list of the various columns OpenX can display in the user interface’s various statistics screens. If it is not enabled, and you would like to view requests in the statistics screens, check the “Requests” setting. You can also change the order in which the viewable columns are displayed by changing the “Column Rank” numbers.

Note that while OpenX 2.4 provides a facility for the administrator account to control which columns the four account types that exist in OpenX 2.4 can see, this is not possible in OpenX 2.6 and OpenX 2.8, where every account can modify which columns they want to view themselves — the above instructions simply change the master default account preferences for the “Administrator account” which all other accounts inherit their preferences from.

So, what’s the difference, and why do I care?

If you read the article on the banner delivery process carefully, you will note that a request is logged as soon as the OpenX ad server has determined which banner it is going to display. However, an impression is not logged until after the banner has actually been displayed⁷.

You will notice, if you are logging requests and impressions, and displaying both columns in the user interface, that as a general rule, the number of requests are greater than the number of impressions. The difference between requests and impressions is generally referred to as the drop off rate. A “high” drop off rate is bad for two reasons:

1. If your OpenX server is performing work selecting banners that are never shown, then your server is doing work that is irrelevant — so, your server performance is less than it could be, which is costing you money.
2. If users are viewing your web site, and requesting banners, but the banners are not being displayed, then you are losing out on income — regardless of if your campaigns are paying you on a CPM, CPC or CPA basis, if the banners don’t show up, you won’t get paid.

So, what is a “high” drop off rate? There is no industry defined standard that The Guru is aware of, but anything more than 10% would certainly be cause for concern, and even drop off rates lower than this may represent a significant reduction of potential income for some sites. The only real rule here is that the lowest possible achievable drop off rate is desirable.

How do I fix a bad drop off rate?

This, of course, is the big question. The way to fix a bad drop off rate is to identify why banners are being selected for display, but are not actually being displayed, and to then act accordingly. Here are some of the top reasons for banners failing to display, and suggestions on how to address these issues:

Incorrect use of the Single Page Call tag

The Single Page Call tag calls OpenX just once, to obtain a banner for all of the zones that are to be displayed on a page. By default, the Single Page Call tag selects a banner for all of the zones in a website. So, if only some of the zones are going to be displayed on a page, then the tag needs to be edited before it is used, to ensure that banners are not selected that will never be displayed.

Large banner file sizes

If the file size of a banner is very large (e.g. large flash banners, etc.) then users with slower internet connections may “navigate away” from a page before the banner has finished downloading to their computer. Try to avoid using having very large banner file sizes, or, if this is essential, consider purchasing the MaxMind NetSpeed database, which will allow you to target large file size banners to users with faster internet connections only, while targeting alternative, smaller file size banners to those on dial-up connections.

Slow 3rd party banners

Many OpenX users will generate a large part of their income from ad networks, who supply an HTML tag that loads banners from the ad networks’ servers. It is an unfortunate fact of life that sometimes, the 3rd parties’ servers are not always as fast as would be desired. The only real option here is to monitor the drop off rate at the banner level in the statistics pages, and see if there are particular ad networks that are causing you persistent problems — and if there are, consider the income they generate. If they are not a major part of your income, perhaps dropping these ad networks may result in overall better income for your site.

Slow websites and poor banner placement

If your website itself is slow to load, then as with large banners, users can sometimes “navigate away” from a page before the page has finished loading. In these cases, banners that are placed towards the bottom of the page may not get a chance to complete loading before the user goes elsewhere. Upgrading your server to ensure your web site loads quickly at all times will help, as may re-considering your website design and banner placement.

1. OpenX 2.8 introduced request and impression logging by default. In OpenX 2.6 and 2.4, request logging was optional, and not enabled by default. [↩]
2. If request logging is enabled. [↩]
3. You may need to edit these example commands, if your OpenX installation uses a database table prefix, e.g. “phpads_”, “oa_”, “ox_”, etc. [↩]
4. You will need to be logged into OpenX as a user that has permission to act as the “Administrator account”. [↩]
5. As before, you will need to be logged into OpenX as a user that has permission to act as the “Administrator account”. [↩]
6. As before, you will need to be logged into OpenX as a user that has permission to act as the “Administrator account”. [↩]
7. There is one exception to this rule, which results in the request and the impression being logged at the same time. As mentioned in the banner delivery process article, this is when an Image, No Cookie Image or XML-RPC zone tag is used to deliver a banner, because these tags do not support the logging of impressions via a logging beacon. [↩]

Check out the free replacement icon set for OpenX 2.8 from EsDeveloped.

The Guru has, and it’s rather good!

One of the most useful screens in the OpenX ad server is the zone probability page. There’s an incredible amount of information that you can get from this screen about what’s happening with regards to banner delivery in your zones, if you know how to understand the information presented.

What’s linked and active?

The most immediately obvious information on the zone probability screen is the list of all banners that are linked and active¹ in the zone. The fact that the zone probability screen only shows active banners can be useful, as it allows you to easily see the difference between banners that are active in the zone, and any banners that are merely linked to the zone, as shown on the linked banners screen.

The zone probability screen showing only one active linked banner.

The zone linked banners screen, showing two linked banners -- one of which is inactive.

What’s targeted and/or capped?

Any banner in OpenX can have delivery limitations or capping applied, to target the delivery of the banner to certain users of your website. However, targeting or capping not only applies to your users, it also applied to you when you are viewing your site. Sometimes, that means that when you view your own website, you won’t see some of the active banners linked to the zone!

As a result, it’s often important to know exactly which banners have targeting or capping applied. The zone probability screen makes seeing which banners in a zone are targeted or capped very easy.

The zone probability screen showing which banners are targeted and capped.

What’s the approximate probability of seeing a banner?

The probability column of the zone probability screen shows, as you would expect, the approximate probability of OpenX delivering each of the active banners that are linked to the zone.

The probabilities shown are only approximate as a result of delivery limitations and capping.

• When delivery limitations and capping rules are applied to Contract (Exclusive) and Remnant campaign banners, then the banners will usually be shown less often than the probability shown. This is because the delivery limitations and capping reduce the available inventory that the banners can be displayed in.
• The OpenX Maintenance Prioritization Engine has code to compensate for the effect of delivery limitations and capping rules that are applied to banners in Contract campaigns. However, in The Guru’s experience, this compensation often means that the probability values shown on the zone probability screen for Contract campaigns are often, well, rather odd. This is because banners that are very highly targeted² are given a very high probability — but because of the fact that during the banner delivery process, banners that cannot be displayed are discarded, and then the priority values are re-calibrated, this means that the un-targeted Contract campaign banners with apparently low probabilities on the zone probability screen actually end up with much higher probabilities after re-calibration.

Are Contract campaigns over-subscribed?

If you’ve read The Guru’s article on how the OpenX banner delivery process works, you will know that a banner from a Contract campaign may not deliver on every impression, in the event that the OpenX Maintenance Prioritization Engine has decided that not every impression is required to be used up to allow the Contract campaigns to meet their delivery targets.

The converse of this is that if you run Contract campaigns in a zone, and if almost every impression in the zone is being used by a Contract campaign, then it might be the case that there is not enough inventory in the zone for the Contract campaigns to meet their delivery targets — a condition known as the zone being “over-subscribed”.

You can easily identify this situation by looking at the probability of your Remnant campaign banners in the zone — in particular, look at your “guaranteed delivery” campaign banner. If the probability is zero (or very close to zero), then your Contract campaigns in the zone are using up all of the inventory (or almost all of it) — and so the Contract campaigns may not be delivering to contract. If you see this, you may want to investigate the linked Contract campaigns to inspect their delivery progress — you may need to take action and update the campaign if it is not delivering sufficiently quickly!

The zone probability screen showing a Contract campaign using almost all of the zone's inventory, which may indicate an over-subscribed zone.

1. A banner is considered to be active if it’s in a campaign that is currently active — that is, is within its start and end dates, if they are set, and has not been disabled due to the campaign meeting its delivery targets, again, if it has any. Additionally, the banner itself must be active within the campaign. [↩]
2. That is, targeted to a very small part of the total zone inventory. [↩]

The last thing you want on your website is a “blank” banner. Not only might it make your website look “wrong”, it also means that you are not making any money!

If you understand the OpenX ad server banner delivery process, then you will be able to appreciate that the last place OpenX looks for a banner to deliver when all else fails is in any Remnant campaigns linked to your zone¹.

As a result, unless you have your zone set up to be chained to another zone in the event that no banner can be displayed, The Guru recommends that you always have at least one banner from a Remnant camapaign in your zone with no delivery limitations or capping applied, so that if all else fails, this banner is guaranteed to be able to deliver, and save you from the embarassing situation of having a “blank” banner showing.

1. If you don’t count the default banner, of course, but this is a somewhat limited fall-back type, as it only supports a single image banner — you would not be able to use the banner tag from an ad network as the default banner, for example, as these generally come in the form of an HTML tag. [↩]