JT’s blog

fast ads

We’ve received a number of questions about ad serving lately so thought it would be helpful if we addressed the topic in our forum. Serving ads quickly is a top priority at the Rubicon Project and a subject we take very seriously. We recognize this is an important issue to publishers and their users, especially publishers that rely solely on ad networks as a primary source of income.

First, a little background:

Really, really big publishers rely on us to serve their ads quickly. From sites owned by Fortune 500 companies to publishers that generate millions of dollars a year in ad sales, the Rubicon Project delivers. Whether you have 100 or 100 million impressions a day, our technology will quickly serve up an optimized ad network (we’ve already done so more than 8 billion times!). Our ad serving technology was specifically built to optimize ad networks using the latest innovations and best practices—this is no duct tape system that’s been patched together for years and years. It’s custom built from scratch for your optimal benefit.

Our team has built huge systems before that rely on delivering super fast serving speeds: L90/admonitor, which sold to Doubleclick; MySpace; Ticketmaster and eToys. Each of those businesses is completely reliant on delivering fast serving speeds for customers (think of the uproar if 13 year olds in Kansas City couldn’t get their Hanah Montana tickets at 10 am on Saturday morning because the Ticketmaster site was slow!) As I like to say, this isn’t our first rodeo. Needless to say, our collective past experience has heavily influenced and direct the development of our massive, yet incredibly nimble, infrastructure.

Here’s how we handle ad serving speed:

Many publishers come to us with 3-4 ad networks, but even managing that number can be a pain, especially when it comes to ad serving speed. To make things easier (and more lucrative!), we optimize and serve across more than 60 ad networks, a number that’s growing every day, for our publishers. Occasionally, even with the fast serving speeds on our end, an ad network will have a hiccup serving ads, sometimes taking up to 15 seconds to appear. If this happens, we’ve designed our system so that publishers are able to immediately pause the slow ad network through the Rubicon Project UI until the ad network is able to fix the issue. No more yanking down tags! Management just became easier for publishers by reducing the possibility that an ad network “loses” access to their quality inventory from inactive tags.

To ensure that the we’re consistently serving ads at lightning fast speed we incorporate a number of measurement benchmarks, including our own internal testing process to ensure we’re doing everything on our end to not add any latency to the serving process; and incorporating industry standard 3rd party monitoring tools to keep an eye on things as well. We are committed to improving, and contributing to any slowness, in ad speed and delivery.

We also have a few other tricks we’re cooking up in the Rubicon Project labs specifically targeted at helping our publishers monitor and manage ad network’s ad serving speed. I will definitely keep you posted on our progress there so stay tuned.

Thanks and happy (super fast) monetizing!

Flashy, free ipod and punch the mokey– your favorite ads

I thought I would kick-off 2008 with a post about ad quality (a subject very near and dear to my heart).

Ad quality is very important to us. I have yet to meet a web publisher that didn’t care about ad quality—ads can have a positive or negative brand association for the web site as well as can enhance (mainly by providing free content) and in other instances distract from a user’s web experience.

The ad creative comes from the ad networks, not the Rubicon Project. You should view us as your advocate and watchdog. We talk to the ad networks every day about all sorts of things. In particular, we work with them to ensure the ads meet your content quality standards. We also screen the ad tags/feeds before loading them in our system. In addition, we are currently building out technology that should provide an extra layer of assurance that your standards will be met.

I also thought it was worthwhile to share our thoughts about ad quality. In general, I think there are three “types” of ad quality issues:

1. General content/creative quality- basically, this is about the general content/creative buckets you are willing to accept. Are you ok with ads that advertise dating services, or gambling, are “shaky” or the ever popular “punch the monkey” ads? Some of these can have high CPMs (like dating or gambling), where others are shown when the network doesn’t have much else to serve. Even if you are willing to accept the ads in this last group (the shaky, punch the monkey and so on), our technology looks to reduce their frequency as they generally have low CPMs.

2. Competitive filtering - pretty self-explanatory here: you probably don’t want your competitors advertising on your web site (although, if they are paying you a high enough CPM, you may be ok with it).

3. Ad relevancy: In general, having ads that are “relevant” is a great thing. It drives up eCPM’s and is likely more useful to your users. However, an ad doesn’t need to be contextually targeted to be relevant. Ads can also target your site’s users. Let’s say your users tend to be male—well then advertising trucks or Monday Night Football might be “relevant” even if your site’s content is not about automobiles or football.

Other times, ads are targeted at a user level (not just at a site/site content level). To make the example personal—I am a soccer fan on a soccer site, but I am still a soccer fan when I visit a finance site. Sometimes certain advertisers are willing to pay higher effective CPM’s to reach the audience they want, even though the ads aren’t contextually targeted and may not always seem “relevant”.

So here’s the ad quality trade-off:
The one thing to keep in mind about ad quality: restricting the ads you are willing to accept can often cause a drop in eCPM and fill rate. Luckily, the Rubicon Project’s interface allows you to manage that trade-off—and it’s not an all or nothing.

To reiterate: ad quality is a top priority at the Rubicon Project (and a top priority for me personally). We know it is currently a pain in the rear. Some networks are obviously better at it than others, but we hope to continue to make it easier for everyone, networks and publishers alike.

I’ve talked to a lot of publishers…

…and there have been some reoccurring themes to most of my phone calls. I thought I would try to summarize much of what I have heard and try to generate a larger discussion around them.

1. Publishers are really savvy. Despite a serious lack of technology solutions for them, publishers have rigged together all sorts of homegrown ways to manage (and maybe even optimize) their ad networks. That said, there are also quite a few publishers out there who haven’t had the time to deal with it (too busy running their site/business) and are leaving some serious money on the table.
2. It’s a lot of work managing multiple ad networks (and I have talked to sites that have more than 20!) On average, most of the publishers I talk to have somewhere between 2-5 ad networks and they have often tried 5-10. Publishers have to log in to all of the different interfaces for each network to pull their reports. They then have to calculate their eCPM’s in excel to figure out how often they should show each ad networks. They then need to program their ad server (or do it by hand) to show the right ad networks at the right time. At best, this can be done daily, but most publishers I talk to do this at most of once a week. This doesn’t even include dealing with tags, communication with the ad networks and the end of the month accounting after all the checks come in from different ad networks.
3. Sell through rates for ad networks are often quite low (in the 20-40% range). Depending on the site and the network, they can much higher, but still there is an obvious opportunity for improvement on all sites.
4. Publishers are tired of trying to figure out which ad networks are best for them. With all of the new ad networks that are rolling out, what is a publisher supposed to do? Publishers have to field all the sales calls and emails (or if you are like a lot of the sites—fill out some form and hope that someone will ever get back to you), watch the demo, complete all the paper work, test the tags and get the tags live on your site—this all must be done before you know or not if they are going to make you any decent money (for every ad network you want to try out!).
5. Publishers would rather spend time building out new content, working their site’s seo to drive traffic, improving the site’s ui or spend time with friends/families than try to manage a bunch of ad networks. How many people do you know who started a website just so they could manage a bunch of ad networks?
6. So many publishers have said to me “ad network X ‘gives’ me a $X cpm.” That strikes me as wrong in so many ways.
7. They all are very excited about the Rubicon Project. I think it is for 2 main reasons: we solve their pain points (and I really get the sense they are true pain points) and we will make them more money. I can definitely tell you that the enthusiasm from publishers has excited our team to work harder and faster to bring more publishers in to the beta program and to continue to improve our technology.

So, those are my thoughts. What do you think? Do you have similar thoughts or experiences?

Welcome David Tenser!

Please welcome David Tenser, our new SUMO Project Manager! We are all very excited to have David working on the SUMO project and back in the Mozilla family.

David is a longtime contributor to Mozilla and the Firefox and Thunderbird support sites,
authoring major parts of help content from the early days of the Foundation. Originally from Eskilstuna, Sweden, David has a BS and MS informatics and computer science. David was most recently Chief Software Engineer at Emsize AB in Sweden, where he led the development of supply chain software in the packaging industry. He recently participated in the Mozilla Memory bank project– you should check out his conversation with them.

Updating the update page

As you likely saw when you upgraded to the most recent version of Firefox, we show you a landing page to tell you that you have updated to the latest and most secure version of Firefox. We have also traditionally used that page as a way to communicate to you (and all the other users), most often about add-ons. We think that page could use a little work….

Below you will find the screen shots of the new versions of the page. Please check them out and give us your feedback.

Our primary audience is people who have not tried add-ons before; either because they have never heard of them or they don’t quite understand what and how useful they are. We hope to use the learnings from this effort to continue to improve how we communicate the “customization” benefit of Firefox across all of our properties.

We will be testing two versions of the update page. The first version is similar to our current update page, but with a design, copy and UI changes. Please note that with both versions of the page, we have included the “release notes” to tell people what changed when they updated Firefox as well as an easy way for them to go to their homepage if they are not interested in trying out add-ons.

The goal of our second page (below) is to introduce the user to specific add-ons from the start. We think that even if these specific add-ons aren’t appealing, the user will quickly “get” what an add-on is and will be interested in seeing more.

This page is the “landing page” that users will click through to if they are interested in seeing more add-ons. This page will also have a link to the full add-ons site. We will be testing two different versions of this page: one that shows 6 add-ons to users and one that shows 10. For all pages that show add-ons, we will be rotating add-ons through and tracking to see which ones were downloaded the most often.

SUMO meeting postponed to Friday at 3pm pacfic time

Sorry for the late notice, but this week’s SUMO weekly meeting has been postponed to tomorrow at 3 pm pacific time.

Looking forward to our call tomorrow!

Please give us feedback on the forum home page mock-up

We have been having lots of back and forth about the design of the SUMO forum home page. After much discussion and feedback, we have developed this mock-up:

For a general reference for comparison, please check out the SUMO homepage: http://support-stage.mozilla.org

Goals of this page:
1. To ensure that the user has searched through the knowledge base.
2. To get the user to search through the forum to find an answer to their problem.
3. If they can’t get their answer in 1 or 2, we want to make it easy for them to ask their question (we are currently missing a good explanation of how the forum works– maybe that is a call-out box that we link to– any ides?)
4. Make it easy for people to log-in and/or track their current questions

I would appreciate your thoughts and feedback here.

To get involved with the SUMO project, check out our contributor page.

Join us for our weekly SUMO project meetings

This will be a weekly, public call to discuss the progress of the SUMO project. Please join us!

Thursday from 2:00 pm - 2:45 pm pacific time

Phone call details:

• California: 650-903-0800 then extension 91
• Toronto: 416-848-3114 then extension 91
• Toll-free: 800-707-2533 then password 369

Then, enter your bridge number : 280

IRC: #SUMO

Introducing our Firefox Support leadership team

As a result of all the hard work of the support community, the Firefox Support Working Group has officially transitioned to the SUMO team. I am very excited to announce our SUMO leadership team:

David Tenser has been hired as the Firefox Support Project Manager. David is a long-time Mozilla volunteer and was responsible for much of the original support documentation for Mozilla (all the way back to the Phoenix days). David is joining us from Sweden, where he most recently served as a Chief Software Architect.

Chris Ilias, Jason Barnabe and Lucy Connor will join the SUMO leadership team as leaders of the knowledge base, forums and live chat, respectively. Chris, Jason and Lucy have not only been active support volunteers for many years, but have shown tremendous dedication to SUMO and are responsible for much of the progress so far.

Please join me in thanking David, Chris, Jason and Lucy for all their work and welcoming them to their new roles.

As a part of the new SUMO leadership team, I will be scheduling a weekly SUMO call that will be open to the public. I will post more details on the date and call-in info once it has been scheduled.

Update on status of support.mozilla.com:
We have been running performance testing on our current tikiwiki implementation as well as comparison tests for mediawiki and drupal. This data should give us a good understand of the scalability of our current implementation. We will publish the results early next week.

Also, we need your feedback on the forum design. Check it out here:
http://babyhook.com/SUMO/
username: forum
password: design

Enterprise Working Group Call Wednesday morning

From wiki.mozilla.org/Enterprise:

We’re planning our second call for Wednesday, August 8th at 10:00am Pacific, 1:00pm Eastern, 17:00 UTC. Here’s the meeting details:

• 650-903-0800 or 650-215-1282 x91 Conf# 280 (US/INTL)
• 1-800-707-2533 (pin 369) Conf# 280 (US)
• IRC - irc.mozilla.org - #ewg

The theme is “Wishlist.” Please feel free to update the Wishlist page before the call.