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

It’s great to see one of the larger players in the advertising space going after alleged malvertisers. Apart from being something that is terrible for web users, it can also be a major hassle for publishers.

If you’ve ever suffered from malvertising on your site, often through no fault of your own, you will know what a devastating effect this can have on your site’s reputation.

Via: Mike on Ads.

Two days ago, Google announced the DoubleClick Ad Exchange, a system for advertisers to buy inventory from publishers.

It would seem that the product is aimed mainly at large advertisers and advertising networks on one hand, and large publishers on the other. As a result, it would seem that for most OpenX users, this announcement will have little immediate relevance, although the exchange does support smaller advertisers through AdWords and smaller publishers through AdSense, which hopefully means that at the very least, OpenX users will be able to obtain higher levels of income from their AdSense banners.

Ultimately, though, Google’s announcement is welcome news for OpenX users as it seems to confirm that online advertising is slowly moving towards an open exchange market, where smaller publishers will be able to participate in online exchanges, like the OpenX Market, which will allow advertisers to more easily access obtain the most useful inventory for them, which should translate into higher earnings for publishers.

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