Notice: This blog is no longer updated. You may find a broken link or two

You can follow my new adventures @mikeonwine


I just realized that I broke commenting on my wordpress a couple weeks ago — realized that things had been a little quiet recently! I screwed up and Akismet (the anti-spam) was marking every single comment as spam. Problem has been fixed but I fear a lot of comments have been lost in the 4000+ spam comments.

Apologies to any of you that have commented and got spammed (and if you remember your comment please repost it!).

AdECN announced their new ‘Federated’ exchange today. What’s the difference? Ad-Networks will be able to bid on AdECN impression in real time.

“Our goal is to provide a fair and level playing field for all the online advertising industry players to play on,” said Jeff Green, co-founder of AdECN. “The federated system simplifies online buying and selling. It will allow ad networks to use their own tools in which they have invested large amounts of time and money, to connect advertisers and publishers across the industry.”

Now as I’ve heard this is something that’s been in the works for quite a while and Microsoft is certainly not alone in moving in this direction. I’ve heard that both Google and Yahoo have been actively recruiting networks for real-time bidding on their respective exchange platforms.

More thoughts on this tonight when I have some more time to write.

Awesome Apple Combo Ad

September 18th, 2008

Just saw this terrific combo ad on the New York Times for Apple where the 728×90 interacts incredibly well with a fat sky on the bottom right. I must say, I wish more advertisers would engage more with the content they are appearing on. I love how the ad is meant to look like a newspaper article, integrating quite well into the NYT homepage experience. I’m sure this cost them an arm & a leg to run, but it sure as hell grabbed my attention!

Screenshot: (click to watch video)

Quality Matters!

September 16th, 2008

Ads being shown by Google Adsense on Recent Posts:

Here’s the problem — I don’t really care how much money I make from advertising on this blog — I care far more about it’s reputation, which of course reflects on my personal reputation. Now I have nothing against display ads — in fact I have spent quite a bit of time optimizing themselves, but give me a filter. Why is it that adsense only gives publishers the option to either “show display” or “do not display”. Give me a “recognized brands only” button! Let me filter out these crappy ads! Let me select advertisers who I will allow to show display ads… give me control!

Thankfully for the rest of us, Google still has a bit to learn about display! In the meantime, I’m switching back to text ads only.

In this blog post I examine the time difference between three different methods of “redirecting” users from one adserver to another. I find that there is a significant difference in latency between 302, IFRAMEs and JavaScript redirects. Specifically — JavaScript redirects are 70% more likely to last longer than a second than 302 redirects. Read on for the details!

Introduction

In the advertising world today there are three primary methods of “redirecting” a user from adserver to another: “302″ redirects (aka URL creatives), IFRAME tags and JavaScript.

302 Redirects: The HTTP 302 status code means that the site being accessed is called “Moved Temporarily”. This is the simplest and easiest way to redirect a user from one adserver to another. When the user’s browser loads the first ad-tag the server responds that the service the user is trying to request (the ad) has “moved temporarily” and passes a URL where the proper content can be grabbed.

IFRAME Tags: In this scenario the adservers responds with a simple HTML page that contains an IFRAME HTML tag with a src URL pointing to the next adserver from which to load content. An IFRAME tag can be most simply described as a page within a web-page. The browser generates a mini web page within the parent page and loads content from the specified source URL.

JavaScript: In this scenario the first adserver responds with javascript code which subsequently called the function “document.write” to inform the browser where to load subsequent content.

So if all we’re trying to do is accept an ad-call and determine which party it is best to redirect to, what’s the difference between the three? Using JavaScript has a minor advantage that it enables the first adserver to execute some logic before redirecting off to the next partner. For example, if the browser language is set to english and timezone is EST then redirect to advertiser A, otherwise redirect to advertiser B. Other than that there are minor technicalities that can be discussed but really — each method accomplishes the same thing.

The Experiment

I’ve always been curious about the performance difference between the three different redirect types and a recent surge in traffic was the perfect opportunity to test this out! So since August 1st I’ve been running a little experiment on the visitors of this blog.

On each page load I make the browser run through a simulation where a fake publisher adserver redirects off to a fake advertiser adserver. Each time this happens I time how long it takes for the browser to load the advertiser adserver after loading the initial publisher ad tag. How it works is simple.

On the top of every page there is an IFRAME that points to “/redirect_testing.php”. This page randomly decides either to do a simple 302 redirect, write out an IFRAME or return JavaScript — each method redirects to the same page and the results are shocking.

First off, out of a total of 476,635 samples there was a nice even distribution between the three — 159,897 redirects, 158,193 iframes, and 158,545 javascript redirects — almost exactly a third each. I split the result data into four different ‘speed categories’.

Fast Requests: These are requests in which the advertiser adserver content was loaded in under a second.

Medium Requests: In these it took greater than one second but less than two seconds to hit the advertiser adserver.

Slow Requests: If it took longer than 2 seconds to load the adv-server they are certainly slow requests!

Timeouts: The second request never happened! Uhoh.

The Results

speed type count(*) avg_time
fast redirect 133008 0.365
fast iframe 120544 0.395
fast script 113264 0.445
medium redirect 10937 1.384
medium iframe 14307 1.408
medium script 17626 1.389
slow redirect 14255 6.519
slow iframe 20720 5.889
slow script 22035 5.877
timeout redirect 1697 null
timeout iframe 2622 null
timeout script 5620 null

The first thing that popped out at me when I looked at the above table is that redirects appear to be 80ms faster than javascript on “fast” requests. On medium requests redirects continue to be the fastest although only marginally more than javascript. The anomaly appears in the “slow” category, although at this point we’re looking at a very low percentage of requests.

The second thing that popped out at me was that redirects and iframes seems to be significantly more likely to be “fast” requests than javascript. Digging further:

Redirect IFRAMEs Javascript
Fast (< 1s) 83% 76% 71%
Medium(>1s, < 2s) 7% 9% 11%
Slow (> 2s) 9% 13% 14%
Timeout (> 30s) 1% 2% 4%

Wow. 17% of “redirects” were slower than one second versus 29% for Javascript. Putting that in other words –> Javascript redirects are 70% more likely to take longer than a second than simple 302 redirects.. The second surprising bit is that IFRAMES aren’t that much better with 24% of requests taking longer than a second.

Why should you care? Well, latency matters. And not only from a “keep your users happy” perspective. Every additional 100ms of latency increases the likelihood that your user moves to another page, stop loading the page .. or in other words -> every 100ms of latency added is another subset of your users that are lost.

So how are you redirecting over to your advertisers? Can we all please just 302?

Josh Kopelman from First Round Capital (one of our investors here @ AppNexus) has started a great little site for those of you considering leaving Wall Street for a startup!

While no one is happy with the turmoil we’re seeing facing the financial services sector, and no one is happy to see mass layoffs, this does represent an opportunity for startup companies to attract seasoned, technical talent. With Bear Stearns laying off over 7,000 employees, Lehman Brothers rumored to layoff over 20,000 employees, and Merrill Lynch expected to layoff thousands after their sale to Bank of America, we’re on track to see over 150,000 people lose their jobs this year.

If you are one of those 150,000 employees, you might want to consider joining a startup. These days, startups are more stable than Wall Street (seriously). And while a startup probably won’t offer the creature comforts of a job in the financial services industry, startups offer different benefits. You get to participate in the creation of something new. Your work makes a direct (and clear) impact on the success or failure of the company. No more politics, endless meetings, or multi-layered organization structures. Plus, you’ll likely get stock options to share the upside.

Check it out: http://www.leavewallstreetjoinastartup.com/

First off — the ad is still showing. If someone has a contact @ Mashable, it’d be good to send them a note.

Greg Yardley thinks that this ad is not served by the Adsense network but instead by Mashable’s internal salesforce and that they are simply using Google’s new AdManager product as their adserving solution. Digging through the tags, it’s unclear whether or not this is the case. The actual creative is hosted on the domain “pagead2.googlesyndication.com” which has traditionally been used to host Adsense creatives and ad tags. Google’s AdManager runs on a different domain — “partner.googleadservices.com” — but it is certainly possible that AdManager and AdSense share the same underlying static content delivery system. (someone from Google care to comment?)

This is an excellent example of the fact that URLs generally don’t provide enough information to identify who is delivering the actual advertisement on the page. In this Mashable/Google page, it is unclear — it could be Mashable’s internal salesforce selling the ad — or there could be some server-side integration between AdManager and Adsense and Adsense is responsible for serving this actual creative. Right Media suffered from many of the same problems — people would always yell at the Right Media Ad-Network whenever a creative hosted at content.yieldmanager.com was causing problems, even though that single domain was shared across 50+ networks.

The solution that we came up with @ RM was to start using DNS CNAME aliases when returning any and all content. A CNAME is a simple DNS record that simply says — “this domain name is an alias for this other domain name”. So for example, the domain “content.cpxinteractive.com” is an alias for “content.yieldmanager.com”. This way, if CPX was responsible for serving a bad ad the offending URL would be “content.cpxinteractive.com/ad.jpg” and not “ad.yieldmanager.com/ad.jpg”. CNAMEs allow central serving systems (eg, AdManager) to both hand out tags and return creative content tagged with an owner while still maintaining the same internal systems.

Matt Cannon sent this one over to me yesterday afternoon. He saw Google showing this lovely ad for MediaMan on mashable.com at about 1pm EST. MediaMan has been identified a long time ago as a malvertisement so it’s a surprise to see them popping up on the Adsense network. Details are below. Now I’m not posting this to shame Google (I’m sure their content team has already pulled this ad) — I’m posting this more as a call to action. It’s time that we start grouping together as an industry to help stop this. More thoughts coming on that shortly.

Screengrab of ad on Mashable:



Source of the ad (warning I would not open this if I were you):

http://pagead2.googlesyndication.com/pagead/imgad?id=CLK8lreVvKyciwEQ2AUYWjIIqyqX6hvFaHc

Screengrab of the ad:



And for the first time in a while (probably because I’m in Moscow!) I actually got the actual trigger, and got this nice popup:



and was redirected to this lovely landing page:



Pete Warden took my little hack and modified it to go to another level — integrating the search results with the del.ico.us API to generate a “tag cloud” of sites you have been to. What’s interesting is that (at least for me) the tags were pretty accurate. It’d be interesting to do this with actual browsing history (not just the top 10k) and some incorporation of frequency & recency.

Check it out!

I spoke at AdMonsters 360 last week about Malvertising (aka Errorsafe). It was a great session (at least I enjoyed it). I’ve included the powerpoint presentation I put together below, feel free to chop up, re-use do whatever you with it.

Downloadable PPT version: admonsters-presentation-2008-06-16