I’m having some great fun this morning playing around with Google’s index from January 2001 (made available to celebrate Google’s 10th birthday). Results also link through to the Internet Archive so you can see what those sites looked like at around the same time.

Some fun queries:

• site:wikipedia.com (they hadn’t moved to their .org home at that stage)
  
• “upload videos” compared to today’s results
• “subprime mortgage” risk. How funny.
• “social network” points to academic work in Sociology

I could do this for hours!

Let me know if you come across any interesting results.

As you can tell from the entirely un-sexy title, this is one for the analytics nerds.

Google Insights provides the interesting capability of viewing the relative search volume of keywords mapped to a geography. So for instance, Andrew Chen has used the tool to identify websites used by early adopters. This is handy both directly for web strategy, as well as indirectly as a proxy for spread of usage.

One feature that’s missing though is a quantitative measure of spread. I want to know, for instance, the degree of usage of TechCrunch relative to the NYT. Or of my new startup compared to established competitors. Or of a US brand compared to a competing European brand. And I want it in numbers.

For this, you need to take the CSV dump from Google Insights and take the standard deviation of the values for the “top regions for [keyword]” with some adjustments due to the dorky way that Google gives you data.

Or if you don’t want to do that, you could just plug your CSV files into the geographic spread calculator that I threw together this morning.

Here are some fun queries I prepared earlier:

• Obama vs McCain internationally
• Obama vs McCain in the US
• Top social networks
• Australian print newspapers
• “Olympic swimming” vs “South Ossetia”

Have fun, and let me know if you come up with anything interesting!

Google’s Android project is in serious trouble. They’re taking too long to iterate the SDK, and aren’t providing developers with enough information about its progress. At the same time, developers on the rival iPhone platform are enjoy stellar success.

Needless to say, Android developers are not happy, and are readier than ever to jump ship. Google’s not doing much to prevent this - the only Google voice in the discussion was that of Jean-Baptiste Queru, an engineer, who also remarked that he would “get into trouble for posting“.

As a further insult, developers recently discovered that an elite few have been secretly receiving updated versions of the Android SDK. This is not a good message to be sending the development community, particularly when an attractive characteristic of the platform is openness.

Android’s success or failure will largely be determined by the degree to which the platform is embraced by developers. So surely, Google would see Android developer relations as a key priority. But rather than embracing the community, Google has antagonised it.

So why is it so difficult for Google to be on top of developer relations? Why is there no obvious liaison - somebody who has the requisite technical knowledge, a ubiquitous presence, authority to answer developers’ questions, and a desire to expeditiously resolve conflicts? Why is there no individual whose sole responsibility is to complete the communication loop?

My intuitive response is that there’s a paradigmatic reluctance among the Android team to view third-party developers as partners and assets. Perhaps this is due to the pressure of working hard on a much anticipated product, resulting in myopia. Or perhaps it’s due to Google’s cultural of producing fantastic products in a self-reliant manner, engendering mistrust or undervaluation of third party developers.

Whatever the reason, there is no excuse. Amicable developer relations are vital for the project, and not should not be difficult to maintain.

Ray Grieselhuber has some interesting thoughts on how Google has trained us all to think like marketers.

The crux of his post:

Google (and others, of course) have successfully trained an entire generation of technologists to think like marketers and that might not be a good thing… Primarily, [the problem] is this: hackers these days have a tendency to view their applications as marketing channels, best or most easily monetized by some sort of advertising / affiliate reward / product upsell.

I don’t think we can chastise Google for this - they never intended to create the new wave of marketing, and do generally remain focused on delivering the best possible product to their users. However, the astounding success of many advertising-powered startups naturally encourages chinese math amongst young hackers, possibly distracting them from great products that they could be making for a smaller number of users.

I don’t think Ray should be concerned that seasoned entrepreneurs could become corrupted - they tend to be product-focused, and ultimately determine an appropriate avenue for monetization. But younger entrepreneurs and hackers may be better served by building products that are worth paying for.

It might not sound appealing to serve x customers rather than 1000x users, but there’s no greater vindication of your concept than having people pay you for it.

The answer is close to $11 million. Let me explain…

Mozilla makes almost all of its money from Google (or more precisely, from search-related royalties). Basically, search engines (mostly Google) pay Mozilla a small royalty every time a user uses the search bar in the right-hand corner.

How much? In 2006, search royalties constituted $61.5 million of $66.8 million total revenue (from the 2006 Audited Financial Statement). Given that this is a 20% increase from the previous year, and considering the increasing percentage growth of Firefox adoption, it would not be unreasonable to project that figure to more than $75 million for this year.

That’s an enormous amount of revenue to come from one small element of Firefox’s functionality (as a percentage of total revenue). So you would expect it to be in Mozilla’s best interests to encourage everyone to use the search bar, right?

Well, the location bar that ships with Firefox 3 (the one that you type URLs into) is predictive - start typing terms which appear in the URL or title of a page you’ve visited before, and hey presto, Firefox finds the page for you. Great for users, but as we will see, perhaps not so good for Mozilla’s bottom line.

When you remember that a large fraction of search volume is for terms that would appear in the title or URL of a previously visited site, the source of the loss becomes apparent - as users start seeing better and faster results from the location bar than they do from the search bar, there will be a natural shift, and Mozilla’s search royalties diminish.

So if we now approximate the volume of search terms that would appear in the title or URL of a site likely to have been previously visited (let’s call them ’simple’ terms) as a proportion of all search volume, we can make a reasoned guess as to the amount of loss.

Unfortunately, this is a difficult calculation to make. We could look at the Zeitgeist or spend a few days on Trends, to notice that around 90% of all top search terms are simple terms (almost always the name of the site - myspace, bebo, wikipedia etc. or the name of a celebrity). However this is only the head attached to a very long tail so would make a poor source of data to extrapolate from. We could look at my own search history, of which 5% of terms are simple, but this would be an under-representation for two reasons: since as a sophisticated searcher I generally use longer queries with operators, and since simple terms would be used more often than non-simple terms but only appear once each in my search history.

With a frustrating lack of appropriate, accessible data, I had to make the compromise of aggregating the search histories of a few non-geek friends and asking questions as to the frequency of the simple search terms that I saw. My tentative conclusion was that 15% of all search volume was for simple terms (with an embarrassingly large margin of error). This tends to accord with my own search history and Google Trends observations, but remains only approximate - so if you can make a better guestimation, please let me know.

Applying this to our revenue projection, we could now say that the location bar functionality will cost Mozilla approximately $11 million per year.

The problems with this guess are that I used a very small survey sample of largely homogeneous users in a single language. Also, Firefox users would tend to use fewer simple terms than non-Firefox users, so that would require another adjustment. But it’s a reasonable guess for our purposes.

I should make it clear that this is only an opportunity cost. Clearly the increase in adoption rates with Firefox 3 will more than compensate for the drop in per-person search royalty revenue, rendering the software more profitable than previous iterations. However, I make this point to illustrate that Mozilla is forgoing a significant amount of revenue by opting to include this element of functionality.

While the number is large, ultimately I think this is a far-sighted, well-reasoned decision. The fact that Mozilla is willing to incur this degree of opportunity cost proves how highly they prioritise user experience.