: How to you prevent someone from getting a "new free trial period" by just creating a new login? I am considering several options for the Trial version of our web app. The one I favor the
I am considering several options for the Trial version of our web app.
The one I favor the most is the classic trial period.
Of course, it's a LOT easier for someone to hack this system.
They can defeat the various methods of fingerprinting the user, thusly:
Browser cookie: Clear their cookies completely (or just for our site) or use a different device. Although Evercookie may help with the former.
Email address: Create a new login (with a new email address)
I'm going to monitor things for a while and just see how it goes. If it's a problem I'll consider requiring a credit card number matched to a name and billing zip code. Each such "ID constellation" would be considered one user. Someone could still have multiple credit card numbers but we could flag the same name+zipcode coming up again.
Are there any better ways to do this?
More posts by @Sarah324
5 Comments
Sorted by latest first Latest Oldest Best
Tag your users, and tag them good.
Make the sign-up for trials generate a simple link with a UUID or an actual high-entropy token to identify the source. That token should then attach itself as pervasively as possible. URLs, cookies, LocalStorage, you name it, that UUID should be there. It should be easier to click your magic link than to create a new signup.
You may find that you need to completely separate your trial authentication/authorization from real, credentialed users (i.e., Charlie doesn't get inside the chocolate factory without a Golden Ticket—the magic tracking token should be all that's required to try your software). In the spirit of the above suggestions, you will want all browser bookmarks created by your trial users reference the radio collar you crafted for them.
In general, the solution is more Economics than Software Design:
Make your product easy to try.
Make your product easy to buy.
Make your product easier to buy than to rip-off.
Getting a trial should be as as you can make it—assuming you can actually convert your trials into real customers, you should be handing out free trials Wherever Web Apps Are Sold(TM).
A happy user of your trial product should find it easier to enter their credit card number than to figure out how to clear their cache, lose all their cookies and wipe local storage. Only people who can see the value in your product will be wanting to get more. Those people are your future customers.
Finally, spend your development effort to make it super-easy to buy your product. Engaging in an arms race with people who will never buy your product isn't worth the effort. Finding all the domains mailinator.com has registered is far from trivial, and that's just one way an active user of your product can find unlimited email addresses.
Some final suggestions:
Make sure your Take My Money link is prominent.
Only require the bare minimum details to make the transaction go through. A fast checkout lets the money get to you quicker.
Sign-ups should be plentiful and refunds painless.
Reduce the value in creating lots of signups. If you have a way to restrict all free trials to a limited (not crippled, but limited) experience, then the value of a proper signup becomes even more compelling. For instance, if paying customers can create unlimited widgets, free trials can only create five. Enough to try, but too limiting for real use. If you have twenty chapters of something, try rotating the unlocked chapters every week.
If you don't want to cripple the experience, keep in mind that you're allowed to make them think that the trial is still working after the trial is up. Maybe they find a sudden, unexplained increase in the amount of promotional banners on all the pages.
Also, if "many of [your] users are over 60" (sic), you may want to make sure that any of your proposed anti-hacking efforts don't become obstacles to likely sales.
Use a Hash Generator to create a License Key.
Associate the Key with the users login info, created during registration.
Send them an Activation Email. In the link, pass the LicenseKey and generate a Timestamp.
Save the timestamp in the DB, along with the Key, and the UserName
When the user logs in, put a check in your software like so:
PSEUDO-CODE
$authentication => check_login_info($userid, $key, $timestamp)
$new_timestamp === $timestamp + 30 days
if current_date >= $new_timestamp
//Log User Out, or show Product Page and Force Purchase
Else
// Continue
fi
Along the same lines as the other answers... by requesting an item of personal information that is difficult to repeat (many times).
What about a (mobile) phone number? A code is text'd to this number for the user to be able to authenticate the first time (or multiple times)?
While it may be a turn off in some regions (due to Credit Cards being mvoe popular among the clients), on some sites it does work: require valid credit card details for a free trial. Once the customer enters the details, mark the name on the card as "used" in your application. This will prevent same user subscribing multiple times with different credit cards he has on his name.
As other people suggest in the comments below, credit cards tend to be more popular in US, than in Europe so you have to keep that in mind. It would be best to do some research on your clients (if you haven't already) and implement a combination of solutions mentioned in the answers to this question.
You could force sign-ups via Facebook and then check how many friends they have from your application. If they have less than X do not give them a free trial. Of course if someone just doesn't have any friends they will be excluded.
Just adding, this only makes it more work on the user's part to get a free trial. They could simply create a bunch of fake friends for their fake Facebook account. To some the work may be worth the effort.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.