One of the fundamental principles that we operate on with siteMighty is having data at our fingertips so that we know what is going on at all times. We do this by 1) setting metrics, 2) gathering data, and 3) presenting it in an actionable way.

I have staked the growth of siteMighty to analytics: we have to know how we are doing and act accordingly. One of my failings with Huckabuck is that we built a great web-app but never had any idea how or if people were using it. In the end, the most concrete data we had were the $2 checks that rolled in from our advertising rev-share.

I got serious about this at SXSW in March. siteMighty was ready for beta launch, and functionally it was ready, but we already knew that we didn’t have data tracking and analysis tools that would enable us to stay on top of siteMighty. And as I’ve said before, getting to launch is like pulling up to the starting line, the race hasn’t even started yet, so I knew we needed tools to understand siteMighty. Ryan Carson blogged about his meeting with Ryan Allis the 22 year old CEO of a multi million dollar company. Ryan wrote:

What really struck me though, was how he knew his numbers inside and out. He is absolutely hard-core about measuring everything. It was like a slap in the face - as CEO of Carson Systems, I just don’t know enough about what’s going on.

It is critical to know what is going on. So, here’s what we are doing about it:

I designed an analytics dashboard that is mocked up over the the right there. Here are the important things we wanted to track:

• Open support tickets
• The Visitors / Conversion / Paying Users funnel (more on that below)
• Server bandwidth usage and capacity(so we’re prepped for a TechCrunching)
• Aggregate stats on our users sites so we know if they are seeing success
• Revenue stats

Our conversion funnel was designed to really understand how many people we have to get to visit siteMighty in order to actually make a paying customer out of people. I got a lot of insight into doing this from Mike McDermont from Freshbooks. I basically built our funnel around the ideas he presented here on Vitamin. I lifted his conversion funnel for our mockup. (Thanks Mike!)

So, after three iterations of our analytics dashboard here we are. Our current version is over to the right.

This has be instrumental in helping us understand what is going on with siteMighty, react to the needs of users, and evaluate the success of our marketing efforts. We keep this screen up all day for a live look at what is going on.

We’d love to hear your thoughts on any successes with analytics or challenges with not having the data you need. I’d be happy to provide insight into what we are tracking and why, and please feel free to use anything you can learn from our analytics package on your web app.

• Related caveat: I just ordered the new book Competing on Analytics: The New Science of Winning which has been highly recommended. Check it out.
  

I am a firm believer that the future of software is internet-based web applications. We will continue to move from software you buy and install on your computer to software that you rent and run over the internet. Vinny Lingham had a great post this week about the top 20 reasons web apps are better than desktop apps. Now, this is the shared vision for the future of software for many of us, and while the early adopters are moving online, we are still waiting for the masses to begin their migration towards web apps.

Back in microeconomics we studied switching costs, which loosely defined means the cost that a consumer incurs when switching from one supplier to another. The calculation of the switching cost to the consumer to move from desktop software to web applications is more complex than just the different pricing models of the two. In almost all cases, web applications are far cheaper than desktop applications, if not free. However, it is important to understand that price is not the only switching cost incurred by consumers.

Mitigating Consumer Switching Costs Incurred in Moving from Desktop to Web Applications

1. Pricing & Ownership - One of the first things people have to get familiar with is the idea of not owning the software they use. They no longer buy software, they rent it. If they stop paying, they no longer have access to it. This is inherent in shifting the idea of software from a product to a service. Shifting the consumer’s mindset is a key to success, but it is also important to realize that there is a cost to the consumer to move from desktop apps to web apps.
2. Free & Trial Subscriptions - Make it easy and free for your consumer to try out your software. Build a freemium business model. Make it just as easy to cancel as it is to upgrade. Keep in mind that your customer is not just trying out your software, but the idea of software as a service. Make it as easy and painless as possible. Which leads me to:
3. Painless Migration - Build open and compatible software. If you are building software that is about to disrupt the a certain segment of the desktop software industry, make sure you are compatible with it. Make it painless for people to upload their files to your web application. People are willing to try a new piece of software online, but there has to be a continuity with the way they’ve been working until now.

When We Feel a Switching Cost

In our office we are holding off on upgrades to the Microsoft Office 2007 in an attempt to continue to migrate our software usage online. We’re using Google Docs for our spreadsheets and word processing, and continue to use Basecamp. Next up is photo editing and graphic software. At each step we incur switching costs that reveal themselves in different ways:

• “Hey, how do you do this on here…” - learning curve
• “You mean this feature isn’t available?” - missing (or different) features
• “*&#$%… my browser crashed.” - the browser bugaboo

With each of these, we learn a little more about what switching costs really mean. Our goal is to make the transition to our web application as easy as possible and to minimize the switching cost to the consumer of moving to web apps.