OpenX Tips

Newcomers to OpenX often ask a seemingly simple question: “Why don’t I have the same number of impression in OpenX as page views in my website stats program?”

As is often the case, the answer is never quite as simple as the question, and you may need to look in a few different places before reaching the “aha!” moment where all becomes clear.

Number of ads per page

The most obvious starting point in the page views vs. OpenX impressions conundrum is to check how many ads you have per page on your site. If you have more than one ad per page, then you should have more OpenX impression than page views. If you have some pages without any ads, then you should have less OpenX impression than page views.

Of course, if you have some pages with one or more ads, and some without, or pages with varying numbers of ads per page, then obviously, you’ll need to do a little bit of maths to figure out your expected ratio of OpenX impressions to page views!

This might all seem pretty obvious, but it’s still worth noting, as it’s often overlooked.

Drop off

In the event that you have consistently less impression in OpenX than you were expecting relative to your number of page views, then drop off could be the culprit. Drop off occurs when a user clicks on a link in your page content, clicks the back button on the browser, or maybe even goes to a completely different page or even site before the ads on the page have loaded from OpenX and had their impressions recorded.

Now, some level of drop off is normal, and to be expected. You will never be able to eliminate drop off entirely, so please don’t waste your time trying!

However, if you are suffering from a high level of drop off — that is, very many less ad impressions than you were expecting — then there are three main possible reasons for this:

• Poor site load performance can lead to drop off, as users don’t wait for the entire page to load before navigating to another page. For this reason, it is important that you measure your site performance;
• Very large banner sizes and slow 3rd party tags can be a cause of ads loading slowly, which may obviously result in ads not fully loading by the time users go to another page; and
• The location of your ads on the page¹ or the use of end page placement & positioning with CSS can also result in drop off.

You can look at the difference in requests vs. impression in OpenX to help you diagnose drop off issues.

Web log analyzer issues

Web log analyzers look at web server logs to generate the number of page impressions on your site. If you are using a web log analyzer, and you are seeing a ratio of OpenX impression to page views that don’t make sense, then the following are all worth investigating:

• Check that your web log analyzer is working properly — is it processing all your log files? Is your web server logging everything that it should be?;
• Is your web log analyzer correctly excluding items from your web server log that are not page impressions? That is, are all calls to images, CSS files, JavaScript files, etc. being correctly excluded from page view counts? Most web log analyzers should do this by default, but it is worth double-checking; and
• Finally, have you set up your web log analyzer to exclude all of the calls to the OpenX scripts from being analyzed?

1. Ads placed at the bottom of the page are more likely to result in drop off. [↩]

When version 2.6 of the OpenX ad server was released, the OpenX Team introduced a whole new user and account management system.

The new system gives OpenX ad server administrators two important tools for managing who can log into an OpenX installation, and what a user can do once they have logged in: Users, and Accounts.

Users

OpenX allows every person who needs to log into an OpenX installation to have their own username and password. This means that you can do away with sharing one username and password — this is obviously better for security, makes life much easier if you need to remove a user’s access to the installation, and means that the information in the user log is much more useful!

If you’ve got multiple people logging into your OpenX ad server installation, and you’re still sharing a single username and password, now is the time to add some new users to your setup — more on how to do that below…

Accounts

In OpenX, there are four types of accounts:

• The Administrator account;
• Manager accounts;
• Advertiser accounts; and
• Website accounts.

For most OpenX ad server users, the two most important and widely used accounts are the Administrator account, and Manager accounts.

The Administrator account

An OpenX ad server installation has one, and only one, Administrator account. The Administrator account is the account that can do everything — if your user is linked to the Administrator account, then you can not only access the Configuration tab (and the Plugins tab, in OpenX 2.8) to manage the OpenX installation’s configuration settings, but you can also “act” as any Manager account as well, which allows you to manage all of the advertisers, campaigns, banners, websites and zones in the entire installation.

Working as the Administrator account

To “act” as the Administrator account, so that you can access the Administrator account specific tabs, simply use the Working as dropdown menu, and change to the Administrator account¹.

The "Working as" dropdown menu.

Trafficking as a Manager

As stated above, if your user is linked to the Administrator account, then you can act as any Manager account in an OpenX installation, allowing to you manage any advertiser, campaign, bannner, website and zone in an OpenX installation.

However, in order to carry out this management, you need to “act” as the appropriate Manager account. To do this, you can either select the appropriate Manager account from the Working as dropdown menu, or you can use the appropriate Switch to this account link on the Inventory tab.

Linking a user to the Administrator account

To link a new or existing user to the Administrator account, first of all, ensure that you are Working as the Administrator account yourself. Then go to Inventory > Admin Access.

Here, click on the Actions button, and select Add user. (This is true even if you simply want to link an existing user to the Administrator account.) Enter the username of the new or existing user you would like to link to the Administrator account, and click Add user.

If you have entered a new username, then you will be asked to enter the new user’s details — their password, name, email address and default OpenX UI language. Enter these details, and click Add user.

Creating a new user.

That’s it! The user will have been created (if required), and linked to the Administrator account.

Removing a user from the Administrator account

To remove a user from the Administrator account, first of all, ensure that you are Working as the Administrator account yourself. Then go to Inventory > Admin Access.

Here, simply locate the user that you would like to remove from the Administrator account, and click on the appropriate Remove link².

Manager accounts

In OpenX, a Manager account “owns” a complete set of advertisers, campaigns, banners, websites and zones. These sets are independent of one another — so, Manager accounts are a great way of dividing up a single OpenX installation, if you have a number of different groups of advertisers and websites.

Creating a new Manager account

To create a new Manager account, you will first of all need to be Working as the Administrator account. Then go to Inventory > Account Management.

Here, click on the Actions button, and select Add new account. Enter the name, contact name and email address for the new Manager account, and click Save Changes.

Creating a new Manager account.

Working as a Manager account

To “act” as a Manager account, simply use the Working as dropdown menu, and change to the appropriate Manager account. You will only see another Manager account in the dropdown menu if more than one Manager account exists in your OpenX installation, and your user is linked to more than one Manager account (or, your user is linked to the Administrator account, in which case you will automatically have access to all Manager accounts in your system).

Linking a user to a Manager account

To link a new or existing user to a Manager account, first of all, ensure that you are Working as the appropriate Manager account yourself. Then go to Inventory > User Access.

Here, the process of linking a new or existing user to the Manager account is the same as for the Administrator account, with one difference — there is an option to set a permission for the user, called “Allow this user to create new accounts.” This is a misleading permission name, as in fact, this permission allows the user to link new or existing users to the Manager account, and has nothing to do with creating new accounts³! If you want to ensure that the new or existing user you are linking to the Manager account does not have permission to link other new or existing users to the account, then disable the option before you link the user to the account.

Removing a user from a Manager account

To remove a user from a Manager account, first of all, ensure that you are Working as the appropriate Manager account yourself. Then go to Inventory > User Access.

As with removing a user from the Administrator account, simply locate the user that you would like to remove from the Manager account, and click on the appropriate Remove link.

1. Of course, the user you are logged in as will need to be linked to the Administrator account to be able to this! [↩]
2. If the user will not be linked to any accounts once they have been removed from the Administrator account, then the user will be deleted. OpenX will prompt you to ensure that you are happy to delete the user if this is the case. [↩]
3. You need your username to be linked to the Administrator account, and be Working as the Administrator account, to be able to create a new Manager account. [↩]

Did you know that the OpenX ad server has a user log, which provides an audit trail of the changes made to the advertisers, campaigns, banners, websites and zones in your OpenX installation?

This can be an incredibly useful tool in diagnosing who changed what, when for larger users of OpenX, where you might have more than one person performing your ad server trafficking.

You can find the audit trail under the My Account > User Log tab.

The User Log

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

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!