Posts tagged ‘metrics’

The bell

Jeff Bezos loves to tell the story of the bell that rang in the Amazon office every time they made a sale.  Of course, after a while it began ringing so often that they had to turn it off.  The important thing was that the bell served as a constant reminder to the entire team of what they were trying to accomplish.  The bell unified the team behind one goal and gave them an obvious way of knowing how they were doing.

I was late to the party in understanding the power of the bell.  I’ve since been eager to catch up and install some modern-day bells for EventVue.

Earlier this year we started sending out nightly metrics emails to everyone in our company along with some of our close mentors and investors.  This email includes key metrics like how many people signed in that day, how many people used Discover, how many people shared with friends, etc.  Recently we took it one step further and started publishing real-time updates into the Socialcast community that our company uses for internal communication.  We publish stories as people use our products and reach meaningful milestones like inviting their friends to join them at an event.

The result is quite powerful.  It helps us really feel what’s happening in addition to seeing the cold, hard numbers each night.

Of course, there are a lot of different ways you could accomplish the same goal, but building on top of the Socialcast API has given us a few unique benefits:

  • Our bell can be heard anywhere we have an internet connection.
  • We don’t have to change our behavior.  We’re already using Socialcast every day.
  • Everyone has their own volume control.  The stream can get noisy, but Socialcast makes it easy to filter.
  • We can search, filter and catch up later if we miss anything.

If you haven’t installed a bell in your office yet, why not give it a shot?  You’ll find yourself encouraged by some things and discouraged by others.  One thing is for sure:  you’ll learn more about your users as a result.  And at the end of the day, that’s what it’s all about


Will anyone really use EventVue?

Last week EventVue launched an exclusive beta version of our product for the Community Next conference. Since then we’ve seen dozens of attendees sign in, create profiles and send messages to each other via our community.

We’ve been watching the usage statistics like hawks. These numbers are important to us, since they are an indicator of how much people value our product. We can get a good idea of how much benefit people are receiving from EventVue by the amount of time they spend on our site and how often they come back.

Since launching the community for Community Next:

  • EventVue users have racked up over 4,500 pageviews
  • the average EventVue user stays for 8.5 minutes
  • the average EventVue user views 14 pages per visit
  • 31% of EventVue users have returned 3 or more times
  • 19% of EventVue users have returned 9 or more times

To put those numbers into perspective, that’s a total of over 47 hours that have been invested by the Community Next attendees to prepare themselves for the conference!

We no longer need to wonder if anyone will use EventVue – they already are!


Image storage: Database or File system?

From my experience, storing images in a database is a lot easier to manage than storing them in the file system. Here are a few of the benefits that I love the most:

  • Related information is automatically kept in sync.
  • It’s easier to backup your data when it’s all in one place.
  • It’s easier to maintain an independent development environment.
  • You can add additional file servers without having to deal with on-the-fly file replication.

Of course, the classic argument against storing images in a database is that it is slow. Retrieving images from a database takes longer than retrieving an image from the file system. At least, that’s what they say.

I decided to do a benchmark test for myself to see just how much of a difference it makes in performance. The results were surprising.

First, I created three different sized thumbnails of this picture and stored them in a directory on my file system. Then I took the same three images and stored them in a mySQL database. I then measured the total time for Firefox to display each image. I ran each benchmark 10 times for better accuracy.

Here are the results:

File system

  • Large – average of 7.87E-05 seconds
  • Medium – average of 7.77E-05 seconds
  • Small – average of 6.65E-05 seconds


  • Large – average of 6.68E-05 seconds
  • Medium – average of 6.69E-05 seconds
  • Small – average of 5.90E-05 seconds

Wow! The images retrieved from the database were actually displayed faster than those retrieved from the file system!

Of course, we still haven’t proved this is scalable. I only had 3 rows in my table. What would happen if you have 120,000 images in your database? There’s one way to find out. Test it.

I inserted my picture into the database table 120,000 times (yes, that took a while). When I ran my benchmark test again, the average time was 6.07E-05 seconds! So much for being “slow”.

I’m not sure what would happen if my table contained over 120,000 images. For now I’m not too concerned – we’re still a few weeks away from reaching that milestone.


Platypus update

This is what happens when Facebook adds your application to their directory:

Here is a quick summary of the other numbers from the Platypus experiment:

  • 416 people have looked at it
  • 227 people have installed it
  • 158 people are currently using it
  • 69 people (30%) installed it and then removed it again

The biggest surprise to me with these numbers is the low retention rate. Why am I loosing 30% of the people who install my application? Has anyone else noticed this trend with their Facebook applications?