OpenX Tips

Here’s a great question from reader Komson, who writes:

Dear Guru,

We are using OpenX, and we are facing a problem — the server “goes down” at peak times.

Can you please shed some light on the maximum number of impression per hour, in general, you recommend you should not go over?

e.g. you should not serve over 150,000 impressions per hour.

Thanks in advance!

Here’s a question in response:

I’m planning a party. I’ve already bought some food. How many people can I invite?

It’s a somewhat flippant question, for sure, but hopefully you get the idea — it’s not possible to answer the question of how many people can come to the party without knowing more about the situation. To be able to accurately determine how many people can be invited to the party, you will need to know:

• How hungry do you expect the guests to be? Are they going to be happy getting just a few snacks, or will they will be expecting a full meal?; and
• How much food do you have for the party?

The same thing goes for answering the question about how many impressions per hour you can serve with OpenX.

First up, there’s the question of how much you want to “feed” to your guests. You may be aware that in computing, there are two different ways of measuring “performance”. There’s throughput¹, and response time².

Obviously, users of your web site won’t care about throughput³ — all they care about is response time, because they don’t want to sit around waiting for ages while your website loads. They want it to load now.

So, this is the question of how “hungry” your guests are — they want to be fed, and chances are they want to be fed now, but how much food do you need to ensure all of your guests are well fed? In this case, though, given that you’ve already bought the food (i.e. you’ve already got OpenX installed and set up ready to go on a server you’ve bought, or a hosted service you’ve paid for), its more useful to ask: how many guests can you invite to the party and still ensure everyone gets a good feed? That is, how many impressions per hour can you serve, and still ensure that your website loads quickly?

Of course, if we were really talking about food that you had bought for a party, then once you’ve decided how much you think people will want to eat, it would be pretty obvious by just looking at it how much food you have as to how many people you would be able to feed with it. Naturally, things aren’t quite so simple with an OpenX installation. How much “food” do you really have, so you can figure out how many people can come? That is, once you’ve decided what the maximum average response time you want your users to experience is, how many impressions per hour can you serve with your existing hardware before you will start having a response time that is worse than this?⁴

Unfortunately, there’s only one way to figure this out — you have to measure it!

Luckily, OpenX have actually provided some scripts⁵ to take some of the pain out of measuring your ad server performance, but unfortunately, in the end, if you want to really know how many impressions per hour your OpenX installation can serve, while still keeping people happy, then unfortunately, you have to do some work.

Finally, before you dive into the task of measuring performance (or, if you’ve done so already, and you’re not happy with the results), don’t forget that the OpenX blog has three different articles that all relate to performance — these are definitely worth reading, especially if you have an OpenX ad server installation that is having performance issues!

1. Throughput is a measure of the number of units of work that can be performed per unit time. So, in this case, it is the number of impressions per hour that your OpenX installation can serve. [↩]
2. Response time is a measure of how long it takes to get a response — that is, how long does it take from the moment a user requests a banner from your OpenX installation until the banner is displayed in the user’s web browser. [↩]
3. You obviously care about throughput, as this is the whole point of the original question — how many impressions per hour can you serve from your OpenX installation? However, your can be assured that your website users won’t care about this. [↩]
4. If you want to get really technical, you can also consider what the maximum standard deviation you will allow as well, to address the case of those response times that are greater than the average response time. Think of the standard deviation of the average response time as a measure of that annoying thing that happens at a party where, although there is plenty of food, the people who are standing nearest to the kitchen eat it all, while people furthest away from the kitchen go hungry while they stand around waiting for the plates of food to get passed to them. The greater the standard deviation, the more hungry people will be getting angry in the far corner of your party. [↩]
5. The OpenX scripts page indicates that they are for testing new installations of OpenX before they are put into production. While this is obviously the ideal case, it’s still possible to do performance testing on a live installation — but do the performance testing off-peak (e.g. the middle of night) so that you won’t have many users looking at your website if you end up pushing your server too hard, and you have really bad response times during testing. [↩]

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

Sometimes, users who are new to the OpenX ad server find that they struggle to get OpenX to deliver banners. Even experienced OpenX users can sometimes run into difficulties with banner delivery issues.

As you may imagine, there are may different reasons why OpenX might not be delivering banners, so there is no single solution to this problem. Fortunately, the process of diagnosing OpenX banner delivery problems is not a difficult task! Just walk through the following banner delivery troubleshooting check-list…

#1.0: Are any banners delivering?

Is the OpenX ad server at least delivering some banners (even if they are not the ones you want), or is it delivering no banners at all? If at least some banners are being delivered, move on to item #2.0 in the check-list, otherwise if no banners are being delivered at all, proceed with item #1.1 below.

#1.1: Are you using direct selection?

If you are trying to deliver banners from OpenX using direct selection, instead of by using a zone tag, then try to deliver some banners via zones first. Direct selection is known to be a very complex and difficult process, and is really only intended for advanced users of OpenX. If you’re unable to get banners delivering, chances are you’re not an advanced user just yet — so, try using zone tag delivery instead.

#1.2: Have you re-generated the zone tag?

Sometimes, the reason why banners are not delivering is due to a simple cut & paste error. Try re-generating the zone tag, and cut & paste it into your website again, to see if this helps.

If it doesn’t, try putting the zone tag into a very simple HTML page, with no other content. It might be that there is some kind of conflict between your page’s content and the zone tag. Putting the zone tag into a plain HTML page will allow you to ensure that this is not the case.

#1.3: Have you tried a different zone tag type?

It may be that there is a problem with the zone tag type you have selected, or it may be that the zone tag type you are using is not suitable for the banners you have linked — for example, the Image tag can only display actual image banners; and HTML banner would not be able to be displayed by the Image tag.

Try another zone tag type, and see if that helps. As a general rule, the Javascript zone tag type should work in a plain HTML page, when viewed with a normal web browser.

#1.4: Are you certain there are active banners in the zone with probabilities greater than 0%?

Have you checked the zone probability screen for the zone you are generating the tag for, to ensure that there is at least one active banner linked to the zone with a probability greater than 0%? If there are no such banners, you will need to link some active banners to the zone, so that they can be displayed!

Alternatively, if you are relying on zone chaining to send you to a secondary zone in a case where the zone you have generated the tag for has no active banners, try generating the secondary zone’s tag and using this directly, to see if this helps — perhaps you haven’t got the zone chaining setup as you might expect.

#1.5: Are you certain that there is a “guaranteed delivery” banner in the zone?

Many is the time that The Guru has been called in by a client who is complaining that one of their zones is not displaying any banners, and it has turned out that, for example, all of the banners linked to the zone are limited to only display once per day, and all of the banners have already been seen by the client that day — resulting in there being no banners left in the zone that can possibly be displayed.

As there are many different forms of delivery limitations and/or capping that may result in banners not being displayed, double check that you have at least one “guaranteed delivery” banner linked to your zone, to ensure that at least this banner can be displayed if all others cannot.

#1.6: Are you running an ad blocker?

Ad blockers like Adblock Plus can, rather obviously, prevent banners from showing. If you have an ad blocker installed, try disabling it to see if that helps!

#1.7: Diagnose the web server calls made by the zone tag

If the above steps have not helped, then the chances are that something is going wrong on your web server when the zone tags are called. To try to diagnose what the problem is, you will need to investigate the process of the calls to the web server itself.

As an example, consider this plain HTML page containing nothing but a single OpenX Javascript zone tag in it, running on an OpenX ad server installation on the “www.example.com” domain:

<html>
<head>
  <title>Text OpenX Page</title>
</head>
<body>

<!--/* OpenX Javascript Tag v2.8.0 */-->
<script type='text/javascript'><!--//<![CDATA[
  var m3_u = (location.protocol=='https:'?'https://www.example.com/openx/www/delivery/ajs.php':'http://www.example.com/openx/www/delivery/ajs.php');
  var m3_r = Math.floor(Math.random()*99999999999);
  if (!document.MAX_used) document.MAX_used = ',';
  document.write ("<scr"+"ipt type='text/javascript' src='"+m3_u);
  document.write ("?zoneid=1");
  document.write ('&amp;cb=' + m3_r);
  if (document.MAX_used != ',') document.write ("&amp;exclude=" + document.MAX_used);
  document.write (document.charset ? '&amp;charset='+document.charset : (document.characterSet ? '&amp;charset='+document.characterSet : ''));
  document.write ("&amp;loc=" + escape(window.location));
  if (document.referrer) document.write ("&amp;referer=" + escape(document.referrer));
  if (document.context) document.write ("&context=" + escape(document.context));
  if (document.mmm_fo) document.write ("&amp;mmm_fo=1");
  document.write ("'><\/scr"+"ipt>");
//]]>--></script>

</body>
</html>

When a user’s browser sees this code in the page, a number of calls are made to different URLs on your OpenX server. You can actually see these URL calls by using tools like iehttpheaders for Internet Explorer, or LiveHTTPHeaders for Firefox. Here are the URLs that are called when the above page is viewed:

• http://www.example.com/openx/www/delivery/ajs.php?zoneid=1&cb=15028591281&charset=UTF-8&loc=http%3A//www.example.com/test.html

• http://www.example.com/openx/www/delivery/ai.php?filename=468×60.gif&contenttype=gif

• http://www.example.com/openx/www/delivery/lg.php?bannerid=2&campaignid=1&zoneid=1&loc=http%3A%2F%2Fwww.example.com%2Ftest.html&cb=0c9f6849c2

You can probably tell from the above that the first URL called obtains the code required to display the banner, the second URL called obtains the actual banner image, and the third URL called is the call to the 1×1 .gif logging beacon to record the impression after the banner has been displayed. For the purpose of debugging why no banners are being delivered, the first URL called is the most important, as it is the call to get code to display the banner.

Putting the first URL into a browser returns something like the following:

var OX_cacd23fb = '';
OX_cacd23fb += "<"+"a href=\'http://www.example.com/openx/www/delivery/ck.php?oaparams=2__bannerid=2__zoneid=1__cb=b5fcef6ca8__oadest=http%3A%2F%2Fwww.openxtips.com%2F\' target=\'_blank\'><"+"img src=\'http://www.example.com/openx/www/delivery/ai.php?filename=468x60.gif&contenttype=gif\' width=\'468\' height=\'60\' alt=\'\' title=\'\' border=\'0\' /><"+"/a><"+"div id=\'beacon_b5fcef6ca8\' style=\'position: absolute; left: 0px; top: 0px; visibility: hidden;\'><"+"img src=\'http://www.example.com/openx/www/delivery/lg.php?bannerid=2&amp;campaignid=1&amp;zoneid=1&amp;loc=http%3A%2F%2Fwww.example.com%2Ftest.html&amp;cb=b5fcef6ca8\' width=\'0\' height=\'0\' alt=\'\' style=\'width: 0px; height: 0px;\' /><"+"/div>\n";
document.write(OX_cacd23fb);

This is the Javascript that actually writes out the HTML for displaying the banner.

Obviously, the above examples will be different on your OpenX ad server installation, as you won’t be using “www.example.com” as your domain name, you may have OpenX installed in a different path, and you may be using a zone tag that does things in a different way to the Javascript zone tag. However, the basic process is the same — if you view the URL calls being made to your OpenX ad server when you view a simple page containing your zone tag, the first URL called should be the one that, if then called separately in a browser, returns code to produce the banner contents.

If you find that no banner contents are being returned by this call, then something is wrong with your ad server installation that is preventing the banner contents from being returned. Generally, this can be diagnosed by the following steps.

#1.7.1: Check the web server logs

Look at your web server logs, and try to find instances of the URL call that returns the banner contents. These may be in a separate error log from the normal log, if an error is occurring when the URL is called. Your log should help you determine why the call is failing. The two most common reasons for this failing are:

• An incorrect permission on a file or directory, which is preventing the web server from reading either the OpenX ad server code or one (or more) of the various cache files that are in the OpenX “var/cache” directory; and
• A problem with your database server (for example, the database server is not running, you have a corrupt table or data in the database, the database user password or permissions have been changed, etc.) is preventing OpenX from reading the required banner information.

#1.7.2: Turn on higher debugging

If the web server logs still don’t help you determine why the URL call that returns the banner contents is failing, you may need to enable a higher level of debugging output to see if this presents you with any additional information. However, be aware that when you do this, debugging errors may appear in your live site, so, this really is a last resort.

To enable higher level debugging, edit your OpenX configuration file, and change the setting:

[debug]
production=1

so that the production value is 0 (or “false”).

You may also need to modify your PHP settings to enable the display of errors.

With luck, these changes should allow you to see some kind of error, which should allow you to either diagnose and fix the issue, or at least submit a detailed bug report for the OpenX team!

#2.0: Some banners are delivering, but not according to expectations.

Sometimes, banners are delivering, but those banners don’t seem to be delivering according to your expectations. For example, it might be the case that:

• All of the banners you see being delivered are not the banners you thought you would see;
• There’s a specific banner that you think you should see, but you never seem to actually see it; or
• There a banner being delivered sometimes that you just don’t expect to see at all.

In these cases, following troubleshooting check-list should help.

#2.1: Are you using the correct zone tag?

Generally, the reason that all of the banners that are appearing in a zone seem to be the wrong banners is because the zone tag is not actually the correct zone tag, often as a result of a cut & paste error from another location on your website.

Try re-generating the tag directly from OpenX, and re-inserting the tag into your site in the desired location.

#2.2: Is a banner you expect to see, but do not see, active and linked?

Double check on the zone probability screen that the banner you are expecting to see is actually active and linked to the zone you are viewing. Double check that the banner has a probability greater than zero!

#2.3: Is a banner you expect to see, but do not see, a recently added or modified banner?

The OpenX ad server employs a caching system to ensure more efficient banner delivery. As a result, changes to banners, including the linking of new banners to zones, will not become active in the delivery engine until the banner cache timeout value has passed.

If the banner you are expecting to see, but are not seeing, has been recently added, linked to a new zone, or in some other way modified, ensure that you have waited until the cache timeout value has passed before checking to see if the banner can now be seen.

#2.4: Is a banner you expect to see, but do not see, targeted and/or capped?

Sometimes, banners that are actually delivered will not be visible by you, as you will have targeted and/or capped the banner delivery in such a way that it is only visible to other users of your website.

Use the zone probability screen to quickly see if a banner is targeted and/or capped, and if so, review the targeting and/or capping to ensure that it is correct. You can also inspect the number of impressions recorded for the banner in the statistics screens, to ensure that banners that you are not able to view yourself are actually being delivered.

#2.5: Are you running any 3rd party ad network banners?

Occasionally, you may see a banner on your site that is unexpected. Often, this happens when you are displaying banners from 3rd party ad network banners, and the ad network introduces a new advertiser, or perhaps even a new format of banner advertising that they were not previously supplying.

Try using a tool like iehttpheaders for Internet Explorer, or LiveHTTPHeaders for Firefox to view the URL call path when such a banner is clicked. This may help you identify which ad network is supplying the unexpected banner.

#2.6: Are you running the OpenX Market?

As of OpenX 2.8.0, the OpenX Market provides a way for publishers to optionally set a base price at the campaign level, so that if there is an advertiser in the OpenX Market who wants to pay more than the base price for an impression, they can, and the OpenX Market advertiser’s banner will be shown instead of the banner from the campaign.

While this is obviously great news for publishers who use OpenX, as it allows them a no-risk way to potentially earn more income, it does mean that whenever an OpenX Market advertiser is willing to pay more than the base price for an impression, an “unexpected” banner may be displayed.

If you see an unexpected banner that is not from a 3rd party ad network, check your campaigns, to see if you have enabled any for the OpenX Market. This may be the (pleasant and cash-earning!) reason why you are seeing a banner you were perhaps not expecting to.

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