Note: This is cross-posted on the Ghostery News site. Please go there to read the entire post.

This is the first in a series of posts coming this week on the Top Web Bug Trackers we saw at Ghostery last month.

What surprised me:

1. Google’s utter domination of the Top 10 list (Google Analytics, Google Adsense, Doubleclick and Google Custom Search).
2. Google Analytics coverage is massive and growing quickly. I instinctively knew this but its breadth and velocity even surprised me.
3. Two sleepers: Statcounter and AddThis. Their penetration rates eclipsing many well-known services, including some very large ad networks.
4. Free: 8 of the trackers are “free” or have “free” versions. With only Doubleclick and Omniture being paid “enterprise” services.
5. Open-source inside: OpenAds and Wordpress Stats are based on, or are, open source projects.

Read the rest at Ghostery – Top 10 Web Bug Trackers on the Web

The common theme that runs through every startup that I’ve started, or been a part of, is the need for “big data” analysis. “Big data” analysis is the area where off-the-shelf software tools breakdown, where statisticians, analysts and developers meet and where normal number-crunching turns into “supercrunching“.

At my last two startups, Compete and Lookery, this “big data” analysis has transcended its usual internal audience and become a fundamental part of, if not the entire product.

In the time before Lookery (B.L.) we needed to create our “big data” infrastructure from scratch. This usually took the form of large clusters of computers running proprietary, created from scratch, software. The most formal of these being the software we created at Compete which included the Compete Filesystem (CFS) and CompeteSQL (CSQL).

Today we have open-source software like Hadoop to provide the framework for our data analysis software at Lookery. The Hadoop project has grown fast with companies like Yahoo, Facebook, Last.FM, and The New York Times using it. There are even venture-backed startups focused solely on building services and products on top of the framework.

This weekend Elias Torres, our VP of Engineering at Lookery, released a project he calls Hadoop Timelines. Hadoop Timelines is a great example of what I’m calling “Hadoop Performance Optimization” (HPO).

While the barriers to use something like Hadoop have fundamentally dropped there are only a handful of experts that can make your Hadoop cluster perform well. What’s needed is a new suite of services and tools that can analyze your cluster and automatically optimize your performance. Hadoop Timelines, while rudimentary, is the beginning of an exciting new business niche, Hadoop Performance Optimization (HPO).

If you’re a Hadoop user please comment on how you’re optimizing your performance today.

This graph shows what the greybeard VCs and angels have known for a while. If your company has VC investors, they will reduce the probabilities of an exit that would produce a 1-5x return for the angels. That exit might have produced a 100x return for the entrepreneurs because they paid much less than the angels for their shares.

Having VC investors does increase the probabilities of exits above a 5x return.

But there is no free lunch. This data shows that after a VC invests your chances of failing completely also increase significantly.

via Exits with VC and Angel Investors – The Wiltbank Data.

David says: The news is that this isn’t news. Venture investors are almost always transparent on what it means to take their money. They have no choice anymore as all this information is freely available to anyone who wants it although I believe they are transparent because it makes good business sense first and foremost.

The reason I’m reblogging this post, from the excellent AngelBlog site, is that “we” startup people are either blind eye optimists, blinded by our ideas, ignorant, or all three. “We” commit the same (fatal?) mistakes over and over despite, usually, knowing better.

My gift to you (and me) today is to hit you over the head with this one more time. Hopefully it’ll only take a few more loving strikes with this 2×4 before “we” all finally get it.

(Note the emphasis on the above quote is mine)

Listening to the Dave Ramsey podcast today when I heard this gem:

“In business about 90% of your ideas suck and about 10% of them actually work. And we never know which is which. So you have to survive your bad ideas and when you borrow money to do them you magnify the size of the mistake.

Version 1.0 seldom even makes it to market and version 2.0 doesn’t make you money it loses money. 3.0 starts to work. About 7.0 is the sweet spot by the time you polish this rock a little bit it will shine but the first time your throw it out there it’s a piece of coal.

…Business is a process, you cannot analyze it. – Dave Ramsey

I was reading Jeff Ready’s McStartup blog today and his explanation of “Product Development” jumped out at me.

At Compete and now Lookery, Product Development was the key difference between good products and mediocre ones. The greater the distance between clients and developers the worse the product became. At Lookery, Elias, our head of engineering, is putting the rest of us to shame, juggling sales calls, support, and coding simultaneously.

I’ve never taken Product Development as far as Jeff has (elimnating “engineering”) but the next time I start a company I plan to do so. Jeff’s definition of Product Development below (emphasis mine):

In my companies, we go so far as to merge two functions that are often separated in other organizations: engineering and product marketing. It is my opinion that these should be one in the same. The folks that are building the product are the folks that need to be out in front of customers, finding out what that product should be. They are also the same folks that should be telling those customers how they can use the products they’ve built better or in different ways. We call the combined entity “product development” and it is their job to build products people will buy. They get full responsibility, so there is no blame game between product marketing (”the engineers built a product that sucks!”) and engineering (”marketing got the requirements all wrong!”). This one department is responsible for the whole enchilada, no questions asked.

A lot of technology companies delegate the responsibility for coming up with product requirements to “marketing” who then talks to customers (maybe) and analysts (probably) and copies what the competition does (unfortunately and almost certainly), and then hands a list of requirements to engineering, who inevitably further misinterprets the requirements on their way to creating a product that at best is marginally passable and at worst is so far of the mark that no one will buy it. What an unnecessary chain of misinformation and complexity. The people who design the product should be out there talking to people who want to buy it, and should build what they will buy.

via Market research for startups – McStartup Blog – McStartup – tasty advice for startup companies.