Mike On Ads

PubMatic just released a new AdPrice Index which was immediately picked up by a rather frightening number of news sources: Business Week, ClickZ, The Washington Post to name just a few.

First off, serious kudos to the PubMatic team for releasing these numbers. This post is in no way meant to be negative to them, they’ve got a great service and by releasing this index they are upping the bar for everybody else — I wish everybody released a monthly report indicating their view of the market. Note that Rubicon had previously released a less statistical and more narrative Q1 Ad Network Market Report.

What I find somewhat surprising is the level of buzz the PubMatic release generated. Although I’m certain that the statistical quality of their numbers is good I want to point out that there is an inherent sample bias for the Index not only on the publishers selected but also the ad-inventory being analyzed. The publishers are ones that chose to signup for the PubMatic service to help them optimize revenue from Ad Networks. Next, PubMatic’s numbers reflect only the subset of inventory that was sent to PubMatic and the media dollars that inventory made based on the networks that work with PubMatic’s platform.

So even taking these numbers with a grain of salt there are probably enough pubs & networks that something happened in April… so surely it must be time to PANIC because we’re in this massive recession and online advertising is going to dry up and die … right?

Well, I’ll let you in on a little secret. Agencies have quarterly budgets. Each ad-campaign has a certain target revenue that needs to be spent by the end of the quarter, and since most publisher forecasting systems are prone to error there are a large # of campaigns that find that their guaranteed buys have under-delivered and are now nearing the end of the quarter with significant money left to spend. Where do they go? Ad-Networks. Through years at RM we saw the same thing year after year, quarter after quarter. March, June, September and December were always high in revenue, with December being particularly great with some nice “end of year” budgets moving to remnant display. So my guess — what we’re seeing is a normal cyclical trend, where Q1 budgets moved to Ad-Networks in March, disappeared in April and hence PubMatic saw a significant drop in revenue. Of course I could be wrong, but either way the media should certainly stop predicting the impending doom of the online-ad market.

More important than the actual numbers, I think that the reaction to this event shows how desperate we are for insight and visibility into what’s going on. How much money is flowing, and to which parties? What I’d like to see is the Quantcast 100 Advertising Index. Impressions, CPMs & revenue for the aggregate top-100 sites on the Net — now those would be numbers to analyze and report on!

There’s a great post from Christian Kreibich dissecting Adsense’s JavaScript. Near the very bottom there’s a little hidden nugget that I’m not sure Christian quite got the consequence of that I’d like to elaborate on (don’t worry if you don’t understand JS, I’ll explain!):

	    if (specialSites[doc.domain] && doc.domain == “ad.yieldmanager.com”) {
		var d = doc.URL.substring(doc.URL.lastIndexOf(”http”));
		win.google_page_url = d;
		win.google_page_location = doc.location;
		win.google_referrer_url = d;
	    } else {
		win.google_page_url = doc.referrer;
		if (! isTooSmall(win, doc)) {
		    win.google_page_url = doc.location;
		    win.google_last_modified_time = Date.parse(doc.lastModified) / 1000;
		    win.google_referrer_url = doc.referrer;
		}
	    }

Now you don’t need to be technical to get this. That first line basically says this — “If this is coming through ad.yieldmanager.com do something special.” As most of you probably know, ad.yieldmanager.com is the serving domain used by the Right Media Exchange, which of course encompasses a significant chunk of remnant inventory being sold online today. So what Google is doing with this code is something “special” in case the publisher’s referring domain contains the url ‘ad.yieldmanager.com’ — when the publisher is some party on the Right Media Exchange.

The next couple lines do some special manipulation on the referring URL. Now, it’s most likely that Google is simply pulling out the “&u=http://site.com” parameter (the “URL.lastIndexOf()” ) commonly seen in yieldmanager.com tags, which would be the URL of the actual website hosting the ad. Google could then be using this to drive contextual results in case it is wrapped in one too many IFRAMEs and can’t pull out the “document.url” parameter it normally uses. But it bring to light another possibility.

Rather than accuse Google of doing something bad (which they probably aren’t), let’s move this to a hypothetical situation — a network (Network Evil) is buying from a publisher (Pub Good) and wants to extract additional information to build a more detailed behavioral profile of the end user. “Good Pub” knows the age and gender of his users and passes that to his adserver for premium advertisers. This particular publisher doesn’t share this information with ad-networks for privacy reasons and only uses it for direct brand advertisers where he hosts the actual creative.

One of the easiest ways for the publisher to pass information to his adserver is to insert a query string parameter at the end of an ad-call. For example, I could append “&gender=male&age=21″ at the end of my IFRAME ad-call. My adserver could then interpret these values and my media-sales team can then target specific advertisements to men or women of certain ages on my site. The problem with this method is that ‘Network Evil’ could easily sniff this information

All ‘Network Evil’ has to do is log and then harvest data from referring URLs. With a little bit of clever javascript (or server side code) ‘Network Evil’ can dig through the publisher’s referring URL and use the age and gender passed in the querystring to better target his ads and even store this information in his own cookie.

Of course with this simple example there are a number of easy workarounds. First off, any smart publisher won’t pass “&gender=male&age=22″ into the querystring and instead use obfuscated or encrypted parameters. This makes extracting the information much more difficult. But, as I’ve shown before in this post, there are some clever tricks you can do with Javascript already to increase how much data you can retrieve from a partner. Rather than post a list of nasty ideas and get them in peoples heads I’ll leave things to your own imagination.

This brings me to the whole point of this post. It seems these days that everybody is an ad-network. We have vertical networks, publisher networks, behavioral networks, data networks, optimization networks, cpa networks…. each of which when it comes down to is buying and selling online media in some shape or form — often from each other! This is the problem — our partners are our competitors and our competitors are our partners.

The question becomes — how do you monitor and control what your partners/competitors do with the inventory or creatives you give them? How do you stop someone form stealing behavioral data? How do you audit the creative an ad-network shows? Of course you can put contractual obligations in place, but how do you audit those policies? How do you audit your partner’s partners? If one network buys male users from you and then resells them to the another network, how do you control and audit that neither network is storing that data for future use?

To date the answer has generally been two things: rudimentary technology solutions and trust. When it comes down to it, most companies simply trust that their buyers and sellers are going to adhere to the negotiated contract terms. Some may go an additional step and place some rudimentary technology solutions in place to help audit, but honestly true auditing is incredibly difficult and challenging (look at Errorsafe which is still happening!). This is why slip ups continue to happen. Data leaks, adult creatives end up on premium sites and brand ads are shown on spyware apps.

Is this really the way ads are still being traded in 2008?

In my last post I talked about redirects and the limitations they posed for online advertising. In this post I’m going to discuss the various workarounds that people have put in place to address the problem. I’m primarily going to focus on serving speed & the “one-way” challenges of redirects as there isn’t much that can be done to address the fact that redirects are inherently insecure.

Fundamentally when you are talking about “integrating” two different serving systems there are two key driving factors: tracking information and influencing the decision. In most cases tracking information is for either transparency or behavioral information. Influencing the decision is also often related to behavior as it’s close to impossible to transplant data from one cookie domain to another. So let’s look at three little ‘hacks’ that people do to make systems play nice.

Replacing a redirect with a tracking pixels

One of the primary reasons why agencies operate their own adservers is to be able to track the # of impressions that their publishing partners are serving. Yet a much simpler method of counting ads that doesn’t involve an entire redirect is to place an “impression tracking pixel” that the publisher (or network) shows on every ad call.

Let’s compare how an impression-tracking pixel impacts the serving speed compared to a more traditional redirect If both a publisher and an advertiser are using a serving system and are using standard redirects (or ad tags) to integrate, each ad call will result in three consecutive requests:

Call 1, Publisher’s Adserver. The first call obviously goes over to the publisher’s serving system. When the publisher’s adserver chooses an adserver he returns to the page either a 302 redirect or some javascript from the advertiser’s serving system. Effectively redirecting the user.

Call 2, Advertiser’s Adserver. In this call the advertiser receives the request, logs an impression and then spits back some HTML (or javascript) that tells the browser to download the ad, generally from a content delivery network (CDN).

Call 3, Creative Content. In the third call the browser requests the actual GIF/JPG/SWF file from a content delivery network and displays the ad.

If each call takes 250ms the total time to serve this ad will be 750ms as no call can occur until the prior one has fully completed. The browser doesn’t know where which advertiser adserver to request content from until he has fully received the publisher’s redirect and then the actual SWF file can’t be downloaded until the advertiser’s adserver has responded with the appropriate HTML.

When an advertiser passes the actual creative over to the publisher and includes an impression tracking pixel the ad-call sequence changes a bit.

Call 1, Publisher’s Adserver. The first call is still to the publisher’s serving system, except rather than returning the actual ad-tag (or redirect) to the advertiser the publisher’s system returns two things. One a call to the actual creative (SWF/GIF/JPG) hosted on his CDN and then a second pixel call to the advertiser’s impression tracking pixel.

Calls 2&3, Creative & Tracking Pixel. Because the user’s browser received both instructions it can now proceed to download both the creative and the tracking pixel in parallel.

If each call takes 250ms then the total time to serve this ad will be 500ms, 250 for the first publisher call and then another 250 for the creative & tracking pixel in parallel.

Benefits: The biggest benefit of the impression tracking pixel approach is that it decreases the time to serve an individual ad — something that will reduce discrepancies and increase the quality of the end user’s experience.

Drawbacks: Of course there are drawbacks with this approach. Trafficking both a creative and it’s associated impression tracking pixel is more work than a simple ad-tag. It also requires more coordination between the advertiser and the publisher

“Forking” an ad-call with an impression pixel

Impression pixels do not have to solely exist instead of a redirect. In fact, they can also be used to supplement existing ad-calls and let third parties “listen in” on an impression stream without giving them the power to manipulate an ad. For example, let’s say that a network uses the Right Media ‘NMX’ platform for their network adserving but is unhappy with the amount of information that he receives from the reporting systems. Said network’s advertisers demand more information from their media-buys — what can he do?

Obviously one answer is to add a redirect to every ad call — this quickly becomes complicated though as the network will have to host the actual gif & flash files, somewhat defeating the purpose of using a 3rd party network adserver. Also, many publishers won’t accept third party served ads from unknown adservers, posing an additional challenge when trying to buy tier-1 inventory.

Another way to address the issue is to insert a tracking pixel into every creative. On every ad-call the network fires off a pixel to his own tracking server which contains the key information that he is interested in — say — creative ID, publisher ID and referring URL. He can then log this information and provide the advertiser with the detailed reports showing exactly where his ads appeared without having to reinvent an adserver!

Using AJAX to load 3rd party content

AJAX has gained a lot of popularity recently. One way that people can integrate two serving systems is by inserting a small bit of javascript that loads the 3rd party content required to either track information or make a decision directly into the browser. For example, let’s say a network wants to know whether a behavioral data provider has valuable data on a user. If the behavioral partner he receives the impression and if not the publisher sends the impression over to one of his regular networks. He could insert a small bit of javascript that sends a request browser-side and loads the behavioral advertiser’s cookie data from the third party domain.

There are some benefits to this approach — timeouts could be set on the actual request limiting the potential slow-down. Also, since the third party isn’t in the redirect stream he doesn’t get full control over the entire impression. The downside is that the decision is made on the client side. This introduces a whole new set of challenges around tracking & writing cross-browser compatible JS.

All these methods are hacks

You’ve probably realized by now that most of the workarounds involve tricking the browser to load some content from different serving systems. Some schemes that I’ve seen get incredibly complex. I remember a customer who wanted to use Right Media’s serving system as the source of inventory but then inject behavioral information from his own cookie domain. The end result was that impressions came into the RM adserver, were redirected to his adserver and then were immediately redirected back to the RM serving system. That’s three ad-calls before an advertiser had even been selected!

That’s about it for now … Stay tuned for part III….

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

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!