OpenX Tips

If you are using the OpenX ad server to display banners on your website, then you are almost certainly also interested in viewing the details of the users who visit your website.

To obtain this information, some people use third party services like Google Analytics, which collects data via a tag that is inserted into a website’s pages. Other people download and install Piwik, which also uses a tag inserted into a website’s pages. However, many people still use older tools like AWStats or Webalizer to analyze their web server log files instead.

If you are using a web server log analyzer, then you should keep in mind that the calls to OpenX to request, display and log banners will probably end up being added to your web server log file¹. As a result, if you are using a tool like AWStats or Webalizer, you should consider updating the configuration of the log file analyzer to ignore, or otherwise separate out, the OpenX ad server log entries, otherwise your page hit information in these tools will be greatly over-stated.

1. This will depend on exactly how OpenX is installed, and how your web server logging has been configured [↩]

Great news! Long time OpenX community member Heiko Webber has announced a patch to allow the OpenX ad server to display statistics by country.

Although the OpenX plugin framework in OpenX 2.8 clearly needs further work by the OpenX team, as Heiko has been forced to release this functionality as a patch, rather than a separate plugin, this is still great news for all OpenX ad server users who have been missing this feature.

Thanks Heiko!

Here’s a great question from reader Tabrez:

Let’s say we have a newspaper website, and we want to have a hierarchy of zones. Should we have (for example) a Sports News zone that then daisy-chains to an All News zone? Or should we use source params etc. What’s better, when?

Similar questions appear on the OpenX forum from time to time as well.

There are actually two different — although related — questions for the price of one here. The first question is, what is the best way to deal with site segments on my website? The second is, how do I deal with hierarchies on my website?

Let’s look at each question in turn.

Site segmentation

Some websites have multiple segments. For example, in Tabrez’s question above, his newspaper centric website will obviously have many different news segments — he’s highlighted that “Sports News” and “All News” as just two of these segments.

If your website has multiple segments like this, then selling advertising based on the different segments is probably a good idea, as it should allow you to provide your advertisers with a more specific target audience, and thus command better rates.

Of course, this means that you need to be able to manage your advertiser’s banners so that they show up in the appropriate segment(s) of your website. So, what’s the best way to manage this with the OpenX ad server?

As Tabrez suggests, there are essentially two different approaches — you could create a separate zone for each segment of your site (i.e. use multiple zones), or you could have just the one zone that is used across the whole site, but use delivery limitations (i.e. banner targeting) to ensure the banners are delivered in the correct segment(s) of your site.

But which of these two approaches is the “best” approach?

The answer, as so often is the case with a very powerful and flexible system like the OpenX ad server, is that there are a number of pros and cons for each of the two approaches, so which is “best” will depend on what works best for you! Here are The Guru’s thoughts on the two different approaches…

Multiple zone approach

The pros of using a different zone for each segment of your site are:

• As each segment in your site is a separate zone in OpenX, and because it is possible to view OpenX statistics by zone, this means that it is possible to view all of the OpenX delivery data in the statistics screen by site segment. This includes the ability to see how each banner is performing on a per-zone (i.e. per-site segment) basis. This information is not available when using the banner targeting approach to site segmentation.
• Provided that your zones are clearly named, ideally with some form of naming convention, then once you have configured all of the different zones, management of your advertiser’s banners should be very simple, as “targeting” banners to given segments of your site is simply a matter of linking the campaigns and/or banners to the appropriate zones. As the linking of campaigns/banners zones is something that you would do anyway in OpenX, this means that the multiple zone approach to site segmentation introduces no additional management overhead.

The cons of using a different zone for each segment of your site are:

• Although the multiple zone approach to site segmentation means there is no additional management overhead once you are up and running, there is potentially a high initial set up cost associated with the approach, in the event you have many different segments on your site. This is because you need to set up all of the separate zones in OpenX, generate the zone tags for each zone, and then ensure that these tags are placed correctly in the different segments of your site.
• If you have advertisers that run campaigns where the campaign banners are not always displayed in the same website segments, then this approach will mean that you cannot link campaigns directly to zones — you will need to manage the zone links at the banner level. This may introduce additional work, especially if there are many banners per campaign.
• If you do not use an appropriate naming convention for your zones, or you have many hundreds or thousands of site segments, then the OpenX screens for managing campaign/banner to zone linking may be slow, and it may also be difficult to find the appropriate zone(s) to link to, simply as a result of the number of zones in the system.
• If you have segments on your website that receive very small numbers of page views, then you may find that these zones do not effectively deliver Contract campaigns. This is because the OpenX Maintenance Prioritisation Engine depends on zones having a reasonable number of impressions per hour to be able to accurately prioritise banners — if there are very few impressions per hour in some of your segments, using banner targeting to segment your site may be preferable.

Banner targeting approach

The pros of using banner targeting to target banners to different segments of your site are:

• There is almost no initial setup required to start targeting banners to a segment of your website. Simply enter the required banner delivery limitations that will ensure that your banner appears only in the required site segment, and you are done¹!

The cons of using banner targeting to target banners to different segments of your site are:

• As the site segmentation is being performed with delivery limitations, and because delivery limitations can only be applied at the banner level in OpenX, this means that every single banner that is to be targeted to a site segment needs to have delivery limitations applied, which introduces an ongoing additional management overhead².
• Unlike the multiple zone approach, it will not be possible to view the OpenX delivery data for banners on a per-site segment basis. As there is just one zone across the whole site, banner delivery data will simply be logged against this zone, no matter which site segment a banner’s impression occurs in.
• If you have segments on your website that receive very small numbers of page views, then you may find that banners in Contract campaigns that are targeted to these segments can cause the OpenX Maintenance Prioritisation Engine to cause other Contract campaigns in the system to delivery incorrectly, due to issues with dealing with very highly targeted Contract campaign banners.
• Debugging delivery issues where a banner is being displayed in an incorrect site segment may be more difficult than with a multiple zone approach to site segmentation, due to the potential complexity of the banner delivery limitations.

Conclusion

Performing site segmentation is a balancing act. The pros and cons of the two different possible approaches probably seem difficult to weigh up, especially if you have not previously tried both approaches.

To make life simpler, The Guru recommends that if you have not performed site segmentation before, you select an approach based on how many site segments you have. That is, if you have only a dozen or so site segments, then use the multiple zone approach, as this will not be too difficult to setup, and with a small number of site segments, you are not likely to suffer from the many of the cons of this approach. However, if you have more site segments that this, try the banner targeting approach.

Keep in mind that if this is your first time using site segmentation, no matter which approach you first try, you can always experiment with the alternate approach later, should you find that the initial approach is not suitable for your needs for one reason or another.

Finally, it is worth pointing out that you can actually combine the two approaches. That is, you can always partially partition your site via multiple zones, and then further partition each zone into smaller segments via banner delivery limitations. This approach will of course require balancing at which level you stop multiple zone based segmentation and move to banner targeting based segmentation, but with time and practice, you will learn to get most of the pros, while avoiding most of the cons.

Zone hierarchies

The concept of a zone hierarchy is related to the idea of site segmentation. Think about it this way — if you have divided up your website into segments for the purpose of selling your inventory at a higher rate, what do you do when when you have spare inventory in a site segment?

The answer, for once, is reasonably simple. If you have used multiple zones to manage your website’s segments, then using zone chaining to create a hierarchy of zones is the correct approach. That is, if you have a zone that represents a site segment (e.g. the “Sports News” segment zone from Tarbrez’s question), and you find that that the site segment/zone has spare inventory, then the easiest way to ensure that a banner is shown is to link the zone via zone chaining to the next zone “down” in the zone hierarchy. In Tabrez’s example, this sounds like it would be the “All News” segment zone. Of course, you can have as many levels of zone changing as you need in your zone hierarchy³.

If, however, you have used banner targeting to manage your website’s segments, then a zone hierarchy doesn’t really apply. Presumably, advertisers that are buying inventory in your site segments will be doing so via the Contract (Exclusive) or Contract campaign types, and so you can simply link any Remnant campaigns, containing un-targeted banners, to the single, site-wide zone in OpenX. These Remnant campaign banners will be shown whenever there is spare inventory that is not used by your segment-specific advertiser campaigns, due to the way that the banner delivery process will only show banners from Remnant campaigns after it has determined that there are no banners to be displayed from any Contract (Exclusive) and Contract campaigns⁴.

1. Of course, some delivery limitation types may require additional work before they can be used. In the original question, it was suggested that “source parameters” would be used. To be able to target with source parameters, the Site – Source delivery limitation type requires that changes to the zone tags will need to be made so that the appropriate source parameters are passed into the OpenX ad server calls and allow the targeting to be performed. For this reason, the Site – Page URL delivery limitation type may be more suitable to perform site segmentation, assuming that you are able to accurately determine site segments via your website’s URL. [↩]
2. This can be somewhat reduced by appropriate use of targeting channels, however. [↩]
3. There is a performance penalty for each level, of course, so try not to have a zone hierarchy that is too deep. [↩]
4. If you are not using the Contract (Exclusive) or Contract campaign types for your segment targeted advertiser campaigns, then a two zone hierarchy would be appropriate — an “initial zone” that is linked to all of the campaigns containing banners that are site segment targeted, which is then linked via zone chaining to a “remnant zone”, containing all of the untargeted banners. [↩]

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

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?