Mailcheck.js - How we decreased sign up confirmation email bounces by 50%
blog.kicksend.com
blog.kicksend.com
- Fields for typing-in a credit card
- Fields for typing-in an e-mail address
- Fields for typing-in a U.S. street address
There are widely-known techniques for optimizing data entry for these fields, yet these techniques aren't widely adopted, and further yet they're known to increase conversation rates.
Someone should build a (subscription) service where you can embed a bunch of fields (and labels) onto a form with a single line of Javascript.
Then, the fields would render on the page. The performance of the fields (their effect on conversion rates) could be measured continuously. New variants of the labels and fields could be A/B tested continuously as well. That is, the performance of the fields would improve over time.
If there's interest I'll elaborate in a blog post (with mockups).
made a few edits
As someone who's currently looking over PCI compliance stuff: YES.
Other than the long-term storage of credit card numbers stuff, most of it focuses on security measures I'd want someone using Stripe to have implemented.
After all, if someone hacks the server, they're going to have an easy time adjusting the flow to save the CC# that's supposed to only be going to Stripe.
Just thinking out loud really, I know nothing about PCI compliance or law.
PCI compliance rules are designed to test the serious risks that can be tested.
If the credit card data doesn't pass through your servers, then it doesn't pass through your servers.
Stripe complies the same way as PayPal; it just looks different to the user.
It's also worth noting that there's a big difference between data at rest and data in motion. If your site is hacked tomorrow and starts redirecting CC info, then all of the CC info between tomorrow and the day someone stops the hack is compromised.
If CC data is stored on your server in any way -- and this if it passes through your server, this may be the case even if you aren't putting it in a database -- then when someone hacks your server tomorrow, it's quite possible that all CC info entered since 2003 (or whenever you started) is compromised. That's a much greater risk.
jQuery is third-party source code too, but I can host it myself.
The vast majority of PCI compliance requirements - those relating to server security - would seem to still apply. If someone hacks your server, they could easily add an additional bit of JavaScript that sends the CC field to a second, malicious server.
All data should be 256bit ssl encrypted for point to point security and asset tampering protection. After that, i doubt stripes js lib is much of a problem, it communicates in a secure tunnel from the client to stripe.
They as well say you don't have to worry about PCI compliance then because you are never handling financially sensitive data directly, only indirectly.
It's a technique I use, along with only allowing digits and doing some format masking (i.e. spaces or dashes to split the number into 4 digit blocks) to make the number more readible
Not quite the same, but sounds a bit like inForm[1]. These guys presented at a recent HN London meetup[2] and this was the meetup.com description which summarizes it better than I could:
"Ever wondered how users engage with your site, where they get stuck or how long they spend making choices? Forward Technology's upcoming form analytics service inForm can help you answer all these questions and more. Without any configuration Inform allows you to quickly build up a strong picture of what happens when real visitors interact with your forms."
Beta sign-up for HNers here[3]
[1]http://inform.forwardtechnology.co.uk [2]http://vimeo.com/32617520 [3]http://inform.forwardtechnology.co.uk/users/sign_up
But testing multiple fields, with multiple variables and experiments requires lots of traffic.
And what works for one source of traffic, PPC for example, won't duplicate to other sources of traffic like TV / Radio / PR / SEO / etc.
We recently ran a ton of traffic just around an inbound-email newsletter pop-up that lists out what we found to work best here:
http://www.conversionvoodoo.com/blog/2012/01/opt-in-email-ne...
Those are some "tried and true tips" that we'd stand behind for a popular affiliate marketing blog getting most of their traffic via SEO and referral, but unfortunately the entire addressable universe that we can guarantee those results for are the client we undertook the project with ;)
The base case alone would be enough to get many to buy your component but for a subscription (where the real money is) you need to provide continuous value.
So your pitch could be that using your product would instantly get you the best industry standard input forms but over time they'll get better because you're going to apply a/b testing and machine learning on them continuously.
We implemented the Luhn[1] algo credit card check on the checkout page. Invalid CCs would trigger a little warning but still allow the form to be submitted. Invalid CC transactions dropped ~90% immediately. Even better we were able to get rid of the 'select your card type' field since that was detected by Luhn. A little JS was a win all around.
Out of curiosity, why allow the form to submit anyways?
FYI: Card Type is not determined by Luhn algorithms, but rather (broad brush strokes, see http://en.wikipedia.org/wiki/Bank_card_number#Issuer_Identif... for more detail):
3 - American Express 4 - Visa 5 - Mastercard / Diners 6 - Discover
I think you misspelled "open-source widget library".
We experimented with doing something like this on Quizlet, but didn't actually launch anything. We first looked at a lot of the data and doing based on string distance is the wrong approach.
For example, if you type hotmail.de into that checker, it suggests hotmail.fr. Another is ymail.com --> gmail.com. The more valid domains you add, the more (correct) permutations get marked as invalid. We have 20k users with ymail accounts.
I think a blacklist approach is much more solid than a whitelist approach, I just haven't gotten around to building it.
Just curious, but are you suggesting that plain text is the wrong way to store an email address? Your comment makes me draw that conclusion, which of course seems rather silly.
If email addresses are obfuscated in some way, the difficulty for an attacker is increased.
The tradeoff in convenience is that you force a user who has forgotten his password to remember what email address she signed up with in order to recover it via email.
Hashing an email address would be pointless because the the email address is no longer usable to do things like, you know, send email to that person. As such, the only real option is to store it in plain text--and that makes the most sense.
Off-the-shelf usefulness would be improved a lot if the plugin contained a list of say 100 or so of the most commonly-found email domains.
My 2c.
Edit: Another good idea from hinathan.
A mx checking service sounds awesome. Keep us posted if you guys do it.
`$ dig hotnail.com MX` yields results but is still invalid.
But just showing a little note "are you sure you didn't mean username@gmail.com", then letting them submit anyway, isn't generally annoying even for misfires.
Because there actually are going to be occasional users who mistype "ymail.com" when they mean gmail. Hey, thanks for the warning; the y is right near the g.
One thing we do differently on http://www.queondaspanish.com/ though is allow users who haven't confirmed there email use the logged in features but with limitations. They can keep track of their lesson progress for example, but not send messages to other users. They can also change misspelled email addresses, which I think would help in your case.
casema.nl, chello.nl, hetnet.nl, home.nl, kpnmail.nl, kpnplanet.nl, live.nl, online.nl, planet.nl, quicknet.nl, schuttelaar.nl, skynet.be, t-online.de, tiscali.nl, upcmail.nl, wanadoo.nl, wxs.nl, xs4all.nl, zeelandnet.nl, ziggo.nl, zonnet.nl.
This checks email addresses using regexps and DNS.
It's certainly plausible that Google or FB login is a more pleasant experience for customers, just be aware that a non-zero number of people will bounce from your site if that's all you offer.
How is that different from OpenID? Creating an account on e.g. MyOpenID is easy enough - you just need to write an username and a password; even the email field is optional.
I tried highlighting this in the FAQ and on the purchase page, but the rate at which it happens didn't seem to change.