Anonymous User Handling

[jonfroehlich]

I'm still not sure why we don't do this with anonymous users:

1. New user visits Project Sidewalk
2. User clicks on 'Start Mapping.' At this point, we auto-generate a unique anonymous user id
3. If user clicks on 'register' at anytime during session, we convert the anonymous user id to the registered id

Thoughts? @sbower213 or @misaugstad?

[manaswisaha]

This is the issue we had the discussion about adding a unique id - #299

[jonfroehlich]

Why do I feel like I'm stuck in a perpetual cycle?! Argh!

[misaugstad]

I would love it if we could find a way to deal with this cleanly in our next deployment to other cities. The frustrating tradeoffs that I currently see between our two main options:

If we continue as we are (with all anon users having the same user id, and we differentiate their actions based on IPA)

• 👍 We don't have to implement anything new :)
• 👍 Defining an anonymous user by IP address is arguably closer to the "truth" than considering every new session as a new anonymous user (although by using IP address, we erroneously group some users on the same LAN at a university/business).
• 👎 Every time we want to implement something on the backend that does X for each user (think: computing a user's labeling frequency, getting a user's labels for clustering, etc), we have to write a separate (though similar) query for anonymous and registered users.

If we give a unique ID to an anon user for every session (as suggested in the initial comment for this issue):

• 👍 I believe it makes future fixes and implementations easier/simpler; for example, it gets rid of all our current difficulties with duplicating queries, it would make it easier to assign contributions as an anon user to their account when they register (Add anonymous user contributions to the account user creates after sign-up/in #783), and it removes the ambiguity of situations where an IP address changes partway through a session.
• 👍 It would also simplify a ton of code that we have already written, making our codebase more maintainable going forward.
• 👎 We would have to make those modifications to our old code to simplify it, which takes time.
• 👎 This definition of an anonymous user is arguably further from the "truth" than using IP address. It is possible that we could make some modification to this method, where we give a new anon user id to each IP address, and whenever a user starts a session, if that IP already has an anon user account, we automatically "sign them in" to that account. This would add at least a little bit of complexity. I haven't thought through all the implications, so I'm not sure how much more complex things would really get.

[misaugstad]

Oh I forgot to mention what I think we should do: I am leaning towards giving a unique ID to anon users for every session. If we think that IP address is a significantly more defensible strategy for reporting data in a paper, I think we could do something special for the paper, like group anonymous sessions based on the IP address that was used at the beginning of the session.

Of course, the pros and cons are just what I came up with while thinking about this for 10 minutes this afternoon. I think it deserves thoughts from others on the team, and it should be discussed in a meeting before we make a decision. Especially since we have been kicking this idea around for over a year and a half now.

[misaugstad]

I am thinking that I will make this the next big update that I do. A lot of the other features we want to implement this summer would involve different implementations for anonymous and registered users. But once we give anonymous users a unique id like registered users, we should be able to do just one implementation of everything going forward :)

[misaugstad]

Closing via #1293