OpenX Tips

If you are using the OpenX ad server to display banners on your website, then you are almost certainly also interested in viewing the details of the users who visit your website.

To obtain this information, some people use third party services like Google Analytics, which collects data via a tag that is inserted into a website’s pages. Other people download and install Piwik, which also uses a tag inserted into a website’s pages. However, many people still use older tools like AWStats or Webalizer to analyze their web server log files instead.

If you are using a web server log analyzer, then you should keep in mind that the calls to OpenX to request, display and log banners will probably end up being added to your web server log file¹. As a result, if you are using a tool like AWStats or Webalizer, you should consider updating the configuration of the log file analyzer to ignore, or otherwise separate out, the OpenX ad server log entries, otherwise your page hit information in these tools will be greatly over-stated.

1. This will depend on exactly how OpenX is installed, and how your web server logging has been configured [↩]

A question that is often asked about the OpenX ad server is how to move the installation. Generally, this means one of two things — either how to move the installation from one server to another, or how to change the domain name that OpenX is installed on.

Moving server

Moving an OpenX ad server installation from one server to another is a relatively straightforward task, provided you don’t want to get too fussy and technical about it. The following approach for moving an OpenX installation to a new server is a simple, quick and easy way to get an installation moved.

• Ensure that your new server is set up with MySQL, a web server, PHP, etc. and is configured and working¹.
• Backup your OpenX database on the old server.
• Restore the database on the new server².
• Backup the entire OpenX ad server directory on the old server.
• Restore the entire OpenX ad server directory on the new server. Double check that the read/write permissions of the files have not been altered³.
• If required, backup the entire OpenX banner directory on the old server.
• If required, restore the entire OpenX banner directory on the new server. Double check that the read/write permissions of the files have not been altered⁴.
• Test logging into and using OpenX, on the new server.
• Test banner delivery on the new server.
• Change to use the new server in production!

Unfortunately, this approach does have a down side, in that once the OpenX database has been backed up in the second step, any changes to the database, including all data recorded by OpenX for banner delivery on the old server while the migration is “in progress”, will be lost.

Moving domain

Moving an OpenX ad server installation from one domain to another is very straight forward.

• Change your web server software to the new domain.
• Re-name your OpenX configuration file. For example, if your OpenX installation used to be on “www.example.com” and you are moving it to “www.newsite.com”, you would have a configuration file in the OpenX “var” folder called “www.example.com.conf.php”, which needs to be re-named to “www.newsite.com.conf.php”.
• Edit the re-named configuration file. In the [webpath] section, update the admin, delivery, deliverySSL, images and imagesSSL sections to use the new domain.
• Edit any other configuration files, including the “default.conf.php” file. These files may contain a “realConfig” item, which is a reference to the “master” configuration file. Update to the new domain name as required.

Moving server and domain at the same time

The Guru does not recommend that you do this. If you need to move server and you need to move domain name, do one first, and then do the other. Give yourself a day or two between each of the two steps, to really make sure that everything is working fine after the first step, otherwise if you end up with a problem, it won’t be possible to determine which change might be responsible!

1. You may want to perform a clean test installation of OpenX on the server to ensure that everything is working before proceeding with the move. [↩]
2. Don’t forget that you also need to ensure that all of your database users and permissions are set up on the new server as well! [↩]
3. You may also need to address file ownership, in the event that your new server’s web server configuration is different to the old server. [↩]
4. Again, check file ownership. [↩]

Great news! Long time OpenX community member Heiko Webber has announced a patch to allow the OpenX ad server to display statistics by country.

Although the OpenX plugin framework in OpenX 2.8 clearly needs further work by the OpenX team, as Heiko has been forced to release this functionality as a patch, rather than a separate plugin, this is still great news for all OpenX ad server users who have been missing this feature.

Thanks Heiko!

Here’s a great question from reader Komson, who writes:

Dear Guru,

We are using OpenX, and we are facing a problem — the server “goes down” at peak times.

Can you please shed some light on the maximum number of impression per hour, in general, you recommend you should not go over?

e.g. you should not serve over 150,000 impressions per hour.

Thanks in advance!

Here’s a question in response:

I’m planning a party. I’ve already bought some food. How many people can I invite?

It’s a somewhat flippant question, for sure, but hopefully you get the idea — it’s not possible to answer the question of how many people can come to the party without knowing more about the situation. To be able to accurately determine how many people can be invited to the party, you will need to know:

• How hungry do you expect the guests to be? Are they going to be happy getting just a few snacks, or will they will be expecting a full meal?; and
• How much food do you have for the party?

The same thing goes for answering the question about how many impressions per hour you can serve with OpenX.

First up, there’s the question of how much you want to “feed” to your guests. You may be aware that in computing, there are two different ways of measuring “performance”. There’s throughput¹, and response time².

Obviously, users of your web site won’t care about throughput³ — all they care about is response time, because they don’t want to sit around waiting for ages while your website loads. They want it to load now.

So, this is the question of how “hungry” your guests are — they want to be fed, and chances are they want to be fed now, but how much food do you need to ensure all of your guests are well fed? In this case, though, given that you’ve already bought the food (i.e. you’ve already got OpenX installed and set up ready to go on a server you’ve bought, or a hosted service you’ve paid for), its more useful to ask: how many guests can you invite to the party and still ensure everyone gets a good feed? That is, how many impressions per hour can you serve, and still ensure that your website loads quickly?

Of course, if we were really talking about food that you had bought for a party, then once you’ve decided how much you think people will want to eat, it would be pretty obvious by just looking at it how much food you have as to how many people you would be able to feed with it. Naturally, things aren’t quite so simple with an OpenX installation. How much “food” do you really have, so you can figure out how many people can come? That is, once you’ve decided what the maximum average response time you want your users to experience is, how many impressions per hour can you serve with your existing hardware before you will start having a response time that is worse than this?⁴

Unfortunately, there’s only one way to figure this out — you have to measure it!

Luckily, OpenX have actually provided some scripts⁵ to take some of the pain out of measuring your ad server performance, but unfortunately, in the end, if you want to really know how many impressions per hour your OpenX installation can serve, while still keeping people happy, then unfortunately, you have to do some work.

Finally, before you dive into the task of measuring performance (or, if you’ve done so already, and you’re not happy with the results), don’t forget that the OpenX blog has three different articles that all relate to performance — these are definitely worth reading, especially if you have an OpenX ad server installation that is having performance issues!

1. Throughput is a measure of the number of units of work that can be performed per unit time. So, in this case, it is the number of impressions per hour that your OpenX installation can serve. [↩]
2. Response time is a measure of how long it takes to get a response — that is, how long does it take from the moment a user requests a banner from your OpenX installation until the banner is displayed in the user’s web browser. [↩]
3. You obviously care about throughput, as this is the whole point of the original question — how many impressions per hour can you serve from your OpenX installation? However, your can be assured that your website users won’t care about this. [↩]
4. If you want to get really technical, you can also consider what the maximum standard deviation you will allow as well, to address the case of those response times that are greater than the average response time. Think of the standard deviation of the average response time as a measure of that annoying thing that happens at a party where, although there is plenty of food, the people who are standing nearest to the kitchen eat it all, while people furthest away from the kitchen go hungry while they stand around waiting for the plates of food to get passed to them. The greater the standard deviation, the more hungry people will be getting angry in the far corner of your party. [↩]
5. The OpenX scripts page indicates that they are for testing new installations of OpenX before they are put into production. While this is obviously the ideal case, it’s still possible to do performance testing on a live installation — but do the performance testing off-peak (e.g. the middle of night) so that you won’t have many users looking at your website if you end up pushing your server too hard, and you have really bad response times during testing. [↩]

Here’s a great question from reader Tabrez:

Let’s say we have a newspaper website, and we want to have a hierarchy of zones. Should we have (for example) a Sports News zone that then daisy-chains to an All News zone? Or should we use source params etc. What’s better, when?

Similar questions appear on the OpenX forum from time to time as well.

There are actually two different — although related — questions for the price of one here. The first question is, what is the best way to deal with site segments on my website? The second is, how do I deal with hierarchies on my website?

Let’s look at each question in turn.

Site segmentation

Some websites have multiple segments. For example, in Tabrez’s question above, his newspaper centric website will obviously have many different news segments — he’s highlighted that “Sports News” and “All News” as just two of these segments.

If your website has multiple segments like this, then selling advertising based on the different segments is probably a good idea, as it should allow you to provide your advertisers with a more specific target audience, and thus command better rates.

Of course, this means that you need to be able to manage your advertiser’s banners so that they show up in the appropriate segment(s) of your website. So, what’s the best way to manage this with the OpenX ad server?

As Tabrez suggests, there are essentially two different approaches — you could create a separate zone for each segment of your site (i.e. use multiple zones), or you could have just the one zone that is used across the whole site, but use delivery limitations (i.e. banner targeting) to ensure the banners are delivered in the correct segment(s) of your site.

But which of these two approaches is the “best” approach?

The answer, as so often is the case with a very powerful and flexible system like the OpenX ad server, is that there are a number of pros and cons for each of the two approaches, so which is “best” will depend on what works best for you! Here are The Guru’s thoughts on the two different approaches…

Multiple zone approach

The pros of using a different zone for each segment of your site are:

• As each segment in your site is a separate zone in OpenX, and because it is possible to view OpenX statistics by zone, this means that it is possible to view all of the OpenX delivery data in the statistics screen by site segment. This includes the ability to see how each banner is performing on a per-zone (i.e. per-site segment) basis. This information is not available when using the banner targeting approach to site segmentation.
• Provided that your zones are clearly named, ideally with some form of naming convention, then once you have configured all of the different zones, management of your advertiser’s banners should be very simple, as “targeting” banners to given segments of your site is simply a matter of linking the campaigns and/or banners to the appropriate zones. As the linking of campaigns/banners zones is something that you would do anyway in OpenX, this means that the multiple zone approach to site segmentation introduces no additional management overhead.

The cons of using a different zone for each segment of your site are:

• Although the multiple zone approach to site segmentation means there is no additional management overhead once you are up and running, there is potentially a high initial set up cost associated with the approach, in the event you have many different segments on your site. This is because you need to set up all of the separate zones in OpenX, generate the zone tags for each zone, and then ensure that these tags are placed correctly in the different segments of your site.
• If you have advertisers that run campaigns where the campaign banners are not always displayed in the same website segments, then this approach will mean that you cannot link campaigns directly to zones — you will need to manage the zone links at the banner level. This may introduce additional work, especially if there are many banners per campaign.
• If you do not use an appropriate naming convention for your zones, or you have many hundreds or thousands of site segments, then the OpenX screens for managing campaign/banner to zone linking may be slow, and it may also be difficult to find the appropriate zone(s) to link to, simply as a result of the number of zones in the system.
• If you have segments on your website that receive very small numbers of page views, then you may find that these zones do not effectively deliver Contract campaigns. This is because the OpenX Maintenance Prioritisation Engine depends on zones having a reasonable number of impressions per hour to be able to accurately prioritise banners — if there are very few impressions per hour in some of your segments, using banner targeting to segment your site may be preferable.

Banner targeting approach

The pros of using banner targeting to target banners to different segments of your site are:

• There is almost no initial setup required to start targeting banners to a segment of your website. Simply enter the required banner delivery limitations that will ensure that your banner appears only in the required site segment, and you are done¹!

The cons of using banner targeting to target banners to different segments of your site are:

• As the site segmentation is being performed with delivery limitations, and because delivery limitations can only be applied at the banner level in OpenX, this means that every single banner that is to be targeted to a site segment needs to have delivery limitations applied, which introduces an ongoing additional management overhead².
• Unlike the multiple zone approach, it will not be possible to view the OpenX delivery data for banners on a per-site segment basis. As there is just one zone across the whole site, banner delivery data will simply be logged against this zone, no matter which site segment a banner’s impression occurs in.
• If you have segments on your website that receive very small numbers of page views, then you may find that banners in Contract campaigns that are targeted to these segments can cause the OpenX Maintenance Prioritisation Engine to cause other Contract campaigns in the system to delivery incorrectly, due to issues with dealing with very highly targeted Contract campaign banners.
• Debugging delivery issues where a banner is being displayed in an incorrect site segment may be more difficult than with a multiple zone approach to site segmentation, due to the potential complexity of the banner delivery limitations.

Conclusion

Performing site segmentation is a balancing act. The pros and cons of the two different possible approaches probably seem difficult to weigh up, especially if you have not previously tried both approaches.

To make life simpler, The Guru recommends that if you have not performed site segmentation before, you select an approach based on how many site segments you have. That is, if you have only a dozen or so site segments, then use the multiple zone approach, as this will not be too difficult to setup, and with a small number of site segments, you are not likely to suffer from the many of the cons of this approach. However, if you have more site segments that this, try the banner targeting approach.

Keep in mind that if this is your first time using site segmentation, no matter which approach you first try, you can always experiment with the alternate approach later, should you find that the initial approach is not suitable for your needs for one reason or another.

Finally, it is worth pointing out that you can actually combine the two approaches. That is, you can always partially partition your site via multiple zones, and then further partition each zone into smaller segments via banner delivery limitations. This approach will of course require balancing at which level you stop multiple zone based segmentation and move to banner targeting based segmentation, but with time and practice, you will learn to get most of the pros, while avoiding most of the cons.

Zone hierarchies

The concept of a zone hierarchy is related to the idea of site segmentation. Think about it this way — if you have divided up your website into segments for the purpose of selling your inventory at a higher rate, what do you do when when you have spare inventory in a site segment?

The answer, for once, is reasonably simple. If you have used multiple zones to manage your website’s segments, then using zone chaining to create a hierarchy of zones is the correct approach. That is, if you have a zone that represents a site segment (e.g. the “Sports News” segment zone from Tarbrez’s question), and you find that that the site segment/zone has spare inventory, then the easiest way to ensure that a banner is shown is to link the zone via zone chaining to the next zone “down” in the zone hierarchy. In Tabrez’s example, this sounds like it would be the “All News” segment zone. Of course, you can have as many levels of zone changing as you need in your zone hierarchy³.

If, however, you have used banner targeting to manage your website’s segments, then a zone hierarchy doesn’t really apply. Presumably, advertisers that are buying inventory in your site segments will be doing so via the Contract (Exclusive) or Contract campaign types, and so you can simply link any Remnant campaigns, containing un-targeted banners, to the single, site-wide zone in OpenX. These Remnant campaign banners will be shown whenever there is spare inventory that is not used by your segment-specific advertiser campaigns, due to the way that the banner delivery process will only show banners from Remnant campaigns after it has determined that there are no banners to be displayed from any Contract (Exclusive) and Contract campaigns⁴.

1. Of course, some delivery limitation types may require additional work before they can be used. In the original question, it was suggested that “source parameters” would be used. To be able to target with source parameters, the Site – Source delivery limitation type requires that changes to the zone tags will need to be made so that the appropriate source parameters are passed into the OpenX ad server calls and allow the targeting to be performed. For this reason, the Site – Page URL delivery limitation type may be more suitable to perform site segmentation, assuming that you are able to accurately determine site segments via your website’s URL. [↩]
2. This can be somewhat reduced by appropriate use of targeting channels, however. [↩]
3. There is a performance penalty for each level, of course, so try not to have a zone hierarchy that is too deep. [↩]
4. If you are not using the Contract (Exclusive) or Contract campaign types for your segment targeted advertiser campaigns, then a two zone hierarchy would be appropriate — an “initial zone” that is linked to all of the campaigns containing banners that are site segment targeted, which is then linked via zone chaining to a “remnant zone”, containing all of the untargeted banners. [↩]