Was reading an interesting post by Seth Godin this morning about bounce rate called Silly Traffic. Google Analytics defines "bounce rate" as "the percentage of single-page visits". Which got me thinking -- what's our bounce rate?

The last time I calculated our bounce rate (before we installed GA), it was pretty good: about 50% of new traffic signed up for Weebly.

Traffic to Weebly.com is made up of about 40% new, 60% returning. Of the new traffic, a significant portion -- a little below 40% -- arrives from search engines.

I was quite surprised to log-in this morning and find out that our bounce rate is 33% for new visitors, and 20% for returning visitors.

On the face of it, this seems to contradict the beginning of Seth's article, that all sites see at least a 75% bounce rate from unfocused traffic, but I haven't had much time to think about why that might be.

What's your bounce rate?

19 Comments
 
 

You've built a cool product. Great! Now, you need to show it off to people. Usually, this is a demo: a quick, 5 minute tour around the product.

Giving a demo is a lot better than trying to explain what your product does in words. It lets people see exactly how things work, and is the fastest way to help them understand your product. There's also an important set of people that will be particularly interested in your demo: investors. When raising money, a good demo to investors can make-or-break the decision process. So how do you give a good demo?

When raising money for Weebly, our demo was pretty simple. We'd spend about an hour ahead of the meeting looking up the investor's website, downloading the pictures and text, and importing the template into Weebly. Then, we'd spend a few minutes to practice creating the site quickly. The end result: we'd recreate an investor's site "from scratch" in front of them in 3-4 minutes. It definitely had the intended "wow" effect.

How do you put together a good demo? Here are a few tips:

- It has to be short. It should take 5 minutes or less in person. An online video should be no more than one and a half minutes long.

- It has to look really, really cool. The demo is a visual tour, and your audience will be concentrating on what they can see. Your goal is to get them to say "Wow!" Fades and animations get annoying in the final product, but they can look really cool for a demo.

- Adapt your demo for the audience. In our case, we would tailor the presentation to the investor we were presenting to. The person you're presenting to should be able to relate perfectly to the need for your product.

- Use real data. Don't ever type in "asdfasdf" for a form field. It's so much easier to understand what an application does when you can simulate a real user. Junk data makes it much more difficult to understand the use cases. Make sure to pre-populate your application with real data that highlights the story you're telling.

- Don't demo all of your features. Just demo the ones that best show off your product and give the maximum "wow" impact.

- Follow one general topic. If you're going to switch themes, make that very, very clear. It's like driving a car: if you want to change directions, you have to stop the car first.

- Have an offline or backup version ready. The worst thing is having to fiddle with the wifi connection for 10 minutes, or something going wrong with your host/colo while you're presenting. You might only have one chance -- make sure to have an EVDO card in case wifi doesn't work, or a local version.

- Show your product in the best light. You can be realistic about the shortcomings later, if/when asked. Make sure to always show off your product, and don't ever purposely demonstrate any shortcoming.

Finally, be confident and excited! You've built something really cool, and you should be conveying that message to the audience. If you're not excited about your product, why should they be?

3 Comments
 
Amazon TextBuyIt 04/02/2008
 

Just read this post on TechCrunch talking about Amazon TextBuyIt. There's 2 things interesting to me about this:

1) Is this product a result of the TextPayMe acquisition?

2) This has some very interesting implications. Amazon can now be located in any storefront, and if it becomes easy enough, it could detract from the value of traditional brick and mortar stores. I could be at Best Buy trying out an MP3 player, decide that I like it (the benefit of physical interaction), text Amazon, and buy it, all from within the Best Buy store. Best Buy paid the cost of the physical interaction (employee, store, inventory costs), but Amazon was able to score the sale.

And the obvious first upgrade: Snap a picture of the ISBN/UPC code with a camera phone and send it via picture message to Amazon.

6 Comments
 
thisismyjam.com 03/27/2008
 

It's always interesting to see new technology for sound. There's a huge opportunity for someone to create software that's better able to understand music the way a DJ might (BPM, key, etc) and automatically create a mix by beatmatching and cycling through the circle of fifths, for example.

thisismyjam.com tries to do that. It's a demo product built on The Echo Nest APIs. It's cool to see something like this on the web, but from my testing, it's about as good as existing software out there that's desktop-based or built into hardware like the Pioneer CMX-3000.

There's no reason why a computer can't eventually do the same thing a human DJ can. In the meantime, here's a quick mix I created with thisismyjam.

4 Comments
 
 

Do you take into account the hidden cost when making decisions? It's one of those areas where I used to fail miserably. I've learned to take it into account over the last couple years, but only recently was able to formulate the concept properly.

The idea goes something like this: Behind most obvious decisions is a non-obvious hidden cost, which can often outweigh the benefit of the "obvious" decision.

I stumbled upon a great real-world example in the drive-through to Taco Bell a few days ago. I realized that there was a flaw in the system: I could order, then drive up to the payment window, and not be able to pay. Taco Bell would likely throw away the food, and have to eat the cost. The system had a flaw. Engineers like fundamentally perfect systems, and that's a good thing.

But if an engineer had designed the drive-through, you would probably have to pay before they started making your food. Impossible to game, flaw destroyed. The problem is, what's the cost of the extra time involved in waiting until you receive payment before you start making the food? And what's the cost per meal wasted times the number of times that the customer is not able to pay? There's a reason they start making your food right away: It saves a ton of time, and people are able to pay most of the time.

Seems obvious, right? Then why do we still insist on requiring two password fields, one for verification? Or two email fields? Sure, a banking application might require this... but your average web app? You could look at it this way: What's the chance that someone will mistype both their email AND password, weighed against the drop-off in signups because of the extra form fields. You will drop a significant number of sign-ups with the added fields, but there will be a very small percentage of people who get both their email and password wrong.

Another pet peeve that PG originally pointed out to us: requiring email confirmation as part of the sign-up process. Email is notoriously unreliable, and often gets flagged as spam or not delivered. Why would you require an email confirmation as part of your sign-up process when there is a high probability that the email will never be received, and the user won't be able to sign-up? Maybe I'm in a computer lab and I get email on my laptop. Tough luck, I can't use the website now, when I want to -- I have to wait until I can check my email. Does that high of a percentage of people not supply their correct email address, that you need to require confirmation? And does having a confirmed email address outweigh the big drop-off in signups?

We've learned to take the hidden cost into account with Weebly. It can apply to across the board: Adding features weighed against the added complexity to your application, bootstrapping weighed against the loss in growth momentum, increased security weighed against the increased difficulty in using the application.

In a nutshell: each decision you make will have a negative counterpart. Even (and especially) the most obvious decisions. Figure out what that hidden cost is, and make sure it doesn't outweigh the original benefit.

7 Comments
 
 

Netvibes, I've loved you since day 1, but you've been getting progressively worse and worse. Please, shake off your aspirations of ruling in the hot buzzword categories -- stop trying to be a social network, that's not why I use you, stop trying to be the end-all-be-all of widget embedding (ditto).

I don't really care about your new releases (Ginger, Coriander, paprika or whatever), I just want to be able to log-in every day and check my news feeds. I don't want to have to go through a painful "migration process" -- sounds like something taken out of an enterprise software book, definitely not suitable for a consumer product. And I don't want to have to request an invite to said migration process, get the email, input the invite into netvibes, begin migration, and have to wait hours until the migration is complete.

What I would like is if you fix your most basic bugs that have been there since day 1, instead of developing world-dominating features. The bugs that relate to your feed reader, the core of your product. Like the bug where when I have a feed open and the feed refreshes since I've had it open, the stories I click on display the story a few places up. Or the bug where about 50% of my feed will start the "Loading..." process, only to go completely blank -- the rest of my feed is ok though! Only half of it goes blank when it tries to load, the other half loads properly. That is especially annoying to me. Or the fact that hitting "refresh" on your feeds is flaky -- I usually have to reload the page if I really want to get a refresh.

I'd be the first to understand that everybody has their bugs. But before embarking on these huge feature releases, can you please fix the small things that have been there since the beginning?

EDIT: check out the comments on this blog post and this blog post -- looks like there are a lot of unhappy people.

2 Comments
 
Skiing in Tahoe 03/13/2008
 
2 Comments
 
 

I first started working on Weebly in February 2006. I worked for about a year on it with Dan and, later, Chris' help, and we launched a (very) early version of Weebly in mid-November 2006. We were TechCrunch'ed a few days later, and accepted into Y Combinator the same day. (On the morning of our YC interview, we woke up to discover we were on TechCrunch).

Weebly has been growing ever since then, gone through two complete visual redesigns, added numerous features, and doesn't even resemble the product we launched with at all.

Here's two of our graphs from May 8th 2007 -- five months after we moved out to San Francisco and had been working on the product full-time:

The first is a graph of our new signups per day, and the second is a graph of our total user count per day. I've annotated the top graph with what events caused the major spikes.

There's actually two very interesting things to note about the top graph: First, we had already closed our angel round at this point -- looking back, our investors placed a huge amount of confidence in us.

Second, the new users per day looks like it might actually be declining a little bit.

At this point, I'd been working on Weebly for about a year and a half, and we'd been launched for over six months. Judging by the graphs, you might think things weren't looking spectacular. This is the type of situation when people give up.

I've seen it quite a bit among startups -- they spend more time developing the product than they do running it after they launch it. Several have followed the same pattern: build, build, build, launch, quit.

But you've got to keep with it to gain momentum. It doesn't usually just build overnight, it takes time. Keep building your product, and eventually you gain momentum and a critical mass of people who know about you and tell others about you.

Now, here are the graphs from a couple weeks ago:

These graphs look a hell of a lot better. There's 2 things I'd like to point out:

- First, the "build it and they will come" mentality is a fallacy. You need to build something great and have distribution in order to succeed. And distribution is hard to get.

There are many ways to get distribution. One of those is through press. If you have a great product, the more people that find out about you, the more people will know about you. And they'll tell their friends, who'll tell their friends, etc.

Another subtle press benefit: you're getting links from a bunch of very highly-regarded sites, and this helps out your rankings in search engines quite a bit, which builds more traffic.

There are plenty of other good ways to get traffic too, such as engineering for viral growth, but press can have huge benefits for the right product.

- Second, in order to get people to use your product, you have to stay alive. This sounds obvious, but a ton of people spend 6 months building a product, launch it, and give up within 3 weeks.

Plain and simple, it's going to take time for people to start using your product -- there are exceptions, but it's generally not the norm. So you need to expect that, and be willing to give it time. If you give up within a month or two, your product definitely won't be successful.

Once you launch, people start to know about you. If you launch early, you can start earlier on the process of acquiring users. Don't launch with a crappy product -- launch as soon as what you have is better than what is out there. But don't wait for a perfect product -- launch as early as you can, get user feedback, and keep improving the product.

28 Comments
 
 

How do you get press to write about your new startup, your new product or your feature launch? Here are ten tips to attracting press attention and dealing with the conversations that follow.

The most important of them all (unless you're trying to get launch press): Be launched. We have spent $0 on press for Weebly, but we've gotten some big mentions (Newsweek, Time, NBC, BBC). Half of the battle is having a product that people can write about -- if you're not launched, people won't know you're there. If you aren't launched and people are still trying to write about you, although it feels good to be exclusive, you're missing out on an opportunity that might not come again.

Here are ten guidelines on how to make your story interesting for the tech blogs/press and successful in general:

1) Make your story worth writing about. First, make sure you have an angle that is really exciting. If you need to, tailor your message into something that fits with an industry trend. Make sure you have a jaw-dropping demo and a clear value proposition. Basically, make sure your startup is legitimately newsworthy.

2) Launch your news on a Tuesday, Wednesday or Thursday. There's too much news coming out on Monday, so don't try to compete with that. But make sure not to launch on the weekend, because there's so much less web traffic on the weekend than on the weekdays. Tuesday or Wed is generally the largest blog traffic day, so those are preferable.

3) Put together a short list of bloggers that are appropriate for your product. Put in some time to research this. Don't include bloggers that wouldn't normally write about your story. Add three types of bloggers to this list, in equal proportion: The large blogs, that you'd love to get coverage from, the medium blogs, that might cover you, and the small blogs, that will probably cover you because nobody really approaches them for a story. It's like applying for college: no matter what, you should at least get accepted somewhere.

Even if you don't get on the large or medium blogs, the medium bloggers generally read smaller blogs, and will pick up good stories they find there. Likewise, the larger bloggers read a certain amount of medium blogs, and the story can bubble up if it is newsworthy.

4) Contact the people on your list a week or two before the launch. Make your email very personable, from the founders, but straight and to the point (their time is valuable). Your goal is to meet with the blogger in person. If that's not possible, you want to talk to them on the phone. If that's not possible, as a last resort, let them have an online demo of your product. Why? An idea and mission is much more convincing when delivered in person or over the phone by a passionate founder. You'll also have adequate chance to rebut any of their arguments against it, and you're much less likely to wake up to an article that completely missed the point of the company, or where the reporter ran into some bug in your system.

If you're just starting, though, and don't have any connections to get de-facto attention, you'll want to make it as easy as possible for the blogger to try out your software: this means you should have a direct link that requires no log-in or sign-up with pre-populated data that the blogger is able to play around with in 5 minutes or less.

5) Set a clear embargo date. We've found that sometime in the morning works best for blogs, like 10am PST. What is an embargo? It's a time after which the press is allowed to write about a story, but they're forbidden to write before then. Why set an embargo? If you don't set one, you'll end up with the grave shift post on Friday at 11pm, where no one will see it. The goal is to keep your post on the front page as long as possible.

Embargoes are actually a solution that works well for bloggers (even though some love to hate on it). Nobody likes to write about a story that is old news -- and old news can mean just a few hours old. You need to set an embargo to co-ordinate all of the major blogs, so that nobody scoops anybody else, and they all post about you (instead of just one). The way that Techmeme works, they all get to ride on the coattails of the story this way, too.

Don't feel the need to volunteer an exclusive -- if your story is newsworthy, everybody will write about it. Either way, you're much better off with coverage from 4 blogs than coverage from just one. Your goal is to pop up in every feed people read: then they can't miss your story.

6) Make yourself available. Before the launch, make yourself as available as possible. Give out your cell phone number, and always answer it -- even late at night or early in the morning. You might not get another chance to catch up with this particular blogger/reporter.

7) Make sure your product is ready. It's difficult to tell when a product is ready, but now that you're going to be receiving all of this press attention, make sure it's ready for the load. It's very likely that if your product isn't up to par, you won't get a second chance for coverage or attention. Not to say that you shouldn't launch early and often (you should), but as Paul Buchheit says, "launch your product if it's better than anything else out there."

8) Sit back, relax, and enjoy the attention. Congratulations! A large portion of the tech world's attention is focused on your startup. Expect to get emails from ridiculous people, and a few thousand sign-ups.

9) Don't panic when the attention dies. It's always tempting to fantasize that the traffic spike will stay. Except for in rare circumstances, traffic will die down and form a spike. That's ok -- you should at least have more people/day signing up than you did before the attention.

10) Cultivate relationships for next time. This is good life advice in general. If you meet with press people, work on cultivating a relationship at the personal level. A good friend doesn't only talk to you when they need something, and treats you like a normal person. I'm not advocating being fake with people, but showing a minimum level interest in them personally, sending emails when they change jobs, saying "Hi" when you bump into them at social events, etc, goes a long way. At best, you might become really good friends with them.

13 Comments
 
mod_auth_cookie 02/20/2008
 

The pages hosting this Apache module seem to have gone dark, but I managed to grab a copy through archive.org. It's a very easy way to get rid of the ugly Basic Authentication prompt and replace it with a web page login form.

I created a new home for the module at http://modauthcookie.weebly.com/.

Hopefully, other people will find it useful too.