OpenX Tips

Editor’s note: this is a post by guest blogger Erik Geurts

In recent weeks, many stories have been published about security issues regarding the OpenX Ad Server software. Please find below some additional information on the current situation regarding the security of the OpenX software.

The most recent and most severe issues all resulted from a security problem in a third party open source component named “Open Flash Charts 2″. This component is used in the Video Ads plugin that comes with OpenX v2.8.4 and higher. The problem has been corrected with the release of OpenX v2.8.7. Instead of performing a full upgrade, a much simpler task is to just upgrade the Video Ads plugin. If you run OpenX version 2.8.3, which doesn’t have the Video ads plugin, you will not be affected by this particular issue.

There is also a smaller but still significant issue in the OpenX core software. It affects all version of the OpenX v2.8 software, up to v2.8.5 and it is relatively easy to fix. The way to do that is outlined in an OpenX forum post. Applying this patch is not complicated, but it does require some skill in editing php software files.

You can find out which version of OpenX you have by looking at the source code of any page of your OpenX system, including the login page. The version number is displayed in line 4 of that source code.

To summarize the above:

• if you run OpenX v2.8.2 or older, an upgrade to version 2.8.3 would be recommended, including a patch for the security issue that was discovered in August.
• if you run OpenX v2.8.3, applying the security patch that was published in August should be sufficient.
• if you run OpenX v2.8.4 or higher, it would be smart to upgrade the Video Ads plugin, and apply the patch for the security issue, or to upgrade to OpenX v2.8.7.

Really important news for OpenX Hosted users, as OpenX today announce an update made to OpenX Hosted last week that potentially impacts user’s specifically set banner delivery weights.

As you know, campaign and banner weights are an important part of the OpenX delivery process, as they define how often different campaigns and banners will be displayed in relation to other campaigns and banners.

In this announcement in the OpenX forums, OpenX have announced that when a campaign has all banners set with the default weight of 1, instead of delivering all of the banners in the campaign an approximately equal number of times, OpenX Hosted will now automatically decide how many times each banner should be delivered.

This is great news, if you want this type of functionality — the ability to let OpenX decide which banners should be delivered to optimize performance of your campaigns is a long awaited feature. However, all OpenX Hosted users should be aware that this change would appear to have gone live, and will affect anyone who has set up their campaigns with all banners having the default weights of 1, even if you don’t actually want this feature enabled, and you would prefer that all of your banners in a campaign are delivered an equal number of times.

You can see The Guru’s follow up thread to OpenX on the forums, where, hopefully, the OpenX team will follow up on this change in default behavior…

Great news! Erik Geurts and Matteo Beccati have combined forced, and released a patch for the contract campaign under-delivery bug in the OpenX 2.8.2!

You can find the patch attached to OpenX bug OX-5839.

As you may be aware, the OpenX ad server summarizes data and calculated priorities for Contract campaigns on the basis of the configured Operation Interval.

You may also be aware that it is the maintenance script that summarizes the data and calculates the priorities. But how does this script run? There are two different ways — either automatically, or manually.

By default, an out of the box OpenX ad server installation will be configured to run the maintenance script automatically. The OpenX admin guide lists some advantages to running the maintenance script automatically:

• Outstanding maintenance tasks are triggered by banner delivery;
• Enabled by default on new installations; and
• No need to create scheduled tasks.

However, there are also some disadvantages to relying on automatic maintenance, in The Guru’s opinion:

• Automatic maintenance is called from the “lg.php” and “avw.php” delivery scripts. Respectively, these are the scripts responsible for performing impression logging after banner delivery, and for delivery of banners for the Image and No Cookie Image zone tag types. However, you may have noticed that the XML-RPC zone tag delivery script (“axmlrpc.php”) is not mentioned here. In fact, delivery via XML-RPC, which does not use a logging beacon, will not trigger the automatic maintenance process — therefore relying on automatic maintenance when you are using XML-RPC delivery may deliver inconsistent results, as maintenance will not be triggered.
• As a result of needing to test for when maintenance needs to be run, and then actually running it, the “lg.php” and “avw.php” delivery scripts will not complete as quickly as when automatic maintenance is turned off. Although the OpenX ad server tries to minimize the effects as much as possible, there will nevertheless be some users that occasionally experience a delay in the scripts completing when visiting your website.
• Finally, if you have a low volume site, it is possible that some Operation Intervals will not have the automatic maintenance script run at all. This can lead to some odd campaign priority values, as the script has been designed to run each and every interval.

As a result, running the maintenance script manually is The Guru’s preferred method. This is very easy to set up in crontab, as the OpenX admin guide shows.

However, once you have set up a crontab job to run maintenance manually, you should also update your OpenX configuration, to obtain the maximum benefits. While working as the Administrator account, go to Configuration > Maintenance Settings and then disable the automatic maintenance system — this will ensure the delivery scripts do not need to test to see if maintenance has been run recently, and will ensure you get the maximum performance from your delivery scripts.

OpenX with automatic maintenance fully disabled.

Once you have done this, again while working as the Administrator account, go to Configuration > Maintenance, and OpenX will report the current maintenance script configuration. (Please note that you may need to wait for the end of the current Operation Interval to see the current settings.)

Finally, don’t forget to update your crontab entry to run the maintenance script once per Operation Interval, if you have opted to change the value from the default!

In OpenX, it is possible to apply capping to banners. Capping allows you to set a maximum number of times a banner will be seen by a user. This limitation can apply:

• For the browser session — that is, the limitation on the number of times a user will see the banner will apply until the user closes their web browser, at which time the capping limitation count will be re-set; or
• For all time — that is, once the user has seen the banner the number of times specified by the limitation cap, they will not see the banner again, even if they close and restart their browser.

With either type of capping, you can specify an optional time period. After this time period, the cap will be re-set, and the user will once again be able to see the banner, until the cap is reached again.

In addition to setting capping at the banner level, capping can also be applied at the campaign level. In this case, the capping is applied to the aggregate impressions for all banners in the campaign, and once the limit is reached, no banners from the campaign will be shown.

As an example, consider the banner shown below. It has been set up with a capping level of 2 impressions for all time, with a capping re-set period of 24 hours. You have already seen the banner once now, so, if you reload this page, you will see the banner for a second time — which is the limit. Should you re-load the page a second time, you will not see the banner, as you have already reached the limit of two impressions. (But if you come back tomorrow, the banner will once again show for another two impressions.)

The delivery capping options set for the above example banner.

With regards to the above example banner, no guaranteed delivery banner has been included in the zone being displayed, which is why no banner appears once you have reached the 2 impression limit per 24 hours. This highlights why, in a real-world OpenX setup, you should always have a guaranteed delivery banner in every zone.

Why use capping?

Capping banners is not for everyone. Indeed, it makes little sense to apply capping to banners that are there to simply take up unsold inventory.

However, it is widely believed that as the number of times a user has seen a banner increases, the likelihood of that user clicking on the banner decreases¹. As a result, if you are running CPC or CPA campaigns, you may find that you will make better use of your inventory by applying capping, so that you don’t show the banners to these users too many times — and once the capping limits have been reached for a given user, then you can show the user the lower earning CPM campaigns.

Cookies & first time users

One important thing to note about banners with delivery caps applied is that they are managed using cookies. If OpenX cannot set cookies, then banners with delivery capping applied will never be shown. This is because, if capped banners were shown to users who had cookies disabled, then these users would be able to see capped campaigns infinitely. For cases where you have actually sold inventory on a capped basis, this would obviously be very bad — which is why OpenX does not do it.

However, this does mean that on the very first visit a user ever makes to your site, OpenX will not yet know if it can set a cookie or not. As a result, on this very first ever impression, OpenX will not deliver a capped banner. It will wait until the second impression to do so, when it can then be sure if it was able to set a cookie from the first impression. This may be important, if you absolutely require that a certain banner be shown to all users on their first visit to your site — in this case, you will need to use an uncapped banner.

1. It is surprisingly hard to find any actual evidence to back up this belief, though. Please comment below if you have a reference to any! [↩]