Preventing user abuse of free trial

I setup a free member level to allow users to test out our service for one week. Are there precautions I could take to prevent them from abandoning their free account after one week and then creating a new one? I’m aware of the brute force restrictions but I am wondering if there are further safeguards to detect a user (among 1000s) who might be trying such a scam?

Also, since at the end of their trial they will need to upgrade to a paid account, is there an ideal way to detect and subsequently redirect them to the upgrade page when the trial has ended?

Thanks,
Joe

Hi Joe.

What you can do is have a free registration pro-form that lets them register at Level 1 for 1 week. Then your EOT behavior would demote them to Level 0, where you can show them in the Login Welcome page using a conditional for Level 0, that they should upgrade.

[hilite path]Dashboard -› s2Member® -› PayPal® Pro Forms -› Free Registration Forms[/hilite]
[hilite path]Dashboard -› s2Member® -› General Options -› Login Welcome Page[/hilite]
[hilite path]Dashboard -› s2Member® -› API / Scripting -› Simple/Shortcode Conditionals[/hilite]

No, there isn’t really a way to prevent someone from just registering over and over with new email addresses, that’s a risk you’ll run. Even if you used cookies to track him, he could delete them or use another browser. I’m sorry, but this is a problem everyone runs into with trials.

The one thing you could do is always show the same content to the trial users and only let the paying users see more, but I don’t know if that works for your what you’re creating.

I hope that helps. :)

• This reply was modified 4 years, 8 months ago by  Cristián Lávaque.

Thank you that makes sense. I was having them register in at level 0 so there was never a demotion.

I’m glad it helps. :)

The usual way that trials would be restricted would be to do so via unique credit cards, ideally, then maybe phone numbers and zip codes match. I don’t know if there’s a way to work this in for future release, but it’d be good to have it be more defined.

That’s a good point, Skip, but s2Member doesn’t store card numbers, so there’s no way for it to check this. This is a check that the gateway would have to provide, but I don’t know that the ones s2Member integrates with do. If s2Member stored the numbers, then it would be able to do advanced stuff like that, but it also has a high risk and responsibility because you’re storing card numbers.

Just brainstorming here…maybe you drop a unique cookie on user when they do a trial or when subscriber level changes, and detect that before allowing subsequent trials.

I dunno, I just think this is a key thing that it’d be fantastic to figure out.