Using the OpenX local banner (website) image banner type? If so, don’t use the default storage location (i.e. the OpenX “www/images” directory). If you do use this location, then every time you upgrade OpenX, you’ll need to remember to copy your creative files over to the new OpenX code base.
Instead, create a new directory for your creative files to be stored in and served from. Make sure that this directory is outside of the OpenX code base. (Or, if you have a really large OpenX installation, consider setting up an FTP server that can be used to replicate your creative files to all of your delivery servers, and use the FTP server as your “storage location”.)
This way, you’ll never have to copy your creative files on upgrade ever again!
It doesn’t matter if you are running OpenX on a single server, or if you are running OpenX on 20 (or more!) servers. Either way, you probably want the statistics collected and displayed by OpenX to be as accurate as they possibly can be.
One very simple thing that you can do to help ensure your statistics are accurate is to ensure that on all servers where you run OpenX, you have correctly configured the system time and timezone, and that you are running a tool to ensure that your clock is synchronized with a master time source. (Clock synchronization is clearly important when running OpenX across a number of servers, but it certainly doesn’t hurt on a single server setup either!)
This is something that is very easy to do, both for Linux and Windows systems, and yet is something which The Guru very rarely sees set up. Why not update your OpenX servers today?
In the OpenX ad server, if you are not serving an HTML, text or 3rd party banner, then you will be serving a banner that has a creative file of some kind.
OpenX calls these image banners, and provides you with three different image banner options. Each of of these three image banner types stores the associated creative file in a different way. The three different options are:
- Local banner (SQL);
- Local banner (webserver); and
- External banner.
The OpenX administrator can even control which of these banner types are able to be used. The question is, which storage type, or types, are appropriate for your OpenX installation?
Local banners (SQL)
The local banner (SQL) type (re-named to the sql banner type in OpenX 2.7-beta), as the name suggests, is the image banner type in OpenX where the creative file is stored in the OpenX database.
As a matter of personal opinion, The Guru isn’t a fan of this banner type, because databases are generally not the ideal storage solution for large amounts of binary data. However, for most small to mid-sized OpenX users, this is often the image banner type that is used, and it provides a number of benefits:
- Simple management of banner creative files: As all the creative files are stored in the database, you only need to worry about backup of the OpenX database and OpenX code.
- Nothing to do on upgrade: As the creative files are in the database, when it’s time to upgrade OpenX, there’s nothing else to worry about with regards to the files.
- Makes life easy when growing: With creative files stored in the database, there’s no issue with adding another server to your OpenX installation, as any server that can talk to the database can serve banners.
However, there are also a couple of downsides:
- Large database size: The more creative files you store in the database, the larger your database will be, which can be a concern for smaller OpenX users, especially if shared hosting is used, as there are often associated database size limitations.
- No direct file access: It’s impossible to directly access the creative files on disk, if you should ever want (or need) to do so.
- Limited scaling: While it will be possible to add more servers to your OpenX installation, and have them serve banners, the level of scaling possible with this setup will be limited as, eventually, the database will become a bottleneck.
Local banners (webserver)
The local banner (webserver) type (re-named to the web banner type in OpenX 2.7-beta) is also exactly what you would expect; here, creative files are stored directly on the server filesystem. As before, this banner type has its advantages:
- Direct creative file access is possible: The creative files are stored on your server’s hard drive, so you can access them like normal files.
- Scales well: As the creative files are not in the database, you can replicate the files out to as many servers as you need, so scaling to huge volumes is no problem.
Of course, this is balanced by the disadvantages:
External banners
The final image banner type in OpenX is the external banner type (re-named to the url banner type in OpenX 2.7-beta). As the name suggests, this is for the (normally rare) case where you will not actually be uploading the creative file for a banner into OpenX. Instead, you simply provide the URL to the creative.
As a general rule, you won’t need to use the external banner type unless:
- You are serving a 3rd party banner, but the 3rd party doesn’t provide you with an HTML tag; instead, they just give you a URL to the banner to serve; or
- You run your own creative management system externally to OpenX, and you simply want to take advantage of OpenX’s banner serving and tracking features without having to re-upload all of your creative files into OpenX, as this would essentially be a duplication of work. In these situations, use of the OpenX API from your creative management system may be appropriate, to reduce duplication of work even further!
Which to use?
Which is the right banner type to use? Apart from the external banner type, which has two very specific reasons for use, the choice is very much yours to make, based on the pros and cons of each type. However, if you’re new to OpenX, then The Guru would recommend that you start out with the local banner (SQL) type, until you gain experience with OpenX. After a while, you can consider moving to the local banner (webserver) type as your site, and ad serving requirements grow.
When OpenX version 2.6 was released, the OpenX ad server gained a new feature called Single Page Call. If you’ve got more than one banner on a page, then Single Page Call can be one way to get more performance out of your OpenX installation.
The way OpenX generally works is that for every position on your website that you want to display advertising, you set up what’s called a “zone” in OpenX. For every one of these zones, you then generate the zone’s “zone tag” (sometimes called an “invocation code tag”), and you put these tags into your page’s HTML source where you want the banners to display.
When your site is viewed, each zone tag in your site’s HTML makes a call off to your OpenX ad server, OpenX figures out what banner to show, and then sends it back, ready for display. So, if you have more than zone on a page, this means that you are going to be making more than one call to your OpenX ad server per page view.
The Single Page Call system, though, means that you can make just the one call off to your OpenX ad server to get all of the banners for the page, no matter how many zones you want to display. Fewer calls means less load on your ad server, and also means faster load times for your website.
You can find more information about generating the Single Page Call tag in the OpenX documentation. (The process in OpenX 2.7-beta is slightly different from that in OpenX 2.6, but unfortunately the OpenX 2.7-beta documentation doesn’t seem to be available from OpenX yet.)
However, what may not be immediately obvious from the OpenX documentation is that because OpenX’s Single Page Call code is generated at the website level, this means that the code will, by default, retrieve a banner for every zone configured in the website.
If you always display all of the zones on every page, then there’s no problem at all; but if you have many zones, and you don’t display every zone on every page, then using the Single Page Call code without modification will have two consequences.
Firstly, as you can probably imagine, the performance of your OpenX installation and your website will suffer. Asking OpenX to decide which banner to display for a given zone, and then having to transfer the banner display code for said banner, when you’re not even going to display it, is somewhat wasteful.
Secondly, if you have configured OpenX to log requests as well as impressions, you will notice that your requests are much higher than your impressions, because you are requesting banners that you then don’t even attempt to display. This often leads to concerns that perhaps there is something wrong with your OpenX installation, or that there is some reason why your impression values are “wrong” — when in fact, there’s nothing wrong at all, other than the fact you’re requesting banners that are never going to be used.
To improve performance, and to ensure that your request logging is correct, The Guru recommends that you use the “Advanced Usage” feature that is on the OpenX Single Page Call documentation. That is, if you are not going to display all of the zones defined for a website, and you are going to use the Single Page Call code, then you should define the OA_zones variable in JavaScript in the HTML header before your first Single Page Call code block, to limit the zones OpenX will request and return banners for.
For example, if your website has 5 zones defined (say they have zone ID values 1 through 5), and you are only going to display zone ID 1 and zone ID 4 on a page, then, you’d put the following code into your HTML header:
<script type='text/javascript'><!--// <![CDATA[
var OA_zones = {
'zone1' : 1,
'zone4' : 4
};
// ]]> --></script>
This code should be just above the “header script” part of the Single Page Call code, and of course, as per the OpenX documentation, you’ll need to change all of the “OA_show()” calls to match the names defined above — that is, when placing the “ad script” for zone ID 1 into your page, change the “OA_show(1)” to “OA_show(‘zone1′)”, and similarly for the “ad script” code for zone ID 4.
It may take a little bit of effort to implement, but the improved performance and more accurate statistics are well worth the effort.
The OpenX ad server offers a lot of flexibility — which is exactly what you want from a full featured ad management solution.
However, as with many things in life, with flexibility comes complexity. That means that as your website grows, and you start to need to manage more and more advertisers, or, if you’re running an OpenX installation that looks after more then one website, it can become very easy to get yourself tied up in knots when trafficking in the OpenX ad server, if you’re not careful!
To avoid getting yourself lost in a maze of trafficking management inside OpenX, one of the best things you can do is to use a naming convention for all of your OpenX entities.
While a “naming convention” sounds complicated, it doesn’t have to be. All that it means is that you (and your trafficking team, if you’re lucky enough to manage an OpenX installation large enough to need one), need to come up with a system for naming your advertisers, campaigns, banners, trackers, channels, websites and zones that means that, no matter what page you are looking at inside OpenX, you don’t have to think twice about what it is you are looking at.
Exactly how you do this will depend on how you (and your team) use OpenX. To give you some ideas, The Guru has seen all of the following used to great effect:
Client Codes
- Use codes to identify your clients (i.e. your advertisers, perhaps also your websites, depending on how you are using OpenX). A short, simple code is all it takes. For example, if you have an advertiser called Green’s Fantastic Veggies, then “GFV” might be a simple, easy to use code.
- Use these codes throughout OpenX. By including the client code in all entities (e.g. by putting “GFV” at the start of the name of all campaigns and banners that Green’s Fantastic Veggies run), then you’ll never have any confusion about who’s campaign or banner you are looking at, no matter which screen you’re viewing. This is especially helpful when looking at entities from the “reverse” point of view — for example, when viewing all of the banners linked to a zone, when only the banner names (normally from a number of different campaigns and advertisers) are visible.
- If you have any external systems for managing the contracts you have with clients, try and align your identification codes in these systems with those in OpenX.
Campaign Information
- Include information about how campaigns are set up to run in the campaign name. When looking at the statistics screens in OpenX, it is often very useful to be able to quickly identify the main points of how a campaign should be delivering without having to review the campaign configuration. For example, you could include:
- Details of the type of campaign — e.g. “EXC” for exclusive campaigns, “CON” for contract campaigns and “REM” for remnant campaigns;
- The start and end dates of the campaign, if it has them;
- Details of any campaign lifetime delivery targets;
- Details of any daily delivery targets.
Zone Position or Purpose
- Include something meaningful about the position or purpose of a zone in the zone name. Perhaps you use OpenX in a way where you have separate zones for separate parts of a website — the main site section, the sports section, the news section, etc. — so, make sure that you clearly name which zone appears where.
Size Information
- Including the size of banners or zones in the name isn’t really necessary, as OpenX will always make sure that you don’t link banners and zones that are of different sizes. However, there’s nothing wrong with including this information, as it can help with tracking down exactly where banners are being delivered quickly and easily.
Obviously, there is an almost infinite scope for how you can name your OpenX entities. Ensuring that you have a consistent, easy to understand naming convention that suits the way you use the ad server will go a very long way to helping you get the most out of OpenX, by keeping things clean, clear and easy to understand — and in the log run, this will help you save time, and make more money.
|
Unofficial Hosted Issue List Ask The Guru Got an OpenX problem The Guru hasn't written a tip about yet? Got an idea for a tip? Email: theguru@openxtips.com.
|