Mike On Ads

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

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:

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!

This is a fairly well known problem in the industry — you target a keyword, say ‘travel’, thinking that you will end up on searches & sites relating to travel. Next thing you know you end up next to a New York Times article talking about the recent plane crash in Lima and how it’s limiting travel to South America — oops

Well — the same thing happened to my blog today and good old Mr. John McCain. Although I guess it shouldn’t be too surprising, I found it slightly ironic that John McCain was advertising next my blog post criticizing his advertisements. See the bottom left on the following screenshot:

And the landing page:

Now first off — these ads look much better than before — maybe they read my earlier post? Now I am incredibly curious whether or not these ads are ROI positive in that they bring in more money in donations than is being spent on media. Anybody know??

Saw this John McCain ad on a random blog this evening:

Reminds me greatly of the giveaways you normally see on myspace… seems they forgot to leave out the “get a free lecture on public policy!!”.

Landing pages even look the same — a simple form with a ZIP & email. I wonder if they’ll sell my email address for $2.00 and use my Zip for later retargeting later.

What’s interesting though is that it looks like the McCain campaign is doing some serious remarketing on “clickers”. There are pixels there for the Right Media Exchange, Ad.com’s Leadback and Atlas!

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

I was just browsing on my gender test blog post and noticed the following ad:

So normally you’d say — so what mike, it’s just an ad for senseo! Well this ad is special because I was just searching for Senseo coffee pods earlyt his morning (both via Google & Amazon.com). I find it highly unlikely that this is a pure coincidence. Here’s the clickstream (broken into multiple lines and shortened for legibility):

http://pagead2.googlesyndication.com/pagead/adclick?sa=L&ai=BSrzSV[...]

http://www.sharesenseo.com/index.jsp?q=a-googlewomen

Funny that there is a nice “q=a-googlewomen” inserted into the landing page — I swear the gender test showed me to be a man!! So this is all purely speculative of course, but if this is indeed true then we suddenly have the world’s best behavioral display network to compete with.

Currently experiencing some site issues (Error 500 codes). If you see this, hit refresh a few times and page should appear after a few tries.

Really should move this site to some better hosting… maybe a cloud provider!