OpenX Tips

Here’s a great question from the OpenX Forums about companion positioning:

“I have 4 zones… I only want to show banners from the same campaign for Zones 1 and 2. I don’t want to run an ad more than once on the same page.”

If you read last week’s post on companion positioning, then you will know that OpenX was not designed to do this — either you show banners from a companion campaign on all banners on the page, or you don’t. It’s not really built to run a companion campaign in some of the zones, but not in others.

However, you can subvert OpenX to do “partial” companion position, if you really need to. Well, to a limited extent, anyway. There are two different ways:

Put your non-companion zones first

If you can, you can put your zones that don’t have companion campaign banners in them first on the page. OpenX will happily select banners from any campaign as it goes along, until it gets to a zone where it selects a companion campaign banner. From that point on, all banners will have to be in the companion campaign¹.

Use mixed zone tag types

The iframe, Image and No Cookie Image tag types do not support companion positioning. So, you can set up your companion campaigns to be delivered by zone tags that do support this option (the JavaScript zone tag, for example), while your other zones are delivered by a zone tag type that does not support companion campaigns (say, the iframe zone tag).

Unfortunately, this does mean that other options, like not showing banners twice, or not showing banners from the same campaign again for the non-companion campaign banners will not be available.

1. Note that this trick does not work when using Single Page Call. [↩]

What is companion positioning? The OpenX 2.8 user guide only mentions the topic very briefly, so it’s worth a deeper look.

Companion positioning is a way of ensuring that when one banner on a page is from a campaign, then all banners on the page will be from the same campaign. So, for example, imagine your web site has two zones on every page, and an advertiser says to you that they would like to advertise on your site, but only if they can have their banners in the two zones show up at the same time. This is when you want to use companion positioning.

Setting up companion positioning

Setting up companion positioning in OpenX is very simple. When you have an advertiser that wants a campaign with companion positioning, all you have to do is enable the “Companion positioning” option under “Miscellaneous” on the campaign property screen.

Enabling companion positioning for a campaign.

Effect of companion positioning

Consider the following example, where there are two advertisers, each with one campaign:

Advertiser 1, Standard Campaign:

• Banner 1: Linked to Zone 1
• Banner 2: Linked to Zone 1
• Banner 3: Linked to Zone 2
• Banner 4: Linked to Zone 2

Advertiser 2, Companion Campaign:

• Banner 1: Linked to Zone 1
• Banner 2: Linked to Zone 2

As you would expect, when the two zones are placed on a single page, there are five different possible outcomes — four different combinations of Advertiser 1′s campaign banners can be displayed, and one combination of Advertiser 2′s campaign banners. That is, as Advertiser 2′s campaign is set to be a companion position, it’s banners never show up with any other banners other than its own.

To see the above example in action, see the Tip #29 example page, which you can reload over and over to see how companion positioning ensures that the two companion banners only ever show together on a page.

Caveats

There are a number of caveats to be aware of when using companion positioning:

• When OpenX delivers one banner from a companion campaign, then all of the other zones on the page must have banners from the companion campaign. If any of the other zones on the page do not have a banner from that campaign that can be delivered (e.g. there is no banner from the campaign linked to the zone, or the banner has delivery limitations or capping applied that prevent the banner from being delivered), then no banner will be displayed in the zone¹. You should ensure that your companion campaigns have banners linked to all zones that will appear on your page, and that all banners in companion campaigns have identical capping and delivery limitations!
• The whole point of companion positioning is to display multiple banners from the same campaign on the same page. If you want to run companion campaigns, remember that you must not have your zones configured with the “Don’t show a banner from the same campaign again on the same page” option!
• Older versions of OpenX had a bug in companion campaign delivery, which meant that if the first banner on a page was from a non-companion campaign, subsequent banners could still be from a companion campaign, resulting in a mixed non-companion/companion banner situation. You should upgrade OpenX to the latest stable release to avoid this issue.
• Companion positioning will not work with the iframe, Image and No Cookie Image zone tag types. Obviously, companion positioning will also not work with the Popup zone tag type, as this opens a new window, which contains just the one zone.
• If you are using the OpenX Market, it would make sense to not enable the Market for your companion campaigns. As your advertiser is paying to specifically have their ads displayed in all of your zones on a page at once, it does not make sense allow any of those banners be overridden by an OpenX Market banner!

1. Note: This appears to be set to change in OpenX 2.8.2, so that if no banner from the companion campaign is linked to a zone, then a normal banner will be delivered. See issue OX-5508 [↩]

So, business is booming, and you are approaching your OpenX installation’s maximum capacity — you know this, because you measured your system capacity. You know that it’s time to scale your OpenX installation.

Or, perhaps you have no idea what you system’s maximum capacity is, but you have noticed that your system is a little bit slower than it used to be, and you think that scaling your OpenX installation might be a good idea¹.

How do you go about scaling an existing OpenX installation?

There are essentially two different options for doing this simply.

Vertical scaling

Vertical scaling is the easiest way of scaling your OpenX installation — simply upgrade your existing server (perhaps by adding more RAM or changing the hard drives so that they have faster I/O) or move your OpenX installation onto a larger, faster server.

Certainly, this will not be a hassle-free process — performing hardware upgrades or migrating services from one server to another are never going to The Guru’s idea of a fun day’s work — but if you currently run OpenX on a single server, then it can be comforting to know that, after you have completed a vertical upgrade, you will still have a familiar, single server setup.

Unfortunately, the main drawback with vertical scaling is that sooner or later, depending on your budget, it will simply become too expensive to perform a vertical upgrade².

Simple horizontal scaling

Simple horizontal scaling as an approach where OpenX is scaled horizontally (that is, over multiple servers) at the delivery/UI server level, but where there is still only one database.

Using this approach, there are only four things that are different from a single-server installation of OpenX that you need to worry about:

1. Database access: In a single server installation, ensuring that OpenX can access the database is generally trivial, as all that is needed is a username/password. However, now that your delivery/UI servers are separate from the server that is running the database, you may need to update your database server’s accounts and/or permissions, to ensure that the OpenX code on the remote delivery/UI servers can connect to the database.
2. Load balancing: To distribute the task of banner delivery and OpenX UI access across all of your delivery/UI servers, you will need some form of load balancing solution.
3. Code synchronization: As OpenX is now installed on more than one server, you need to ensure that all servers remain synchronized with each other, so that when you make configuration changes, or perform an upgrade, you don’t end up with one (or more) of the servers in a different state from the others. This is relatively easy to achieve by using rsync, or a similar code synchronization system³.
4. Running maintenance: When OpenX is installed on more than one server, but you have a single, central database, it is important to ensure that only one server runs maintenance⁴. Pick one of your delivery/UI servers, and set up maintenance to run on just that server. Disable maintenance from running on all the other servers. It’s even more important to run maintenance manually in this kind of setup, otherwise the issues of not doing so will be increased, as a result of having more delivery/UI servers!

Of course, with this form of simple horizontal scaling, the central database server can become a bottleneck. If this happens, you can either scale your database server vertically, or you will need to consider using OpenX’s “distributed statistics” mode for horizontal scaling, which allows the database load to be (partially) distributed across multiple servers — however, scaling OpenX in this was is most certainly not a simple means of scaling, and is a topic for another day…

1. Assuming that you have at least tried basic performance tuning first! [↩]
2. Let’s face it, there are not many OpenX users that can afford to go and drop $50k or even more on a top-of-the-line server. [↩]
3. It is often easier to manage this process if you distribute banner delivery across all of the servers, while limiting UI access to one server, as this means there is only one UI server where changes can be made, and upgrades can be run. However, this of course also limits the level scaling you can apply to your OpenX UI service. [↩]
4. If all of your servers ran maintenance, and they all ran maintenance at the same time, this should not be an issue, as OpenX does have code in place to try and ensure that if you run more than one instance of maintenance at a time, it won’t matter; but it’s better not to do this, if you can avoid it [↩]

A few days ago, the guys at isocket tweeted about a recent article in MarketingVOX. This article may be of interest to OpenX ad server users, in particular, this part:

Smaller online ads may be more effective than larger counterparts, a new study by Dynamic Logic found.

The study shows that ad shape and placement may be more important than size. Half banners, at 234 x 60, and 180 x 150 rectangles were shown to be more effective than ads that frame the page, like high-profile leaderboards and skyscrapers. It is possible that users no longer see such framing ads because they have developed “banner blindness.”

In addition, smaller ads may be more effective because they tend to be better incorporated into the content of Web pages.

If you’re an OpenX user, then you know how much easier OpenX makes your life when it comes to delivering banners into your web site(s). However, it’s important to remember that if you’re looking to generate income from a site, then you should be thinking about maximizing that revenue — and if you are, you can’t simply set up your website once, and only experiment with different banners and ad networks. You also need to think about your site design, the banner sizes you have and where those banners are positioned. Unless you experiment with your site and banners, you won’t really be sure if you are maximizing your revenue.

Sure, it certainly takes more effort than just swapping banners in OpenX, but it can be worth it.

Along the same lines, OpenX community member and consultant Erik Geurts has a great post up about 7 common problems with landing pages, which is also worth reading, and may help you in your site and banner experiments in the search for improved advertising revenues.

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!