Feature #7734
closedStoring Registration Emails for New Users
0%
Description
Opening a thread to discuss storing emails from which new users register (as now that record is overwritten when a user changes her email address). Could come in handy for reporting and use analysis going forward, and it possibly could be a tool for user role management and group/site affiliation at some point.
I do not see a reason for this information to be visible anywhere within the application at this point, however.
Updated by Boone Gorges about 7 years ago
- Category name set to Membership
- Status changed from New to Reporter Feedback
- Assignee set to Boone Gorges
- Target version set to 1.10.13
There are a number of ways to do this.
I can record the email address of users at the time of registration. This'd be a one-time operation for each new user, and would give us a single piece of information that we can later query.
Alternatively, I could record each email address at the time that it's change - an "old email" registry. This would give us more information than what's being requested here, but I can imagine a number of different kinds of scenarios where a user has had more than two email addresses, and we'd like to have information about all of them.
My main question is that, if we're going to record all address changes, how much information do we need to save? If it's just the address, it's easy. If we also want things like timestamps, then I need to come up with another way of formatting the data. Not a huge lift in any case, but it's somewhat more complicated if we need more than just the address.
(Ray, copying you here in case you have technical advice. If we're just saving email addresses, I will just add_user_meta() for each one. If we need more data, we'll need a different system. Serialized arrays may limit queryability in the future.)
Updated by Raymond Hoh about 7 years ago
If we're just saving email addresses, I will just add_user_meta() for each one. If we need more data, we'll need a different system. Serialized arrays may limit queryability in the future.)
`add_user_meta()` is also what I would recommend for now.
Updated by Matt Gold about 7 years ago
Hi All -- I don't object (at all) to this, but I would suggest that it be considered in the context of our discussions earlier this year around data privacy and keeping a minimal amount of info on our members
Updated by Boone Gorges about 7 years ago
Matt, this is a good point. Currently, it's possible for a user to have a more or less pseudonymous Commons account: while we require a CUNY address to register for the site (which reflects your real name), it's then possible to change your email address to something arbitrary, with no further indication of your identity.
Luke, can you remind us what some of the specific applications of having this data might be? I can't remember how it came up in the conversation. (Deduplication during invitations, I guess?) Perhaps we shouldn't be collecting this data unless there's a pressing need for it.
Updated by Luke Waltzer about 7 years ago
No pressing need, and certainly worthy of deliberation.
First came up when gaming what a bulk add user process might look like as a way of locating existing accounts on the Commons for folks who've changed their email addresses. I don't think we'll need it for those purposes, given the direction the onboarding work is going.
But then it seemed like there might be instances where this data was useful, since it's really the only piece of accurate metadata that we require, and is the only way that we can accurately trace who's joined us from what campus and when. If we do want to allow permanently pseudonymous accounts, then I agree that we should avoid this (and perhaps be more explicit that this is possible, and how, and why). But if we don't, then this is a way to capture some data that might be useful. We could also deidentify by disassociating the email from the account, and merely storing an independent record of what email addresses have registered (though that wouldn't allow us to use this to manage users).
I don't feel particularly strongly about this... just thought it was worthy of a think.
Updated by Boone Gorges about 7 years ago
- Status changed from Reporter Feedback to Rejected
I don't think we'll need it for those purposes, given the direction the onboarding work is going.
Yes, this is my recollection as well. Bulk-add will send invitations rather than generating accounts directly, and the invitee will have the ability (optional) to associate with an existing Commons account. So this sort of deduplication is not necessary.
In addition to Luke's data-gathering scenario, I can imagine using this sort of data to help with certain sorts of support requests. But I don't think that either of these needs is pressing enough that we should try to collect more information about users. Perhaps we can consider a future system where users can voluntarily enter alternate email addresses, if we find that we could use the data.
Matt and others, please feel free to reopen if you want to reconsider.