[ic] Merge perge for user database
paul at gishnetwork.com
Sat Nov 8 10:10:39 EST 2003
Ed LaFrance [edl at newmediaems.com] wrote:
> At 09:56 AM 11/8/2003 -0500, you wrote:
>> Is there a built in way to handle merging of customer accounts?
>> i.e. if a customer orders and does not log in, they get new accounts
>> each time. If they then call in an order later, and we find that
>> they have many accounts, we would like to merge them into 1.
> You would have to do this manually, though you could probably write a
> script to handle it; there is no built in feature for this. In
> practice, once you have decided which userdb account will be primary,
> it is just a matter of inserting that customer ID in the username
> field of all affected records in the transactions table, then
> deleting the redundant
> userdb records.
> - Ed L.
Yes, and orderline has a username column as well.
So, decide the primary, then iterate through all transactions and orderlines
and swap old username for primary username. Then, take the old userdb's
'order_numbers' and append them to the primary userdb's 'order_numbers' column.
That should be all there is, assuming you never implemented advanced tables
like "order_returns" or "forum", etc.
The only hard part will be how to associate old and new usernames via ADMIN.
Your best bet is probably to make the UPDATE/DELETE query, then just copy paste
the old username with the primary username (into the query). You would have to
retrieve them first by manually searching obviously. I probably would not write
a script that compares addresses and automatically merges.
You could make two pages. One, that show results of similar
addresses/names/whatever in a row. Each record would have a:
radio () primary account
checkbox  merge account
and each row would have a checkbox:
 merge these records
Your query could be built in from that.
I avoided this by requiring login. If you don't require log in, it makes life
harder not only for you but for the customer. If a customer signs up for a
newsletter everytime he makes a purchase, it will be a bear to
unsubscribe/maintain subscriptions. If you want to offer advanced features like
personalized tools, they need log in as well. Having an order history/status is
a tool to mitigate customer service, which is really useless if they don't have
a real account.
I would rather have one record a user can control, know what he is subscribed
to, what he is not, and all his orders. I don't like one person having 20
userdb records. It probably also depends on your product though.
I think subliminally to a consumer, requiring login is a bit of a turn off.
However, they won't admit that it does instill confidence that it is not just
some hack job that will send/save your CC number in the clear to some punk teen
that drives around in a 71' primer grey camero with t-tops that steals your
lunch money even after my mom called the principle...
Ugh... anyways, 90% of all my purchases are on the web, and 99% of the sites I
use require login.
More information about the interchange-users