One of the hardest things to decide on when releasing a trial edition of your software is the registration incentive, or in other words, the limitation of this trial edition.
But it is also a decision that may have a big impact on your downloads to sales conversion rate. So let’s look at it more closely.

First, here’s my thoughts of what a trial edition is and what it is for.
A trial edition is:

• A marketing tool, designed to convert website visitors into customers.
• An evaluation version, a way for prospects to try your software before they buy.
• Not free software.

So, how does this impact the design of your trial edition?

• Make it absolutely clear that it is “just” a trial edition. Remind the user as often as possible. Don’t nag him, don’t annoy him, just make him aware. For example, have a Buy Now button on the toolbar, a reminder at start up and/or when the app closes.
• A trial edition should be limited or at least crippled in some way. Remember it is not free software, it is only meant for evaluation purposes. Preferably, it should not be of any practical use.
  Releasing a fully functional version with just a nag screen may have worked for WinZip, but in general, this is not the best way to make money. At least not anymore… Even WinZip saw the light…
• Make your trial user run into this limitation quickly, if possible during the first hours of usage, that’s when he’s most likely to buy (the impulse purchase). And again, just a nag screen doesn’t count.
• If possible, make sure trial users can evaluate all features of your product, that is, all features that the full edition has. If you have to exclude features from the trial edition, it must be absolutely clear what the missing features are, what they will get EXTRA when they buy the full edition. Yes, it sounds like this contradicts the earlier points, but it doesn’t have to.
• Try to create a “lock-in” situation. Give them enough time to make them feel that they have invested time in your software, too much to switch to a competitor. Or allow them to create enough files or enter enough data to make them regret not being able to access them when the trial expires. Or, get them hooked. Indeed, this may conflict with the “quick limitation” point.

Now let’s look at some common ways to do trial editions:

30-day trial

Now, surprisingly, the most common trial limitation is the 30-day trial.
Why am I surprised? Because it does not encourage impulse purchases at all. It allows full usage of the software for 30 days, during which the user may loose interest, find an alternative.

Or even worse: he may have accomplished what he needed to do, he used your trial edition as free software. Ouch…
An example is the excellent Microangelo Icon Editor. It has a 21-day trial and during that trial period lets you create (and save!) icons at will. Now, I am a developer and indeed have a need to create icons for my programs. But how often do I need to do that? For me, that can’t be more than once a year. So whenever I need to create icons, I download the latest trial edition of Microangelo, do my thing and then forget about it. I never get to the point of buying it. I know, my bad… but hey, they let me do what I needed to do with their trial edition. For my purposes, their trial edition is free software.

The only benefit of this method is that it may result in a “lock-in”, depending on the type of program. For a game or a time-saving utility, you may have your user hooked. For a productivity tool, the user may have created lots of files that he cannot open without your software.

Limited Number of Uses

This is a bit better. It at least makes the user run into the trial expiration sooner if he uses the software more often. But still, if your program is not something that people use on a daily basis, you are missing out on the impulse buy.

One-hour trial

Sounds brutal, but works well for some types of games. One hour is long enough to get hooked, but too short to get bored 🙂
A good way to push impulse purchases. We use this for our Canasta card game.

Crippled output

For instance, watermarks in printed output or in created image files, or a little “created with the trial edition of… ” footer in generated reports, etc…
This works great for “creation” type software, programs for making images, reports, websites, etc… or programs 🙂
It ensure that the user can fully evaluate your product, but at the same time cannot use the output for any practical purposes. And he’ll probably run into this limitation quite quickly.

Disabled Save Feature

I love this one. If it is possible for your app, go for it. Why? Because it lets trial users see what they can do or create, but not save it for any practical use. A classic example of leaving a feature out without limiting the user’s abilities to evaluate your entire program.
We did this in the trial edition of the jigsaw puzzle creator software we have sold for a while. It allowed users to create their own computer jig saw puzzles from digital photos, view them on screen, even play them, but it did not allow saving the created puzzle.

Limited Number of Entries

The idea here is that all features are fully functional, until the user hits a set number of entries. After that, the Add or Create feature is disabled.
This can be a great limitation for database type apps, if you choose the limit right. Set it:

• Low enough to make the trial edition unusable for any practical purposes
• Low enough to make an enthusiastic user run into the limit within the first hour(s) of use
• High enough to allow full evaluation of the software.
• High enough to create a lock-in. Make the user feel he has invested too much time adding entries to give up now.

You guessed it, this is what we use for the Collectorz.com programs. For example, the trial edition of our DVD cataloging software is limited to 50 DVDs.
When the user hits the 50 DVD limit, the Add Movie, Edit Movie and Export features get disabled, the program goes into “view only” mode.

Recommendations

If you are looking for a way to limit the trial edition of your new software (or a better way for your existing program), here’s my recommendations:

• Don’t just go for the “default” 30-day trial system. Use that as a last resort, if you really can’t think of anything better.
• Try to limit functionality without taking away the user’s ability to evaluate all features.
• Don’t let them use your software for free, make em pay before they can do or create anything useful.
• Make em pay quickly, go for the “wow factor” within the first hour and pull in the sale.
• And if you can pull it off, go for the lock-in.

Finally, try to think about a limitation that is specific to your type of software, something original, or an original twist on one of the above methods.