On May 4, three months after Preceden’s launch, I started charging for it. Preceden, for those of you who are unfamiliar with it, is a web app for making timelines.

Not completely charging for it though; I’m employing a freemium business model, which basically means I give it away for free and charge the folks who want a premium version of the product. In Preceden’s case, users can add a limited number of events to their timelines (20) but if they want to add more than that, they need to upgrade for a one-time payment of $29.

I haven’t followed the numbers too closely, so I decided to spend this weekend figuring out just how well the site was converting visitors into paying customers.

Here’s the result:

There’s good news and bad news.

The good news (great news!)  is that 5 people upgraded, for a total of $145.

The bad news is that only 5 people out of 316 upgraded (1.62%). Actually, I have no idea if this is good or bad. It seems bad. Regardless, I’d like it to be higher.

Until several days ago, the homepage didn’t have a “Pricing” section. I did mention the price in the FAQs, but I think a lot of people signed up without realizing that you were limited until you upgraded. A preliminary analysis of the new numbers shows that adding the “Pricing” section cuts the visitor to sign up conversion rate in half (12% to 6%). However, there should also eventually be a corresponding spike in the paid conversion rate, because everyone who signs up now should understand the limitations of a free account.

To complicate things, I also just changed it from a max of 10 events per free account to 20 events per free account. This is a tricky number because too low and users won’t add enough events to appreciate the product but too high and no one will need to upgrade. I thought 10 was too low, so I up’d it to 20. I don’t know yet how this will affect the conversion rate, and it’s going to be hard to tell whether that or something else affected it if it does change significantly.

I’ve also considered limiting free accounts in some other way (no printing?) but haven’t decided on anything yet. Another option is to lower the price from $29 to $19 but this is also complicated (what happens when the folks who paid $29 realize you just lowered it to $19?).

AdWords has been a flop so far. At $5/day, I spent $60 on it over this time period without any conversions to paid users. However, with such a small conversion rate (1.62% so far), the lack of upgrades could just be due to variance, so I’m going to keep at it a while longer.

Now that I’ve got a good system in place for measuring the affects of advertising, I’m going to experiment with some other ad programs and see how they measure up. I’ll make a follow up post in a few weeks showing my progress.

If you have any feedback, especially ideas on ways to improve the conversion rate, please let me know.

Matt

I received an email a few days ago from a customer:

I’m loving your tool and using it to build a pretty extensive timeline for a project I’m working on. However, it seems to have stopped loading.

After a bit of troubleshooting, I realized that he had added so many events (217) that it took upwards of 30 seconds to load the page, causing Heroku to throw an error.

I decided to spend today seeing what I could do to speed things up a bit.

To do this, I created a timeline on my local machine and used the Rails console to add 50 events to it. I loaded it a few times and checked the server logs, which indicated that it took about 15 seconds to load on average. Eesh.

I set out to time all the major sections of code to see if I could determine what was taking the most time. I did this by creating a two methods on my Timeline class: initialize_ticker and tick:

attr_accessor :start_tick

def initialize_ticker
  self.start_tick = DateTime.now.to_f
end

def tick(str)
  diff = (DateTime.now.to_f - start_tick) * 1000
  puts 'Tick %sms - %s' % [diff.to_i, str]
end

I called initialize_ticker at the top of the show method in the timeline controller and then added tick method calls to the top of every significant section of code. This let me narrow down where the slow code was. When I determined that something was slow, I added a few more tick method calls within the method to narrow it down even further. Once I had the block of code that was causing trouble, I tried to identify ways to improve it.

One of my major finding was that converting a DateTime object to a float (like in the code above) takes a nontrivial amount of processing time on the backend. Since Preceden’s code was doing this thousands of times whenever a timeline was loaded, it added a lot of time to each page view. Where I could, I started returning floats rather than DateTime objects so it wouldn’t have to be converted later on.

I made a lot of other changes too, but they’d be hard to explain without the context of the code.

tl;dr: I was able to get that 15 second page load down to about 700ms, an improvement of about 20x.

You notice it even more on timelines without a lot of events because what would take several seconds, is now almost instantaneous.

Not bad for a few hours of work.

What I’m working on this weekend, among quite a few other things:

Before:

After:

Also of note is that I’m starting to charge for Preceden.

In the past, users could create an unlimited number of events on all of their timelines. Now, you can add up to 10 and after that you’ll need to upgrade for $29.

This decision, which I debated for weeks, will ultimately be a good one, I think. User count is great and all, but without revenue, you’re very limited. Sure, a lot of startups do it and it might make sense for them, but at this point in my pursuit, it makes more sense to focus on profits than acquiring a large user base (both would be good though!).

It changes things a lot and it will be interesting to see what happens.