Trial extension abuse prevention

Just in case anyone else is curious, here's what I've done to address this. My product's integrated trial extension request process is now based on offline trial requests. From within the application a user who wishes to request a trial extension is led through the generation of an offline trial request and even the creation of an email to the appropriate address with that XML document as the body. When I receive that request, I attempt a manual activation which results in one of three actions:

1. If the manual activation does not show the trial as already expired based on the absence of an existing known trial duration and a field in which to enter the extension length, I instead create a verified trial extension key and send that to the requesting user.
2. If the manual activation shows the trial as expired and it's a reasonable request, i.e., either for one additional free trial period or the requesting user has already provided sufficient explanation for why more time is needed (typically due to large company purchasing processes), I create an offline trial extension request for the desired number of days and send that to the requesting user.
3. If the user has already had enough trial time and doesn't have a good reason for more, I tell them (politely, of course) that it's time to make a purchasing decision.

For 1 and 2 above, my product's integrated trial extension process accepts either a verified trial extension key or an offline trial extension response XML document as a way to extend the trial.

So again, that's what I'm doing right now (or at least will be starting with the tomorrow's update). I'd be curious to hear if there's a better way to do this, but as stated in the original post above, it seems like with verified trial extensions you lose the total trial time information, and with offline trial requests you can't extend an unexpired trial…a bit of a catch-22.

This is an interesting question. So, there’s a way to determine how many trial days are remaining, but there’s no way to determine how many trial days a customer has used. Well, not client-side. On server-side you can.

It sounds like what you’re asking for is to explicitly limit the amount of trial extensions to 1.  Do I have that right?

No, not quite. I just want to know how much trial time a user has already had when they request a trial extension. While my general policy is to provide one free 30-day trial period that starts automatically upon first install and an additional 30-day extension by explicit request, there are situations in which more time is warranted. The three most common such scenarios are:

1. Someone who is committed to purchasing a license (or more commonly, multiple licenses for their team), but the purchase is tied up in some bureaucratic process. I don't want these folks going without access to the product while they wait for their licenses to be purchased and issued.
2. Someone who started their free trial and work/life got in the way, preventing them from fully-evaluating the product, and then they come back to it some time later to give it another try. This has certainly happened to me when evaluating things myself and I've had to make the exact same “hey, I'm just now coming back to this” request for more evaluation time.
3. Someone who has received a recycled machine from their IT department where the previous owner had already installed the product. This actually happens quite often, and a common situation is that the previous owner took a look at my product at some time in the past and decided against--or perhaps just started it once and then never had a chance to evaluate it--but now the company is looking at it again. Because the machine's fingerprint is unchanged, the new owner of that machine isn't even offered a free trial.

The challenge is trying to separate those folks from the ones who try to act like they've never had a trial extension so that they can keep riding a free product indefinitely. I'd like to have enough information to identify folks in that last group without unfairly penalizing the others.

So basically when someone contacts me asking for a trial extension, I'd like to know whether they're truly just asking for more evaluation time after the initial 30-day trial has expired (or is close to expiring), or if they're asking for more time month after month (after month) so they can continue using the product for free. Folks in the latter group are sometimes easy to identify because they request from the same email address and/or using the exact same copy/pasted request wording, but others can be quite crafty, using completely distinct email addresses and verbiage for each request.

The process that I put in place with yesterday's update of my product solves this problem quite well. Because I now require all users who want a trial extension to generate and send an offline trial request, I get to see how many trial days they've used (at least if it's past the original free 30-day trial period). If they're still in the original 30-day trial, I create a 30-day verified trial extension key for them; if they've already had an extension of some form, I can see just how long that's been and decide how to respond accordingly.

It'd be wonderful if this were handled in a more unified manner, the simplest option IMO would be to allow an offline trial request generated during the original trial period to result in an extension instead of behaving as an activation of the original trial (which is already active).

Does that help clarify the use case? Let me know if you need more info.