OpenX Tips

You’ve got OpenX installed. Great! You’ve set up an advertiser, and now its time to create a campaign, so that you can add some banners and get them onto your website — but the problem is that you are not sure which campaign type your should be using. Luckily, The Guru is here to explain all…

The campaign types

The OpenX ad server has three different campaign types. With the release of OpenX 2.8, these three campaign types are now very obvious, as they are all explicitly named at the top of the screen for adding a new campaign:

• Contract (Exclusive);
• Contract; and
• Remnant.

(The campaign types above are listed in a slightly different order to that in OpenX — for a reason! More on that later.)

Campaign types in OpenX 2.8.

If you are running OpenX 2.4 or 2.6, while these three same campaign types existed, the names were slightly different, and seeing which campaign type you were using was less obvious, as this was not at the top of the screen for adding new campaigns, but rather down in the fourth section on the page, under the section called Priority in relation to other campaigns. In OpenX 2.4 and 2.6, the three campaign types were called:

• Exclusive;
• High; and
• Low.

Campaign types in OpenX 2.4 and 2.6.

For the this article, Contract (Exclusive), Contract and Remnant will be used as the campaign type names — just remember if you’re using a version of OpenX earlier than 2.8, your ad server will call these campaign types Exclusive, High and Low, respectively.

Campaign targets

Before discussing the three campaign types, however, a brief discussion about campaign targets is required.

There are three campaign target types in the OpenX ad server¹:

• Impression targets;
• Click targets; and
• Conversion targets.

Any of the three campaign types can optionally have any of these campaign targets set² — this includes having more than one target set, if so desired.

The effect of having a campaign target set is that as soon as any one of the campaign targets has been reached, OpenX will stop the campaign from running. Here are some examples of how campaign targets affect campaigns:

• “Campaign 1″ has no campaign targets set. It also has no end date set. As a result, this campaign will never be disabled by OpenX — it will continue to run for as long as it remains set up in this way in OpenX.
• “Campaign 2″ also has no campaign targets set. However, it has an end date set. As a result, this campaign will run until the end date is reached, at which point it will be disabled by OpenX.
• “Campaign 3″ has an impression target of 1,000,000 impressions set. There are no other targets set, and no end date set. As a result, the campaign will run until 1,000,000 impressions have been delivered, and then it will be disabled by OpenX.
• Finally, “Campaign 4″ has an impression target of 5,000,000 impressions set, a click target of 10,000 clicks set, and no end date set. As a result, the campaign will run until either 5,000,000 impressions have been delivered, or until 10,000 clicks have been counted, whichever comes first. The campaign will then be disabled by OpenX.

(If at this point you are wondering what happens when a campaign has, for example, an impression target of 5,000,000 impressions set and an end date set, fear not — this will be discussed shortly in the section on Contract campaigns.)

Contract (Exclusive) campaigns

Contract (Exclusive) campaigns exist for a very specific purpose in the OpenX ad server — as you may have guessed from the name, the campaign type is there to exclusively deliver campaigns that are special because the advertiser wants exclusive rights to certain inventory³ on your website.

Some examples will hopefully make this clearer:

• Your website might have certain “sections” — perhaps it’s an online clothing shop site, and you have sections for different types of clothing (jackets, shirts, shoes, hats, etc.) — and a shoe manufacturer wants to have exclusive rights to all of your inventory for the month of May in the “shoe” section⁴; or
• An advertiser wants to have exclusive access to the first 5 impressions on your site, for every visit your users make to your site, no matter where on the site they are for those first 5 impressions⁵; or
• An advertiser wants to purchase 5,000,000 impressions on your website that are shown exclusively to all visitors from New Zealand, their target market country. That is, any user that visits your site from New Zealand should only ever see this advertiser’s banner, until all 5,000,000 impressions are delivered⁶.

As you will have noticed, all of these examples have a common aspect — it’s not the number of impressions that are booked, it’s not how long the campaign will run for, and it’s not about where on the site the banners will be shown, or which users the banners will be shown to — rather, it’s all about the fact that when the campaign banners should be shown, then they should be shown exclusively — no other banner must ever have priority over the campaign’s banners.

This is why this campaign type has been discussed first (rather than in the order the campaign types are show in OpenX 2.8) — the OpenX ad server will always display banners from Contract (Exclusive) campaigns to your website users before any other campaign type (provided, of course, that campaign or banner limitations allow the banner to be shown).

Most small to medium website owners probably don’t have much use for the Contract (Exclusive) campaign type, because a website generally requires a relatively high profile before advertisers will want to purchase exclusive rights to inventory. However, don’t let that put you off — even smaller sites can consider negotiating special deals with advertising partners, and you can consider using the Contract (Exclusive) campaign type to deliver house banners⁷ for special promotions.

Contract (Exclusive) campaigns are delivered on the basis of relative campaign/banner weights. However, as the whole idea of Contract (Exclusive) campaign is to be exclusive, you should never have more than one Contract (Exclusive) campaign linked to a zone at any one time — unless you are separating multiple liked Contract (Exclusive) campaigns either in time (by having the campaigns run at different times), or by section/location via delivery limitations.

Contract campaigns

As with Contract (Exclusive) campaigns, Contract campaigns exist for a specific reason — in this case, to deliver campaigns that have certain time-sensitive campaign targets.

To understand the nature of time-sensitive campaign targets, it is easiest to think of Contract campaigns as having two different sub-types — Contract campaigns with campaign targets and an end date, and Contract campaigns with campaign targets and no end date; or no campaign targets.

Contract campaigns with campaign targets and an end date

If a Contract campaign has at least one campaign target set, and it also has an end date set, the it should be clear that there are two possible ways that this campaign could be disabled by OpenX — either when the campaign targets that are set are met, or when the end date is reached.

As a result, in this situation, the Contract campaign’s targets can be considered to be time-sensitive — not only do the campaign targets need to be met, they need to be met by the end date of the campaign, and ideally, not before the end date of the campaign either!

This is why Contract campaigns with campaign targets set and an end date set are a special type of campaign.

An OpenX 2.8 Contract campaign with a campaign target and end date set.

Contract campaigns with campaign targets and no end date; or no campaign targets

If a Contract campaign has at least one campaign target set, but no end date set, then it is different from the above example of a Contract campaign with campaign targets and an end date, as there is no end date by which the campaign targets need to be delivered by.

However, it is possible to create an artificial time-sensitivity for the campaign, by setting a number of impressions, clicks or conversions that need to be delivered every day, until the the campaign targets are met.

Similarly, a Contract campaign with no campaign targets set (with or without an end date set) obviously has no time-sensitivity around the campaign targets, as there are no campaign targets! But as before, it would still be possible to create an artificial time-sensitivity by setting a daily number of impressions, clicks or conversions that need to be delivered.

An OpenX 2.8 Contract campaign with a campaign target and a daily target set.

As you can see, Contract campaigns are all about the delivery of time-sensitive campaign targets, and there are two different ways of creating this time-sensitivity — either by setting normal campaign targets and a campaign end date, or by artificially specifying daily campaign targets.

As delivery of Contract campaigns is time-sensitive, delivery of Contract campaigns is performed on the basis of priorities calculated by the Maintenance Prioritisation Engine, to try to ensure that the campaign targets (either normal, or daily) are delivered correctly.

Remnant campaigns

The final type of campaign in the OpenX ad server is the Remnant campaign.

Remnant campaigns are the “catch all” type of campaign in OpenX — if a campaign does not have a requirement of having exclusive access to inventory, and does not have any time-sensitive campaign targets, then it should be set up as a Remnant campaign.

Note that although the word “remnant” suggests that Remnant campaigns are only there to take up “unsold” inventory, that’s not the case. There is no reason why an advertiser can’t ask to purchase, say, 1,000,000  impressions on your site, but not care about when those impressions are delivered by — so long as they are eventually delivered, that’s all that matters. In this case, setting the campaign up as a Remnant campaign makes perfect sense.

Having said that, campaigns that exist to show a low-paying ad network banner, or a house banner, whenever there is any unsold inventory would also normally also be set up as Remnant campaigns.

As with Contract (Exclusive) campaigns, Remnant campaigns are delivered on the basis of relative campaign/banner weights.

Conclusion

There are three campaign types in OpenX. Contract (Exclusive) campaigns exist to deliver campaigns where an advertiser requires exclusive access to certain inventory. Contract campaigns exist to deliver campaigns that have time-sensitive campaign targets of one sort or another. Remnant campaign exist for everything else.

Now you know what campaign type to use. Happy OpenX-ing!

1. There are actually six types of campaign targets in OpenX — there are also daily versions of the impression, click and conversion targets. These are discussed in the section on Contract campaigns. [↩]
2. Can’t find all three campaign target options in OpenX 2.8? Change the campaign’s pricing model. [↩]
3. In the world of on-line advertising, inventory is a website’s number of impressions that are available in a given time period. For example, if your website has 10,000 page views per month, and you have a 468×60 banner zone and a 120×600 skyscraper on every page, then your website would have an inventory of 10,000 468×60 banner impressions and 10,000 120×60 skyscraper impressions per month. [↩]
4. In this case, you might use source parameter targeting to ensure that the campaign’s banners are shown in the “shoe” section of your site. [↩]
5. Capping the Contract (Exclusive) campaign to the first five impressions per session, and linking the campaign to all zones will get the job done for this example. [↩]
6. Use geo-targeting on the Contract (Exclusive) campaign’s banners to ensure that the impressions are exclusively shown to users in the target country, and link the campaign to all zones. [↩]
7. In the advertising business, house banners are banners that advertise yourself, on your own website — for example, you may have a house banner to promote a special deal you have that gives a discount for first time buyers on your shopping site. [↩]

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

If you spend any amount of time on the OpenX forums, then you will see quite a few questions asking about how to use the OpenX ad server as a banner rotator. Examples include asking:

I want to display banner 1, then banner 2, then back to banner 1 again. How do I do this?

and:

I need to show ads one after another with certain impressions. For example, there are 3 ads.

It should show ads like this: ad A first, then when ad A finishes its 200 impressions, ad B, and when ad B finishes its 300 impressions, show ad C, when ad C finishes its 500 impressions, go back to ad A again, and keep rotating always.

Here’s the simple truth — the OpenX ad server is not a banner rotator. If all you want to do is to have a specific sequence in which different banners are shown to your website users, then OpenX is not what you are looking for. Indeed, performing banner rotation like this is actually difficult to do with OpenX — if this really is what you want to do, go and find yourself a suitable banner rotator.

Rather than being a simple banner rotator, the OpenX ad server is really an integration of two very useful tools — a banner delivery engine, that allows you to easily put tags into your website to deliver banners, and track that delivery; and also a banner management system, that allows you to setup overall banner campaign targets. The OpenX ad server will then deliver banners as it sees best to try and meet those campaign targets.

Of course, this doesn’t mean that you don’t have any control over your banners, and how they are delivered. Indeed, OpenX provides you with far greater control than a simple banner rotator can ever give you. For example, with OpenX you can:

• Ensure that you never display the same banner twice on a page;
• Limit how many times a banner is shown to a user in a customisable time period, to ensure that they don’t see the same banner over and over again; and
• Target banners to users according to all kinds of criteria, such as date, day, and time of day, browser type, section of the website, geographical location, etc.

As you are instructing the OpenX ad server about overall campaign targets, and OpenX is then making decisions about how best to ensure these targets are met, this means that you do not have the “specific sequence” level of control that a banner rotator has. Having said that, though, there are ways that you can emulate certain aspects of simple banner rotators, if you really need to:

• Use an Exclusive Campaign with Delivery Capping applied to ensure that the first few impressions of a user’s visit to your site are always given to a special advertiser; or
• Use Zone Chaining to emulate a specific display sequence of special advertiser’s banners.

So, stop thinking about delivering banners in terms of banner rotation — delivering banners in a given order isn’t really that important. What is important is delivering banners to your website’s users in a way that gives your advertisers value for money. Talk to your advertisers about who they need to reach, and what their overall capaign targets are — and then let OpenX do the rest.

It might seem strange to you that The Guru would write a tip for OpenX that is as seemingly simple as “backup your database, code and banner files.”

However, you would not believe the number of times The Guru has been contacted by a client, asking for help with their ad server installation, because something has gone wrong with their server hardware, or because an upgrade failed, and then, on investigation, has found that there’s been no effort made at all to ensure that the OpenX database, OpenX code base (including the configuration files) and banner files, if they have been stored externally to OpenX, are all safely backed up.

In these situations, there is little than can be done if the disaster is catastrophic enough, other than to get a new installation of OpenX up and running, and for the client to start putting in all of their websites, zones, advertisers, campaigns, banners and channels from scratch…

If you rely on OpenX to manage your banners, and you can think of more productive things to do with your time than race against the clock to get OpenX set up from scratch before your advertisers take their money elsewhere, then please, heed the warning: Make regular backups of your OpenX database, OpenX code base and, if necessary, your banner files – especially before attempting an upgrade!

Eight months and eleven days after the release of OpenX 2.6.0, OpenX have released the next stable version of the OpenX ad server, OpenX 2.8.0.

The Guru has been testing this release throughout the “beta” phase, and this version does have some good new features:

• The user interface has been updated, and although some parts of it are pretty much the same as in the OpenX 2.6 version, on the whole, it looks and feels more like a web application from the 21st century, which is a welcome change from the distinctly 1990’s feel of previous versions. For the most part, the new user interface is not only an improvement in looks, it’s also an improvement in terms of workflow and ease of use.
• OpenX 2.8 includes something called “Bucket Based Logging“. In The Guru’s experience, this new logging system is a major improvement, and provides a massive boost to OpenX’s logging performance (in the event that your OpenX installation is disk I/O bound), and also means that some of those huge raw data tables are no longer needed. However, at this stage, it would seem that the OpenX 2.8 upgrade process does not remove any raw tables, so you may need to manually drop these tables, if space is an issue.
• There’s a new plugin framework. For most small to medium users of OpenX, The Guru doesn’t imagine this will really make much of a difference, at least, not until some plugins start to appear on the OpenX Plugin site. However, in The Guru’s experience with seriously large volume users of OpenX, the new framework seems to be going down well, as it is allowing users with time, money and development staff to start extending OpenX in a way that will hopefully mean no more code-patching on upgrades. (Hopefully, some of these large companies will contribute back to the OpenX Plugin site?)
• Finally, the OpenX Market, which has been in OpenX Hosted for a while now, is also made available to download users of OpenX. This should be really good news for small to medium users of OpenX, who are stuck with ad networks who are not paying out much!

So, to the big questions. Is it any good? Does it delivery? Should you upgrade?

The Guru has some little concerns about the user interface:

• Firstly, the new Advertiser/Campaign/Banner and Website/Zone navigation system doesn’t seem to remember which Advertiser, Campaign or Website you were last using, and you often end up editing the Campaigns, Banners or Zones of some apparently randomly selected Advertiser, Campaign or Website. This forces you to return to a higher level, and then re-select what you want to work on.
• Secondly, the user interface now no longer seems to work if you have multiple browser tabs open, operating in different areas of the Advertiser/Campaign/Banner and Website/Zone navigation system. For larger users of OpenX, with a complex trafficking setup, being able to open multiple tabs in different areas of the system is vital.
• Finally, although the new UI does look much nicer, and once you get used to the new layout is generally better in terms of workflow, some actions that used to take one mouse click now take two, as a result of moving “actions” and “shortcuts” into drop down menus. It makes the UI cleaner, but it does slow down trafficking a little.

Additionally, if you are thinking about upgrading to OpenX 2.8.0, please note the main changes in minimum system requirements:

• The minimum required version of PHP is now 5.1.4.
• The minimum required version of MySQL is now 4.1.

Finally, The Guru’s main worry is – has this release been released too soon? Is it really “stable”?

In the past, OpenX has always gone through quite a lengthy “beta” cycle, with plenty of releases to get things right. This time around, we had OpenX 2.7.29-beta, released on February 5, and then…. Nothing! There was some talk on the OpenX forum about OpenX 2.7.30-beta having been tagged, and OpenX 2.7.31-beta being under development, and OpenX’s bug tracker says that OpenX 2.7.30-beta was due to be released on March 20, but it never appeared… Now, OpenX 2.8.0 is out, having had just the one prior “beta” release, and at the time of this post, there are 135 bugs in the OpenX bug tracker that affect OpenX 2.7.29-beta, and the two mysterious unreleased OpenX 2.7.30-beta and OpenX 2.7.31-beta versions.

On the whole, however, The Guru’s testing of OpenX 2.7.29-beta, and now of OpenX 2.8.0, has gone well, so unless any of bugs above seem like “show stoppers” for you, then at least investigating an upgrade to OpenX 2.8 seems like it would be a good idea. Just make sure you’ve got a good backup of your existing database, OpenX code, and banner files, so that you can return to your old version, if required…

See the official release notes for OpenX 2.8.0 for further details of the changes and updates in OpenX 2.8.0.