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. [↩]

Using the OpenX local banner (website) image banner type? If so, don’t use the default storage location (i.e. the OpenX “www/images” directory). If you do use this location, then every time you upgrade OpenX, you’ll need to remember to copy your creative files over to the new OpenX code base.

Instead, create a new directory for your creative files to be stored in and served from. Make sure that this directory is outside of the OpenX code base. (Or, if you have a really large OpenX installation, consider setting up an FTP server that can be used to replicate your creative files to all of your delivery servers, and use the FTP server as your “storage location”.)

This way, you’ll never have to copy your creative files on upgrade ever again!

It doesn’t matter if you are running OpenX on a single server, or if you are running OpenX on 20 (or more!) servers. Either way, you probably want the statistics collected and displayed by OpenX to be as accurate as they possibly can be.

One very simple thing that you can do to help ensure your statistics are accurate is to ensure that on all servers where you run OpenX, you have correctly configured the system time and timezone, and that you are running a tool to ensure that your clock is synchronized with a master time source. (Clock synchronization is clearly important when running OpenX across a number of servers, but it certainly doesn’t hurt on a single server setup either!)

This is something that is very easy to do, both for Linux and Windows systems, and yet is something which The Guru very rarely sees set up. Why not update your OpenX servers today?

In the OpenX ad server, if you are not serving an HTML, text or 3rd party banner¹, then you will be serving a banner that has a creative file of some kind².

OpenX calls these image banners, and provides you with three different image banner options. Each of of these three image banner types stores the associated creative file in a different way. The three different options are:

• Local banner (SQL);
• Local banner (webserver); and
• External banner.

The OpenX administrator can even control which of these banner types are able to be used. The question is, which storage type, or types, are appropriate for your OpenX installation?

Local banners (SQL)

The local banner (SQL) type (re-named to the sql banner type in OpenX 2.7-beta), as the name suggests, is the image banner type in OpenX where the creative file is stored in the OpenX database.

As a matter of personal opinion, The Guru isn’t a fan of this banner type, because databases are generally not the ideal storage solution for large amounts of binary data. However, for most small to mid-sized OpenX users, this is often the image banner type that is used, and it provides a number of benefits:

• Simple management of banner creative files: As all the creative files are stored in the database, you only need to worry about backup of the OpenX database and OpenX code.
• Nothing to do on upgrade: As the creative files are in the database, when it’s time to upgrade OpenX, there’s nothing else to worry about with regards to the files.
• Makes life easy when growing: With creative files stored in the database, there’s no issue with adding another server to your OpenX installation, as any server that can talk to the database can serve banners.

However, there are also a couple of downsides:

• Large database size: The more creative files you store in the database, the larger your database will be, which can be a concern for smaller OpenX users, especially if shared hosting is used, as there are often associated database size limitations.
• No direct file access: It’s impossible to directly access the creative files on disk, if you should ever want (or need) to do so.
• Limited scaling: While it will be possible to add more servers to your OpenX installation, and have them serve banners, the level of scaling possible with this setup will be limited as, eventually, the database will become a bottleneck.

Local banners (webserver)

The local banner (webserver) type (re-named to the web banner type in OpenX 2.7-beta) is also exactly what you would expect; here, creative files are stored directly on the server filesystem. As before, this banner type has its advantages:

• Direct creative file access is possible: The creative files are stored on your server’s hard drive, so you can access them like normal files.
• Scales well: As the creative files are not in the database, you can replicate the files out to as many servers as you need, so scaling to huge volumes is no problem.

Of course, this is balanced by the disadvantages:

• Additional backup effort: Creative files have to be backed up in addition to the OpenX database and OpenX code.
• File replication required in multi-server setups: As the creative files need to be on the local server filesystem for delivery of banners to work, this means all creative files will need to be replicated to the local filesystem of all delivery servers if there is more than one.
• Upgrade management: It may be necessary to deal with creative files on upgrade. (This can, however, be avoided, by using an appropriate storage location for your creative files.)

External banners

The final image banner type in OpenX is the external banner type (re-named to the url banner type in OpenX 2.7-beta). As the name suggests, this is for the (normally rare) case where you will not actually be uploading the creative file for a banner into OpenX. Instead, you simply provide the URL to the creative.

As a general rule, you won’t need to use the external banner type unless:

• You are serving a 3rd party banner, but the 3rd party doesn’t provide you with an HTML tag; instead, they just give you a URL to the banner to serve; or
• You run your own creative management system externally to OpenX, and you simply want to take advantage of OpenX’s banner serving and tracking features without having to re-upload all of your creative files into OpenX, as this would essentially be a duplication of work. In these situations, use of the OpenX API from your creative management system may be appropriate, to reduce duplication of work even further!

Which to use?

Which is the right banner type to use? Apart from the external banner type, which has two very specific reasons for use, the choice is very much yours to make, based on the pros and cons of each type. However, if you’re new to OpenX, then The Guru would recommend that you start out with the local banner (SQL) type, until you gain experience with OpenX. After a while, you can consider moving to the local banner (webserver) type as your site, and ad serving requirements grow.

1. A 3rd party banner is a banner one that is served externally to your OpenX installation, usually via some kind of invocation tag code from that 3rd party. For example, banners from Google AdSense, Yahoo! Publisher Network, or from any one of the many. many ad networks out there are all 3rd party banners. [↩]
2. A creative file might be a .JPG, .GIF or .PNG image file, or a Flash file, etc. [↩]