In a consortium environment, in what ways have you reduced the duplicate accounts created by patrons as web site users?
David,
This is something I have spent a lot of time and energy on in a couple different consortia. My biggest step was to convince folks that there are some accounts that can be merged without human intervention. So at night a process runs which identifies new accounts created through the web from the previous day, makes a rigorous check against existing accounts (exact matches on first and last name, email and sometimes mailing address) and then merges the accounts without any users needing to take action.
Another step we take in Dallas is to create web logins for any account with an email address on it using a nightly SQL job. That way, if a patron tries to create a web account using and email they already have on file with the consortium, they are informed that an account already exists and prompted to use the "forgot password" functionality to access the account.
Dealing with web created duplicates is a full time job, but with some planning and strict data standards it can be made into a manageable process.
Levi
Thanks for the reply.
We've got an auto-merge that runs nightly as well. It merges 1000s per year. We'd like to limit duplicate creation because the auto-merge isn't that desirable. An example is this....a patron creates a login and purchases tickets. The nightly merge process happens, identifies him by name and mailing address, and merges the new account with the existing household. Problem is that his web purchase doesn't move to the household.
The idea of scripting the creation of logins for every email address in the db is interesting. Do patrons ever question it?
Also, it sounds like web patron's requests search the consortium entire database, not just logins for a particular consortium member...is that right?
I've been told that patron's don't question the creation of the logins but I asked exactly the same questions when I started this job. Creating the logins is not my favorite way of dealing with this. But it seems to work here.
As for your example, we run into the same thing. A patron with transactions is merged but the transactions don't get migrated to the household. We have a custom report which is run on a schedule that shows all patrons who are in a household who also have transactions on their individual account. Our Data Integrity person then goes into those accounts and runs the "Move Transactions to Household..." operation from the front end of Tessitura.
The number of instances where this is required is quite small and easily manageable. We could have automated the Move Transactions portion as well, but we preferred to have a person review it first.
As for searching for logins, all of the logins in our database (regardless of organization) use the same Primary email as the login. The nightly process creates logins of the appropriate type for each org in the consortium.