

Ask N.YC: How to import Legacy Users? - e1ven

For the last 9 months or so my partner and I have been working on making a
new, web based version of Chron X. Chron X is the originally online
collectible card game, first launched in 1997. It's a great game, but the
engine is sorely out of date, and we're moving to a new revenue model.
When we bought the game we knew there'd be some problems, but we've had to
resort to more hacks that we imagined, particularly in getting the data
out of the old database.<p>As we approach beta, one of the problems we're facing is legacy user
authentication.<p>The problem is that Chron X was originally designed as part of a
"collectible bits" architecture, where you would receive a file on your
machine to authenticate you, rather than a username and password. This
worked well enough for the game at the time, but we know that 90% of the
old users have most likely lost this file.<p>We're trying to find a way to let them authenticate without it. The first
option is to let them authenticate using their email address on file. We
could send a traditional password-reset mail, and let them confirm the
account. Unfortunately,  since the game has been running for 11 years, I
suspect that many of these addresses are no longer valid. We could allow a
password-reset sent to their address, if they still have access to it.<p>As a fallback option, we've discussed allowing users authenticate if they
remember their information, such as the address they lived in when they
signed up.. We've been doing this manually by talking with them, and
comparing against the DB, but obviously this solution won't scale.
I'm hesitant to ask them to just type it in, since we've found that so
many people don't remember exactly where which address they used, or would
run into problems with spelling it, etc. The success rate for people
getting the data right without prompting is sadly low. Think errors such
as "Elm street", versus "West Elm Ave".<p>The other problem with this strategy is that many people originally
registered under false information.. We have too many 123 Fake Streets- No
one is going to remember exactly what they entered under such a scenario.<p>One idea we had was showing them the city and street for 15 random people
from the database, along with their own, and asking the user to pick the
correct data. I like this idea, but I can see a few problems with it..<p>We'd need to use some sort of hash so that we always presented the same 15
addresses, when they asked to reset that account. If we didn't do that,
they could just watch to see which address didn't change. The problem is,
if we did that, they might be able to just try all 15. If we instead
blocked them if they tried more than 2-3, then you could preform a DOS
against other accounts, by manually trying to reset their account, just to
ensure that they get blocked. ;(<p>Has anyone had to face a problem like this before? Do you have any clever
ways we could try to present data to the users, without being a wretched
user-experience?
======
edw519
One thing I have done in a situation like this was to create an artificial
hash of the user info. It ended up giving me a 95% hit rate. Something like :

Hash = SoundexOfLastName + SoundexOfStreetName + First3OfZipCode

So Jim Johnson at 123 Fair Oaks Ave in 12345 would hash to:

"J525F620123"

So just let them enter their user data, hash it, and see if you have any hits
against that hash column in your data base.

Pretty hard to hack, but pretty easy to hit, even with misspellings, etc., and
not a lot of suffering by the user.

------
ltbarcly
A combination should work well enough.

1\. Obviously allow password resets to on file email addresses.

2\. If the above fails, try geocoding the address with google or geocode.us.
If it successfully geocodes, ask the user for the address used to signup for
the account, and tell them the zipcode the address was in so they know what
address if they moved. Take the address they give you and geocode that. If
they are very very close in lat-lon it is the same address (you might call
this a geo-hash of the address).

3\. No email and fake address? Well, this is a consequence of lying when they
signed up, so you might say TFB and let them start a new account.

I can't give you more alternatives without knowing what other info you have on
them, but the first two here should cover 90% of your users who didn't lie
about their address based on the statistics that I pulled from my butt.

