OpenX Tips

One of the least understood configuration options in OpenX is the “Operation Interval” setting. What is it, and what does it do?

Operation Interval in the Maintenance Settings

The first and foremost thing to know about the Operation Interval is that it is not a means of changing how often statistics will be updated in the user interface. OpenX, no matter what version you have installed, will only ever update the statistics in the user interface once per hour. That is it — end of story, end of discussion. Changing the Operation Interval to a value less than 60 minutes will not change this, and if you modify the Operation Interval setting expecting this to be the case, then you will be sorely disappointed.

So, if this is the case, what is the Operation Interval?

The Operation Interval is the mechanism by which OpenX performs internal statistics data aggregation and is the basis on which priority calculations are performed. That is:

• Statistics data is logged based on the Operation Interval (for OpenX 2.8, anyway);
• Statistics data is summarized and stored based on the Operation Interval; and
• Priority values for Contract Campaigns are calculated on the basis of the Operation Interval.

So, given that the Operation Interval is something that only relates to OpenX’s internal operations, why would you want to change it?

To answer this question, you need to understand the two effects that reducing the Operation Interval from the default value of 60 minutes has. (The Operation Interval can only be set to 5, 10, 15, 20, 30 or 60 minutes.)

Firstly, because data aggregation is performed using the Operation Interval value, if you reduce the value from the default of 60 minutes, then OpenX will need to store more data rows. This is because if the Operation Interval is reduced, then there are more Operation Intervals per hour, which means there will be less data aggregation based on the Operation Interval, and so more data rows that need to be stored. As the Operation Interval is the basis by which data is summarized and stored in the “data_intermediate_%” and “data_summary_%” tables in OpenX, which account for most of the database size, then you can expect that an OpenX installation with an Operation Interval of 30 minutes would require twice the database storage as an equivalent OpenX installation with an Operation Interval of 60 minutes¹.

Secondly, because the maintenance process which calculates Contract Campaign priority values does so on the basis of the Operation Interval, if you reduce the value from the default of 60 minutes, then the OpenX maintenance process will be required to perform more work to calculate the priorities. This is because the maintenance script calculates a priority for every active banner/zone link in the system for every Operation Interval, so if the Operation Interval is reduced, then there are more Operation Intervals per hour, which means there are more priority values to be calculated. The part of the maintenance script that calculates priorities for Contract Campaigns would be expected to take at least twice as long to run on an OpenX installation with an Operation Interval of 30 minutes than on an equivalent system with an Operation Interval of 60 minutes.

So, given the increase in database size and the decrease in performance of the maintenance script that comes with reducing the Operation Interval value, why would you ever change the Operation Interval from the default value of 60 minutes?

The answer is that if you run a very high end OpenX installation, having the Contract Campaign priority values updated only once per hour may sometimes not be enough, and you really do need these priority values updated every half an hour, or every 15 minutes, or maybe every 5 minutes. Be aware, though, that you will need some seriously expensive hardware if you expect to be able to run a large OpenX installation with an Operation Interval of 5 minutes².

Of course, if you do change the Operation Interval value, don’t forget:

• You need to update your system crontab so that the maintenance script is run once (and only once) per Operation Interval. There’s no point in setting your Operation Interval to 30 minutes, so that Contract Campaign priorities can be updated more often, and then not running the maintenance script every Operation Interval to do so!
• You should review your banner delivery cache setting, as there is no point in calculating the Contract Campaign priorities more often, only to have these values ignored due to a long cache value.

Finally, it is worth noting that if you don’t actually run any Contract Campaigns, then there is no point in reducing the Operation Interval from the default of 60 minutes, as there will be no benefit for you at all in this situation!

1. Note, however, that OpenX does not update previously logged and summarized data when you change the Operation Interval — the new value only applies to data logged and summarized after you make the change. So, if you’ve had the Operation Interval set to 30 minutes, changing it back to the 60 minute default will only mean that you will save space on all new data. [↩]
2. If you do have an Operation Interval value that is less than 60 minutes, you should probably review this value. Is it really necessary to have it lower than 60 minutes? Is the additional database space required really worth the benefits? Is the maintenance script actually able to complete running within the defined Operation Interval time, or is it taking longer than the Operation Interval? If so, you are not really obtaining any benefits, and you are probably causing issues by not running the maintenance script completely and fully every Operation Interval. [↩]

As you may have read in the OpenX 2.8.1 release notes:

Zone probabilities are distributed amongst campaigns, independent of the number of banners. OX-3095

This means that it is now possible to divide a zone’s inventory up between the linked campaigns by campaign weight, without having to re-calculate all of the weightings when a new banner is added.

As a result, Tip #8: Understand the banner delivery process has been updated to describe the different delivery process for OpenX releases before and after version 2.8.1.

Why would you need to know what happens inside the OpenX ad server whenever a zone tag is called? Simple — although it’s a little bit technical, understanding the banner delivery process is essential for really getting to grips with banner delivery in OpenX, and is vital background information for a number of other topics.

Although the process below is specific to OpenX 2.8, the process in earlier versions of OpenX is very similar, although slightly less efficient. However, the general principle is the same.

The banner delivery process

It does not matter which zone tag type you use, the banner delivery process pretty much follows the same process. After some initial setup of the environment, the OpenX ad server uses the following process to determine which banner to deliver.

1. Find all of the active banners¹ that are linked to the zone.
2. Are there any active banners linked to the zone that are from Contract (Exclusive) campaigns? If so:
   1. Do any of the linked Contract (Exclusive) campaign banners “fail” delivery limitations?² If so, discard these banners.
   2. Are any of the linked Contract (Exclusive) campaign banners incompatible with the zone tag type?³ If so, discard these banners.
   3. Are there any banners remaining? If so:
      1. Select one of these banners via the campaign weight/banner weight process (see below).
      2. Log a request, using the selected banner ID and the zone ID.
      3. Display the banner.
      4. Log an impression, using the selected banner ID and the zone ID.
3. If this point is reached, then there were no banners from Contract (Exclusive) campaigns that could be displayed.
4. Are there any active banners linked to the zone that are from Contract campaigns? If so:
   1. Do any of the linked Contract campaign banners “fail” delivery limitations? If so, discard these banners.
   2. Are any of the linked Contract campaign banners incompatible with the zone tag type? If so, discard these banners.
   3. Are there any banners remaining? If so:
      1. Possibly select one of these banners via the Contract campaign banner selection process (see below).
      2. If a banner is selected:
         1. Log a request, using the selected banner ID and the zone ID.
         2. Display the banner.
         3. Log an impression, using the selected banner ID and the zone ID.
5. If this point is reached, then there were no banners from Contract (Exclusive) campaigns that could be displayed, and there were either no banners from Contract campaigns that could be displayed or no banner from a Contract campaign was required to be shown.
   
6. Are there any active banners linked to the zone that are from Remnant campaigns? If so:
   1. Do any of the linked Remnant campaign banners “fail” delivery limitations? If so, discard these banners.
   2. Are any of the linked Contract campaign banners incompatible with the zone tag type? If so, discard these banners.
   3. Are there any banners remaining? If so:
      1. Select one of these banners via the campaign weight/banner weight process (see below).
      2. Log a request, using the selected banner ID and the zone ID.
      3. Display the banner.
      4. Log an impression, using the selected banner ID and the zone ID.
7. If this point is reached, then there were no banners from Contract (Exclusive) campaigns that could be displayed, there were either no banners from Contract campaigns that could be displayed or no banner from a Contract campaign was required to be shown, and there were no banners from Remnant campaigns that could be displayed.
8. Is the zone set up via zone chaining to be linked to another zone? If so, re-start the process from the first step, using the new zone.
9. If this point is reached, then there were no banners from Contract (Exclusive) campaigns that could be displayed, there were either no banners from Contract campaigns that could be displayed or no banner from a Contract campaign was required to be shown, there were no banners from Remnant campaigns that could be displayed, and the zone is not set up via zone chaining to be linked to another zone.
   
10. Is a default banner configured? If so:
    1. Log a request, using the selected banner ID and the zone ID.
    2. Display the banner.
    3. Log an impression, using the selected banner ID and the zone ID.
11. If this point is reached, then no banner can be displayed.
12. Display a “blank” 1×1 .gif pixel.

Campaign weight/banner weight process

In the above process, when testing the active Contract (Exclusive) banners, or when testing the active Remnant banners, if there is more than one banner that can be delivered, one of the following processes is used to determine which banner to deliver, depending on the version of OpenX:

OpenX 2.8.1 or greater

1. For every banner in the zone, find the parent campaigns.
2. Sum all of the campaign weights.
3. Generate a random number between 0 and the sum of the campaign weights, and use this random number to select a campaign.
4. For all of the banners in this campaign that are also in the zone, sum all of the banner weights.
5. Generate a random number between 0 and the sum of the banner weights, and use this random number to select a banner.

OpenX 2.8.0 or less

1. For every banner in the zone, take the banner’s weight and multiply it by the campaign weight, to obtain the overall campaign/banner weight.
2. Sum all of the campaign/banner weights for the banners.
3. Divide each banner’s campaign/banner weight by the sum of all of the campaign/banner weights. (This ensures that the sum of the new campaign/banner weights is 1.)
4. Generate a random number between 0 and 1, and use this random number to select a banner, so that banners are delivered with a distribution based on their relative campaign/banner weights.

Contract campaign banner selection process

In the above process, when testing the active Contract banners, if there is more than one banner that can be delivered, the following process is used to determine which banner to deliver:

1. Look at all of the active banners in Contract campaigns that have a Priority Level of 10 (if any):
   1. For every banner, take the pre-calculated priority value and multiply it by the pre-calculated priority factor value.⁴
   2. Sum all of the calculated priority/priority factor values for the banners.
   3. Divide each banner’s priority/priority factor value by the sum of all of the priority/priority factor values. (This ensures that the sum of the new priority/priority factor values is no greater than 1.⁵ )
   4. Generate a random number between 0 and 1, and use this random number to either select a banner, or select no banner.
2. If no banner is selected, then repeat the above process with all of the active banners in Contract campaigns that have a Priority Level of 9, then 8, then 7, etc. all the way down to the active banners in Contract campaigns that have a Priority Level of 1.

Variations to the impressions logging ordering

Certain zone tag types (Image, No Cookie Image, XML-RPC) do not log the impression after displaying the banner — instead, the impression is actually logged immediately after logging the request; that is, before displaying the banner. This is because with these zone tags, it is not possible to deliver a logging beacon.⁶

Phew!

Okay, saying at the start that it was a little bit technical may have been an understatement. However, if you’ve at least managed to get a vague idea of how the delivery process works, The Guru promises that future articles on the OpenX ad server will make a lot more sense…

1. A banner is active when it is in a campaign that currently running, and the banner has not been disabled. [↩]
2. That is, if the banner was actually attempted to be delivered, would it be unable to be shown as a result of any delivery limitations or delivery capping that has been set up for the banner? [↩]
3. For example, HTML banners cannot be delivered when using the Image or No Cookie Image Tags, which can only deliver image banners. [↩]
4. These values come from the Maintenance Prioritization Engine. [↩]
5. It is possible for the sum of the new priority/priority factor values to be less than one, if the Maintenance Prioritization Engine has determined that the Contract campaigns do not require all of the available impressions to be used in order to meet the campaign targets. [↩]
6. A logging beacon is a 1×1 .gif pixel that is delivered separately from, and after, a banner, so that if the banner is not actually delivered to the user’s web page, the banner impression is not counted. [↩]