Mike On Ads

Most integrations between ad-companies that want better collaboration between their platforms/technologies/serving-systems involve inserting one parties ad/pixel/click call into the redirect stream. For example, if a Contextual engine wants to pass information about a page to an ad-network, the only real way to do that today is as follows:

1. Publisher replaces ad-call with a call to contextual provider
2. Users are now redirected to contextual provider first
3. Contextual provider checks the page, finds relevant keywords
4. Contextual provider redirects user to the ad-network with the relevant keywords inserted into the ad-call.

In reality most ad-calls involve multiple networks, each of which of course wants to integrate with various third-party technologies. The end result is an ad-call stream that can have four or five redirects before finally reaching the actual advertiser.

So what’s wrong with this you may ask? Well, there are a couple major issues with this redirect method of “integration”:

Redirects are inherently insecure. Redirects make the client’s browser responsible for “integration”. This means that any “integration” is entirely public, both to the end-user, any party that might be sniffing traffic in-between and perhaps most importantly — the party you are integrating with. When you insert a partner into the ad-call redirect stream they have full control over both the user’s cookie and the ad-request. Taking the contextual provider example above, the contextual engine that’s adding it’s data to the ad-request has the ability to start building a behavioral profile of the user, without you ever being the wiser.

Redirects slow down ad-requests. This results in a bad user-experience and dropped impressions. Each additional redirect results in about 3-5% of impressions lost. Of course this number varies on the speed of your serving systems and the end-users internet connection.

Redirects force linear one-way integration. Each party can only “pass off” the impression to the next — it is nearly impossible to reliably “pass back” information to the publisher who passed you the impression. This means that all impression level communication is ‘one-way’ — severely limiting the level of integration between companies. Why might you want ‘two-way’ communication? What if you could just ask a Network how much an individual user is worth to it? What if instead of having to insert a Contextual provider into the redirect stream you could just do a live ping? How about passing the user’s browsing history as you know it to an analytics company to build an “on-the-fly” profile? None of the above is easily done today.

This concept seems to be confusing to a lot of people, so in this post I thought I’d compare more traditional Web 2.0 “integration” without todays’ online advertising “integration.

The Traditional Web 2.0 Way

Let’s imagine that I decide that I want to display the 4 latest images from my Flickr account on the homepage of my website. To accomplish this I put some code into my web-server that pings the Flickr API on every page load and downloads the latest four photos that I’ve taken. The following diagram illustrates this:

Notice something very important — Flickr is never in direct communication with the user on my site. The only information they see is what my webserver sends them in the API request.

Of course this extra API call will slow down my site a little bit. The total time this takes to serve my homepage is limited by the speed of the user’s internet connection to my webserver plus the however long it takes for my webserver to query the Flickr API. If we assume the average cable modem can get to my site and back in about 500ms, and it takes my webserver about 100ms to query content from the Flickr API then the total time to serve my page will be a little over 600ms. If the Flickr API stops responding or slows down drastically I can simply time out the request after 200ms and serve my homepage without my favorite images. So the MAX response time is simply:

Now I decide that in addition to four Flickr photos I want to display four of my favorite Delicious bookmarks. So on each web-page request:

Notice that now my webserver goes off and sends off two concurrent parallel requests, one to Flickr and another to Delicious. Neither Flickr nor Delicious has direct access to my users as all communication must pass through my webserver first. Just as in the first example, I set a timeout of 200ms on both of my external API requests. So my response time:

Notice this is exactly the same max response time as with only a Flickr integration.

The Online Advertising Way

Now lets compare the “Web 2.0″ way with the online advertising way. Lets imagine that Mikeonads.com is working with “Network A”. Network A has contracted with a Contextual engine to scrape page content and extract relevant keywords for better targeted advertising. To do this the Network provided the publishers with an ad tag that points directly to the contextual provide. This means that every time a user visits Mikeonads.com he first requests the ad from the Contextual provider, who then redirects the user over to Network A inserting some relevant keywords into the ad-request. The following diagram illustrates this:

The first thing to notice here is that the user’s browser is actually making two completely separate sequential requests. This means that the contextual provider gets full access to his cookies on the user’s browser, and whatever information he can pull from server-headers & javascript: IP address, geo-location, page URL, etc. etc. Now some people might not care, but depending on the publisher this might be valuable data and fully exposing this is something that you really just want to avoid. This is the security risk I mentioned above.

Let’s analyze the response times. In this case, we have two separate requests to two separate serving systems. This means that the response time will be will be two round trips from the user’s browser to a serving system plus whatever processing time is required for each server. The reason we have to double up the user connection speed is because the browser cannot download the second request is until it has fully completed the first one. Taking the same 500ms round-trip number from above, and 10ms processing time we get:

Notice that this is already significantly slower than the Mikeonads<->Flickr integration. Now lets imagine that Network A decides that Mikeonads.com users aren’t very valuable and sells them off to Network B. In this case:

Now notice there are three different parties that each have full access to both the cookie and the javascript DOM tree. This means that each of these has an opportunity to install tracking cookies, install malicious software, etc. Maximum response time also increases drastically. We now have 3 full round-trips that happen sequentially, and hence our response time is:

Yikes! Total time has grown to 1.5s already! As you’ve probably deduced, if we throw in another serving system the time jumps to 2 seconds, add another we get to 2.5s. No wonder we lose 3-5% for every redirect! The problem simply gets worse and worse as the user’s internet connection gets slower.

The One-Way Limitation

I think the two examples above clearly show both the security & latency restrictions that arise from redirect based integration. The limitation of the “one way” are a little more subtle.

Control: Notice that in the ‘two-way’ Web 2.0 integration the Mikeonads webserver has an opportunity to make a decision based on the responses it receives from either Flickr or Delcious. For example, I could choose to exclude bookmarks tagged as “Suggestive in Nature”. In the online-ad example, Network A has no control over what content Network B returns to the user. There is nothing stopping Network B from showing an adult ad, or attempting to install some Malware on the user’s machine.

Accountability: Network A has no way of knowing whether Network B actually receives the impression. In fact, as mentioned earlier in many cases the user may simply browse to a new page before Network B has a chance to serve an ad. This leads to discrepancies in counting. In the two-way communication, not that Flickr cares, but if they were counting they would know exactly how many times Mikeonads served a web page with Flickr images.

Blindness: Before Network A redirects to Network B he has no clue what is going to happen financially. If he has a revenue-share agreement he doesn’t know how much money he will make until after the fact. Not only that, but there is no way for Network A to ever put an exact value on an individual impression as the data he receives back from Network B will be aggregated up.

There are many more subtle limitations as well. But rather than focus on listing them here, in the next post I will dig into the “one-wayness” of redirects, potential work-arounds and the gains to be had by fixing this problem.

I’m actually a bit embarassed here, this was sent to me about a month ago and got lost in my email with the general business of the holidays. Many thanks to Matt Cannon @ eType for doing all the research:

Spotted a variation on freecar: link. Appears to make a call to:
http://traffalo.com/statsa.php?campaign=cle9ne9t&u=1196943687109

So I then look at http://traffalo.com/ and do a WHOIS and get the IP:
http://www.networksolutions.com/whois/arin-details.jsp?domainTitle=traffalo.com&ip=190.15.73.254

I then find what is hosted on 190.15.73.254, and BINGO!

190.15.73.254 has address 190.15.73.254
Found 89 websites with the IP 190.15.73.254

1) FILEPROTECTOR.COM” gping=”&POS=81&CM=WPU&CE=62&CS=AWP&SR=62&sample=0
2) MYFAVOURITESEARCH.COM” gping=”&POS=74&CM=WPU&CE=55&CS=AWP&SR=55&sample=0
3) OPENSOLS.COM” gping=”&POS=83&CM=WPU&CE=64&CS=AWP&SR=64&sample=0
4) ad2cash.net” gping=”&POS=37&CM=WPU&CE=18&CS=AWP&SR=18&sample=0
5) ad2profit.com
6) adgurman.com” gping=”&POS=51&CM=WPU&CE=32&CS=AWP&SR=32&sample=0
7) adnetserver.com
adredired.com” gping=”&POS=47&CM=WPU&CE=28&CS=AWP&SR=28&sample=0
9) adtraff.com
10) adverdaemon.com
11) adverlounge.com” gping=”&POS=40&CM=WPU&CE=21&CS=AWP&SR=21&sample=0
12) adzyclon.com
13) all-search-it.com
14) antivirussecuritypro.com” gping=”&POS=99&CM=WPU&CE=80&CS=AWP&SR=80&sample=0
15) astalaprofit.com” gping=”&POS=38&CM=WPU&CE=19&CS=AWP&SR=19&sample=0
16) b2adz.com
17) b2adz.com” gping=”&POS=63&CM=WPU&CE=44&CS=AWP&SR=44&sample=0
18) bestadmedia.com” gping=”&POS=110&CM=WPU&CE=91&CS=AWP&SR=91&sample=0
19) besteversearch.com” gping=”&POS=113&CM=WPU&CE=94&CS=AWP&SR=94&sample=0
20) bestsearchnet.com
21) brandmarketads.com” gping=”&POS=39&CM=WPU&CE=20&CS=AWP&SR=20&sample=0
22) candid-search.com
23) cashloanprofit.com” gping=”&POS=36&CM=WPU&CE=17&CS=AWP&SR=17&sample=0
24) casinoaceking.com
25) co-search.com
26) deuscleanerpay.com” gping=”&POS=77&CM=WPU&CE=58&CS=AWP&SR=58&sample=0
27) didosearch.com
28) easybestdeals.com
29) eroticabsolute.com” gping=”&POS=27&CM=WPU&CE=8&CS=AWP&SR=8&sample=0
30) favourable-search.com
31) fileprotector.com
32) findbyall.com
33) freerepair.org
34) friedads.com” gping=”&POS=42&CM=WPU&CE=23&CS=AWP&SR=23&sample=0
35) fulsearch.com” gping=”&POS=114&CM=WPU&CE=95&CS=AWP&SR=95&sample=0
36) getfreecar.com
37) great4mac.com
38) kazilkasearch.com
39) libresystm.com” gping=”&POS=116&CM=WPU&CE=97&CS=AWP&SR=97&sample=0
40) loffersearch.com
41) luckyadsols.com” gping=”&POS=67&CM=WPU&CE=48&CS=AWP&SR=48&sample=0
42) magicsearcher.com” gping=”&POS=75&CM=WPU&CE=56&CS=AWP&SR=56&sample=0
43) manage-search.com
44) megashopcity.com
45) mightyfaq.com” gping=”&POS=43&CM=WPU&CE=24&CS=AWP&SR=24&sample=0
46) misc-search.com
47) moneycometrue.com” gping=”&POS=41&CM=WPU&CE=22&CS=AWP&SR=22&sample=0
48) moneypalacecash.com” gping=”&POS=118&CM=WPU&CE=99&CS=AWP&SR=99&sample=0
49) moneypalacecash.com” gping=”&POS=21&CM=WPU&CE=2&CS=AWP&SR=2&sample=0
50) myhealth-life.org” gping=”&POS=82&CM=WPU&CE=63&CS=AWP&SR=63&sample=0
51) myonlinefinance.com” gping=”&POS=94&CM=WPU&CE=75&CS=AWP&SR=75&sample=0
52) mysurvey4u.com
53) mytravelgeek.com” gping=”&POS=101&CM=WPU&CE=82&CS=AWP&SR=82&sample=0
54) netturbopro.com
55) opensols.com
56) pcsupercharger.com
57) popadprovider.com” gping=”&POS=65&CM=WPU&CE=46&CS=AWP&SR=46&sample=0
58) popupnukerpro.com
59) prizesforyou.com” gping=”&POS=100&CM=WPU&CE=81&CS=AWP&SR=81&sample=0
60) roller-search.com
61) rombic-search.com
62) rombic-search.com” gping=”&POS=32&CM=WPU&CE=13&CS=AWP&SR=13&sample=0
63) se7ensearch.com
64) search-the-prey.com
65) searchcolours.com” gping=”&POS=78&CM=WPU&CE=59&CS=AWP&SR=59&sample=0
66) searchmandrake.com
67) searchonline-ease.com
68) searchoperation.com
69) searchvirtuoso.com
70) sellmoresoft.com” gping=”&POS=97&CM=WPU&CE=78&CS=AWP&SR=78&sample=0
71) sellmosoft.net
72) selvascreensaver.com” gping=”&POS=102&CM=WPU&CE=83&CS=AWP&SR=83&sample=0
73) sharpadverts.com” gping=”&POS=66&CM=WPU&CE=47&CS=AWP&SR=47&sample=0
74) shivanetworking.com” gping=”&POS=62&CM=WPU&CE=43&CS=AWP&SR=43&sample=0
75) simplesamplesearch.com
76) softwcs.com” gping=”&POS=108&CM=WPU&CE=89&CS=AWP&SR=89&sample=0
77) stratosearch.com
78) tallgrass-seach.com
79) traveltray.com
80) treekindsearch.com
81) wewillfind.com” gping=”&POS=109&CM=WPU&CE=90&CS=AWP&SR=90&sample=0
82) wontu-search.com” gping=”&POS=46&CM=WPU&CE=27&CS=AWP&SR=27&sample=0
83) workhomecenter.com
84) yourseeker.com
85) yourshopz.com” gping=”&POS=103&CM=WPU&CE=84&CS=AWP&SR=84&sample=0
86) yourteacheronline.com” gping=”&POS=106&CM=WPU&CE=87&CS=AWP&SR=87&sample=0
87) zappinads.com” gping=”&POS=107&CM=WPU&CE=88&CS=AWP&SR=88&sample=0
88) zooworld-search.com
89) zooworld-search.com” gping=”&POS=30&CM=WPU&CE=11&CS=AWP&SR=11&sample=0

online pharmacycialisviagrasoma

Tired of hearing about Beacons? I know I am, so if you are, stop reading. (yes, that probably makes me a hypocrite for writing this post in the first place).

First off — It’s fascinating how the Silicon Valley love-fest can backfire like all hell. Just a few months ago Facebook was the best platform. Everyone proclaimed they were going to win, they had the winning API, they were so much cooler and better than Myspace. Kind of amazing how fast people will turn on you.

Second I’d like to point you to a Freakonomics post, “Why Is Family Guy Okay When Imus Wasn’t?”, which has probably the best explanation as to why this seems to have such a dramatic impact. Stephen asks why Imus got fired from his job for a bad racist comment when a show like Family guy airs similar or worse comments on a daily basis:

5. There is no real difference between the two, but the kind of big public storm that resulted in Imus being fired is essentially a random event, unpredictable and nearly inexplicable, and it typically arises when political, social, and media pressures all align just right. It can’t be concocted, or controlled. It happened to Imus because it happened; and it hasn’t happened to Family Guy just because it hasn’t.

Now to some extent this wasn’t a purely random event. Facebook has been the poster-child of the valley, so it was only a matter of time until they made a bad move. The fact that everyone happened to pick Beacons, more random.

What bugs me is that the media picked this particular invasion to draw attention to. You think Beacons are invasive? How about the fact that your ISP might be installing a sniffer box that not only tracks what you buy — it tracks everything. It tracks what movies you watch, what sites you go to, where you purchase things, how often you purchase things. I mean, that freaks me out a hell of a lot more than a little Facebook Beacon — because one you can control, the other you cannot. Don’t believe me? Check out: NebuAd or AdZilla. Or how about Errorsafe? The little program that installs on your machine and probably sniffs out and steals your credit card numbers when you buy something. It’s being distributed via advertising networks left & right, yet I don’t see much media attention there either.

Maybe it was part random, part fate — but Facebook has definitely gotten the full fury of the blogosphere thrown at it these past few weeks. So bloggers & journalists. We get the point — Facebook invades your privacy. It has from day one, showing your friends pictures, status updates, all sorts of things. Don’t like it? Stop using Facebook. In the meantime, please pay some attention to some more invasive and much scarier things, like Errorsafe or ISPs that sniff and sell your data without the opportunity to opt-out.

Greg Yardley wrote a nice post explaining how advertiser use pixels (also known as beacons) to track conversions. Nice read for those that don’t understand how conversion tracking happens.

I will disagree with Greg though that we haven’t had privacy online for a while — even though our actions are being tracked they are all on an anonymous basis. Facebook is the first that wants to tie this with a name. There’s a big difference between being able to say:

“A user with cookie ID #ace8748dff clicked on a Netflix ad at 10:45am on Nov 29th on mikeonads.com after having seen it four times and then signed up for a 30 day trial.”

and

“Mike Nolet bought Netflix today.”

I’m fine with the former, but the latter kind of freaks me out!

Ok, so first off — I think I’m back to blogging. I needed a little break after leaving Yahoo, starting new things, but I’ve had a lot of interesting conversations in the past few months and some interesting new thoughts about the industry & life in general.

I know this is somewhat unrelated to advertising, but Andrew Chen motivated me with a great post on why Myspace is still more popular than facebook. I’ve thougth about this a bit as well and agree that Silicon Valley people simply aren’t Myspace people. I’m not one either, I hate the fact that it’s so ugly and unstructured — but as Andrew points out, we’re not like the rest of the world. I also don’t like NASCAR, Oprah or Self-Help books, but each of those are billion dollar markets.

So I thought I’d throw out a couple other reasons why Silicon Valley should stop hyping Facebook for a few minutes and take another look at myspace:

Myspace has had full unhindered third party functionality for years

Facebook apps are great, but by being so incredibly structured they are also incredibly limiting whereas on Myspace non-limited third party apps have been a possibility for years. I can place any HTML on my myspace profile, which means I can embed any sort of dynamic third party content. Sure there are some security concerns, profiles get hacked and all that fun stuff, but users don’t care. This super simple method of allowing third party developers to provide applications for Myspace users in many ways works much better than the very structured Facebook App.

Myspace has built a solid behavioral ad-targeting platform

While Facebook is getting hammered in the press for their “Beacon” product, Myspace quietly, and with no complaints has rolled out a new behavioral platform based on their SDC acquisition earlier this year. They just recently announced that the “FIM Serve” platform will power the rest of Fox Interactive Media’s properties as well.

Considering it’s been less than a year I think this is a rather impressive feat. Building a massively scalable ad targeting platform isn’t easy. Myspace also managed to do it in a way that didn’t piss off it’s users, and with minimal negative press.

Myspace didn’t waste time building a CPC ad platform

Look, lets all admit it, Google is the best at CPC, contextual & all that fun stuff. Everybody tries, but nobody can even come close. So while Myspace goes off and signs a $900 million deal with Google, Facebook builds it’s own platform. Combine the Myspace search & cpc deal with the behavioral ad platform and there’s a solid revenue generating strategy.

Where’s Facebook? Microsoft reps their ad-inventory (and word on the street they’re losing money on this), they don’t have a search partner and have built their own CPC engine which from what I’ve heard isn’t that good.

Myspace makes money

Lots of it. It’s hard to find accurate numbers out there, but estimates lie in the $500-700m for 2007. I can’t find a reliable source, and it’s hard to tell now that Myspace has been acquired by News corp, but they’re supposedly quite profitable. In the meantime Facebook with all it’s hype is getting $15 billion valuations, and raising money to help their own cash flow.

Building for the sake of building

In the end, the big difference between Myspace and Facebook is that one is a technology company, and the other is large social network. Silicon Valley loves the tech company, but this is a great lesson that a lot of companies in the ad-space should consider as well. It’s generally not the best technology that wins — it’s the one that solves the right problem. Your end users will often not care whether you did that elegantly or not, they will care that it works.

Facebook clearly has the better technology. The Facebook platform is fast, elegant, and chock-full of features. Even so, the ugly Myspace page with an IFRAME on it manages to both attract more users and provide a better feature set. I myself may not like it, but then again I’m one of the few people who appreciates the elegant execution on the technology side, your average person does not.

So while reading my blog reader this morning I realized there were quite a large # of posts about malicious ads (aka Errorsafe) coming through. All this new media attention to the problem is good, but saddening that people still see so clueless. Perhaps even worse is the fact that industry folks don’t have a good grasp on the problem yet.

Take this eweek article on malicious ads. Lets look at some of their findings:

There is, in fact, a scourge of so-called “badvertising” infiltrating legitimate sites. Since Sept. 22, the ads have been finding their way into the servers of the advertising industry’s biggest players, such as DoubleClick.

Wow… these guys are really up to date. I created my “Errorsafe” page on March 22nd of 2007, and that’s after many months of frustration with malicious flash banner ads. The first “major” infiltration I know of dates to the summer of 2006 when Myspace served a malicious ad to its users. The tools & technology haven’t changed — the code might be more obfuscated, but it’s still the same type of flash ad executing similar javascript. Oh, and Myspace used DoubleClick for hosting back then.

If only it were so simple. In fact, there is no such anti-spyware that could be built into an ad-serving platform such as DoubleClick. The buyers who are purchasing advertising space on sites and then swapping in malicious ads are far too sophisticated to code their malicious code with something so crude as to be picked up by anti-spyware software.

Of course it’s possible to detect these ads, it just takes a little bit of work. Right Media has such a system. I’m also aware of at least two different companies that are looking to develop similar automated testing tools.

“The big issues that security researchers who deal with Web exploits and downloaders on Web pages struggle with every day are the different ways you can make JavaScript do different things. As long as you accept Flash and it has ActionScript, there’s no way to rule out a repeat of this fiasco.”

Not true. I proposed a fix in this post that should be fairly trivial to implement. Instead of assuming that actionscript is safe, everyone should assume that it’s unsafe. Then, the few ads that require special permissions (such as complex rich media ads) can go through a manual review and receive explicit permission to execute script.

So here’s my proposal — What if the industry giants got together and created one central repository of “safe ads”. This non-profit central body would do a manual audit of all the action-script within all ads and certify them as safe to run. Then, instead of emailing creatives around buyers would send an ID or link to the ad in the central repository. It’s a lot of work, but considering how much money is on the line, I’m sure it’d be fairly easy to get some funding together to do this.

Yahoo, Google, Microsoft — somebody up for setting this up? I’ll help =).

Just wanted to write a quick note — I haven’t written a post in ages because I’m in the process of starting a new venture. New venture -> lots and lots of work -> very little time to blog. I promise I’ll write some more things soon, and also that I’ll post a link to the new venture. For now, if anybody knows any really solid systems administrators or senior web-guys, please send them my way!

No, this isn’t another “OMG, the facebook API IS AWESOME” post. I mean, it is, it’s pretty damn cool, I’ve played with it a bit this month. The real revolution with the facebook API are the server-side requests.

Traditionally widgets & plugins interfaced with social networks by placing snippets of HTML on profile pages. In the Facebook world no content can show up on a user’s profile without passing through Facebook’s servers first. Even your actual application pages must either be within an IFRAME or pass through Facebook. This process provides Facebook with an extraordinary level of control over what can and cannot be displayed on a user’s page. FB can perform a virus scan on all content and analyze any scripts for vulnerabilities or exploits. By directly serving content Facebook also eliminates cookie access — making it far more difficult to track or distribute data about their users.

Yet, the approach has it’s limitations for application developers. I tried briefly to build a “stalker tracker” application which using cookies would tell the user how many people regularly checkout their profile page. No matter what I tried, I couldn’t get access to the cookie without somehow initiating a click — rendering my application completely useless.

Why should you care? Well — advertising isn’t that much different from a traditional social networking widget — both are delivered via a snippet of HTML. Online ads have also been plagued by security issues this past year and I wouldn’t be surprised if the bigger players (Myspace, Yahoo, MSN, etc.) start to ask for server-side ad-requests soon. Server-side requests are the only way that a seller can technically guarantee the safety of third-party ads. Of course this will open up a world of technical challenges — server-side cookies storage, strict global latency requirements and a need for increased capacity to only name a few.

Many publishers either don’t have a strategy for maximizing network revenue or use aging technies such as daisy-chaining to

Out of all the publishers that I’ve talked to many don’t have a solid strategy for maximizing revenue from ad-networks. Many simply don’t understand how networks price, since most are black-boxes that don’t publish how they optimize and choose which ads to display. Yet, there are a couple factors that I find can be large drivers of revenue.

The more times an individual user sees an ad, the less likely he is to respond to it. Ok, seems obvious right? What you may not realize is exactly how quickly user response to an individual ad drops. The following graph is fictitious but representative of the normal response curve of a user on a single site to repeatedly seeing the same ad.

What the above shows is that if you are to maximize revenue you need to start thinking about users and not impressions. A user that’s been on your site for hours and has seen a hundred ads is far less valuable than someone who just logged-on.

Of course every ad-network will tell you that they have a large # of advertisers and deals and that you shouldn’t worry about such things — but lets not forget the Pareto Principle, also known as the 80/20 rule. A small percentage of top advertisers will generate the majority of revenue (and hence higher rates). What that means is that each ad-network will only have one or a couple high CPM ads.

Hence the effective CPM that you receive per user from a network declines as that network continues to see him over and over again. The larger the network the slower the decline, but each will look similar — here’s a rather rough sketch of what various network payout look like (again, numbers are hypothetical, but shape of graph will generally be correct).

Obviously daisy-chaining will not work in this situation as both the medium and large networks have paying ads for each individual ad-view. In the hypothetical example above, you would want an individual user to see the following sequence of ads to maximize revenue:

1. Small
2. Medium
3. Large
4. Medium
5. Large
6. Large
7. Medium
8. Small

Comparing the effective CPM of each network individually versus optimized together:

What you see is that you can vastly increase your CPMs by distributing your networks. Now — although these are fictional numbers — the concepts are real and they work. So how do you do it? Rather simple!

It’s impossible to allocate impressions on a per view basis as I did above so we must rely on a little bit of approximation. The way to do this is to setup multiple placements or zones with your ad-network and then to frequency cap them individually within your own adserver. The above could look something like this:

The key here is not to over-complicate. Sure, a Myspace, Facebook or Bebo may create hundreds of different placements each with different caps and priorities, but there are two reasons you shouldn’t

1. It’s incredibly resource intensive to manage
2. You don’t have enough inventory

Each placement needs to run a minimum amount of volume otherwise pulling out the effective CPM will be nearly impossible. A lot of pricing is based around user response to ads — eg CPC or CPA based pricing. Since clicks and conversions are rare events you need to have enough volume in each placement to get a predictable effective CPM. On CPC networks you can probably get away with a couple thousand impressions per placement per day but on CPA you’ll want to go closer to ten to twenty thousand.

There is some art here as you will have to update both the frequency caps and the pricing on your placements regularly. The first couple times chances are you’ll see your network cpms fluctuate as you play with the caps & inventory allocations but as you get a hang of it you should gain some serious lift.

Enough for today — next, how to effectively target network placements to maximize revenue.

They’re getting smarter and smarter! According to SC Magazine the malicious banner ads have hit up Myspace, Photobucket, Bebo and and Ultimate Guitar. Interestingly enough:

The fictitious ads know to remove the malicious code if they detect the known IP addresses of the Right Media scanning servers.

Well, I say enough! Thanks to Mandy Singh for the tip about using flash permissions to restrict what the ad can do on the site. The malicious ads use javascript to both determine whether or not to and actually execute on the drive-by installs. This permission can be restricted by using the AllowScriptAccess flag. I’ve tested this on various errorsafe flash files and indeed it prevents them from launching an install.

So here’s my proposal — the default for serving any ad should always be with restricted script access. Of course this will probably break certain rich-media ads, which should be individually certified as ’safe’ and given explicit approval to execute javascript.