Just wondering what peoples’ thoughts are on requiring someone to confirm their email address before using your free trial.
With my product, currently, as soon as you submit the sign-up form you’re in and good to go for 30 days before I ask for payment. My fear as that if I’m lucky enough to reach any kind of scale, I might see an influx of garbage/spam accounts.
(I’m likely going to require credit card upfront in the future at which point this will be mostly moot.)
We used to but now we don’t - we asked ourselves why we wanted them to confirm their email address to use the trial and couldn’t come up with a good reason so we decided to remove it. The only thing we do is check that the email entered is “valid” and then they are straight in with an email sent in the background. We then have a banner telling them they need to set a password or they wont be able to login again which is akin to confirming the email really as it does the same thing.
Signups have gone up but there is no way of knowing if that is directly attributable to the change or something else - generally speaking, about 1/3 of people never confirm in our experience.
Also, on your last point, we absolutely will not be asking for card details up front - it might work in some industries but it puts me off and I suspect it puts most others off so I would recommend caution on that one before implementing it.
I love the CC up front. Trial users are more focused, more go deeper into the product. If you have a product that requires some setup to work I think it’s pretty much a must. I’ll probably test again farther down the line but I can’t imagine turning off CC up front.
I wouldn’t call them the same thing. Asking a user to set their password doesn’t ensure that they gave a valid email address and thus won’t prevent a bot from submitting the form.
I think CC up front is a different question altogether and hinges on industry, B2B vs. B2C, business goals, etc.
My question is more about better UX vs. protecting against spam accounts.
Assuming no CC up front, would you make your trial signup process more cumbersome by requiring email confirmation?
I think I’m going to go with completely frictionless trial signup and if spam/bot-generated accounts becomes an issue I’ll require email confirmation.
You’ll get loads of bots, at least we did. It’s not really a huge deal load wise but it is annoying having to try and identify real people from spam and all but of course doable.
I’m sure somebody around here has a/b tested email conf vs no conf so maybe they’ll chime in.
It does when they need to click a link in the email sent on signup to create their password 
Do you think a honeypot captcha would cut down on those bot submissions? Did you have one? We’re not going to enforce an email confirmation for Harpoon, and we won’t require CC up front either (testing that one out), but will use a honeypot captcha. Just curious if I should expect that not to work so much.
To clarify, you’re not requiring the user to enter a CAPTCHA, but rather tricking bots into filling in a field that real human users won’t see. Correct?
We use a Honeypot for Perch demos. It stops bots but a surprising amount of spam is essentially human entered (must be a fun job) and no CAPTCHA or Honeypot is going to solve that.
Yeah honeypots don’t work as well as they used to I have to say though they do work very well against bots. A much larger amount of the trial sign up spam I see is human entered. I have no idea at all why this would be. It makes no sense to sign up for app trials as a spam mechanism unless you intended to perhaps use the email systems within the app for instance to send spam, which we’ve never seen evidence of in Snappy. In HelpSpot it would make no sense to download it and run it to send spam anyway so it’s unclear why they do it.
On HelpSpot’s trials I’ve recently built a system to filter out as much of the obvious stuff as I can by a variety of factors. It’s working pretty well. I’ve kicked around the idea of building it out as a service, but no time and not sure people would pay for it anyway.
Yeah, the honeypot captcha method is a hidden field that bots might fill out. However, these are futile if a human actually does fill it out as Rachel and Ian have mentioned.
Thanks Ian and Rachel for the insight on your experiences.
Rachel - how do you identify and cleanup the spam trials? Do you just delete all trial accounts after a certain number of days elapses beyond the trial period? Or do you leave them in a disabled state?
I’d encourage you to go with evidence over gut feelings. Test changes, rather than just assuming it wouldn’t work.
I get bot spam on mine. It’s always 5 posts all in a row and about 10 total spams a week. My trial set up is manual, so I haven’t worried about it yet. I think the simplest solution to cut down on that somewhat would be a hidden field.
If that’s not your worry though, I would not do an email confirmation. There should be an email sent to them, but more of an onboarding help. I’m sending a personal looking email asking how we can help them get set up.
The demo only runs for three days - we’re not SaaS so it’s just a demo install of a site running Perch. Essentially the setup is like a shared hosting environment.
The biggest issue we had was that because the trials are provisioned by a Puppet run, if we got a heap of spam signups then that would slow down the Puppet runs meaning there was a huge delay before trials got activated if a spammy run was in progress and a legit user signed up. If we only get the odd one then it can sit there for three days and then Puppet will clean it up once it is expired.
We require email confirmations before we set up trials, because setting up a TestRail trial requires some additional technical resources on our side. We track the number of failed confirmations and the number of people who don’t confirm their email is surprisingly small. To make sure that we don’t lose customers in the trial sign-up process, we:
a) make it very clear that a confirmation from their side is required:
b) if a person misspelled their email, they can still change the address and we just resend the confirmation
In our experience this also results in higher quality sign-ups. We notice that customers sometimes try to sign-up with a fake email address and then actually update it to their real address when they see the above screen.
We haven’t tested CC upfront, but it would likely not work well for us because in many cases the person evaluating TestRail doesn’t make the purchase decision. So they wouldn’t be able to try TestRail and would just skip us and concentrate on trying our competitors. If you are B2B and dealing with both small and large companies, this could be an issue.
A quick question for anyone who is not asking for confirmation: Do you actually use these unconfirmed emails afterwards (e.g. trying to convert the customers)?
If yes, aren’t there any legal issues (country-specific or not) related to spam to be concerned about, considering that you don’t (technically) have permission to use these emails?
This is exactly our issue - also the higher the value of the sale the less likely people are to want to put cards in. In our business, someone will often be set the task of evaluating “the market” consisting of many products and then report back to the stakeholder with their recommendations. The person doing the initial test wont make the decision and most likely wont be authorised to use a card. Also, often larger customers won’t even want to pay by card and will want alternate payment means so insisting on a card just puts too many people off especially in the larger end of B2B.
I don’t use a confirmation email with pageproofer.com and I do use the email address they enter to send system notifications etc to. When they sign up the terms include a statement that the info they enter is valid and theirs.