11–20 of 180 posts
I'm fairly certain I would rather collect the emails even if it means less retention. Not for marketing purposes but for support purposes. With MakePostSell [1] a customer may add products to their shopping cart and interact with a shop as if they are logged in, but at the point of sale / checkout, we ask them to verify their email. [1] https://www.makepostsell.com
This genius, my ass.
Login via Google / Facebook / Whatever is sometimes helpful, but it usually results in SPAM. For example, I logged into Redfin through Google and they immediately started spamming me.
Other times, when I login through Facebook and disable sharing my email, the site that I'm trying to log into has a "mystery error" because the concept of not sharing my email address never occurred to whoever wrote the integration.
Most of the time, I just use a unique email address with each site. My domain has a catch-all email address, so when someone starts spamming it, I know who did it.
I'm fairly certain I would rather collect the emails even if it means less retention. Not for marketing purposes but for support purposes. With MakePostSell [1] a customer may add products to their shopping cart and interact with a shop as if they are logged in, but at the point of sale / checkout, we ask them to verify their email. [1] https://www.makepostsell.com
Don't bother. If you collect email addresses, it's PII and someday you will have to account for that. Instead, give them a searchable FAQ or a wiki and an email address to write to for support. Connect it to a ticket system that autoresponds with a ticket number. (then you added your second paragraph while I was writing this.)
Eg. help3a2fg@company.com
The support team can figure out which account or anonymous cookie saw that email address.
It's a handy way to still communicate directly with users while holding as little PII data as possible about them.
The article mentions the tradeoff of username Vs email of increased willingness for people to sign up Vs losing the simple channel for password reset, but does not propose a solution outside of non-expiring cookies, which to me isn't really a satisfactory solution (though perhaps it works OK enough in practice for some types of use cases). In my view, for most applications, the upside is not really worth that downsid…
Earlier quoted context omitted.
Don't bother. If you collect email addresses, it's PII and someday you will have to account for that. Instead, give them a searchable FAQ or a wiki and an email address to write to for support. Connect it to a ticket system that autoresponds with a ticket number. (then you added your second paragraph while I was writing this.)
I get users to email a personalized support email address. Eg. help3a2fg@company.com The support team can figure out which account or anonymous cookie saw that email address. It's a handy way to still communicate directly with users while holding as little PII data as possible about them.
The article mentions the tradeoff of username Vs email of increased willingness for people to sign up Vs losing the simple channel for password reset, but does not propose a solution outside of non-expiring cookies, which to me isn't really a satisfactory solution (though perhaps it works OK enough in practice for some types of use cases). In my view, for most applications, the upside is not really worth that downsid…
The article mentions the tradeoff of username Vs email of increased willingness for people to sign up Vs losing the simple channel for password reset, but does not propose a solution outside of non-expiring cookies, which to me isn't really a satisfactory solution (though perhaps it works OK enough in practice for some types of use cases). In my view, for most applications, the upside is not really worth that downsid…
In fact, the more I think about it, there's a paper I saw that can identify users solely by their mouse movements. If you maintained that kind of fingerprinting in game, you could simply ask the user to play a few rounds then offer to reset if they're from a typical IP address. Might work well for this particular website.
That's really interesting and definitely something worth trying. I wonder how the effectiveness of email changes with the goals for the user (play solitaire vs pay for a subscription, etc).
He does mention, somewhat off-handedly, that the lack of email makes password recovery harder. (Presumably impossible without some other communications channel like a phone number.) And you really need to be able to recover account access for a paid subscription. It's probably also reasonable to assume that if someone is going to give you a credit card number and address, they're probably OK with giving you an email.
It will give them the cookie again if they re-visit from any IP they've previously used.
It also re-gives them the cookie if they try to pay again with the same credit card.
Support just tells people to try to resubscribe if their subscription has 'vanished' - but it seems to happen to very few customers.
Honestly, I hate managing accounts and passwords so much that I'll walk away when a "create an account" is thrown in my face. Login via Google / Facebook / Whatever is sometimes helpful, but it usually results in SPAM. For example, I logged into Redfin through Google and they immediately started spamming me. Other times, when I login through Facebook and disable sharing my email, the site that I'm trying to log into…