Review anonymous user use cases

[kiootic]

Description

Skygear currently implements anonymous user as a real user using implicitly generated credentials (asymmetric key pair).

Some website may want to support 'shopping cart'/'order' for anonymous users. Later on, the anonymous user can signup, and the shopping cart/order can be associated with the user automatically.

Portal Design

Remove this section if the feature have no Portal

Blog Post Specification

Blog Post of the Feature Release

Open Questions

Put a list of open questions here before a complete design / specification is decided

Related Issues

• Server Issues
• Client Issues
• Guides Issues

[kiootic]

The term 'Anonymous user' is quite vague and can be interpreted very differently in different use cases:

Use case 1: anonymous game user

For quick onboarding purpose, developer may want to allow a game player to skip registration and enter the game directly. Player data is stored server-side, therefore developer need to have a way to associate player data with these un-registered players ('anonymous user').

• After registration, the player data should be associated with the registered account automatically.
• Often these type of games are on native platforms, instead of web platforms.
• Player ID should be stable and kept for a long time (e.g. for leaderboard reference), therefore should the data should not expire, or have a long expiry time (e.g. 1 year)
• It is likely a player would goes unregistered for a long time (e.g. weeks to months) before finally registering.
• Player data is valuable (since it can represents a long term progress in game), therefore should be protected and persisted adequately.

Firebase doesn't automatically remove them because it doesn't really know if a user is still storing data linked to that login - only the app creator does. Imagine if you are playing a puzzle game on your phone, and get to level 100. Then when you go to play level 101 next year, all progress is lost. Firebase can't just assume a user being inactive for a year means that the account can be removed.

Use case 2: e-commerce guest user

E-commerce website often allows visitors to add items to shopping carts and checking out (create orders) without registering. Storing shopping cart data at server side is a better option than cookies since it can be quite large, and obviously order data should be stored at server side. Therefore developer need to have a way to associate these data with these guest visitors ('anonymous user').

• After registration, the shopping cart/order should be associated with the registered account.
• Users may want to associates a previous order (as a guest visitor) with the newly registered account.
• Shopping carts do not have an identity (i.e. no natural key), and referencing a specific shopping cart is not a critical requirement.
• Orders have an associated stable ID that should not be changed.
• Shopping carts for guest visitors can be numerous, and should be trimmed regularly (e.g. 1 day of inactivity).
• Orders must be preserved indefinitely for both guest visitors and registered visitors (for invoice/audit purpose, etc.).

Analysis

The 'anonymous user' feature as currently implemented supports the game use-case. However for the e-commerce use-case, it can be understood that its requirement is much different than the game use-case.

For the e-commerce use-case, it is suggested that our 'anonymous user' feature is not used. Instead:

• Represents shopping cart as a record stored in app database
  • id: surrogate key, store in a client side cookie for looking up
  • expire_at: expiry time, update on each page visit
  • user_id: Skygear Auth user ID, nullable. Used to associate with a specific user.
• On user signup, developer passes a shopping cart ID in user metadata, and associate the shopping cart with the user at after user create hook.

Some references on how some existing systems handle it:

As soon a user arrives at the MCS homepage, an anonymous cart is created for the user, an entry is made in database and the cart id is stored in a cookie also.
If the user adds some items to the anonymous cart and logs in, the following use cases can occur:
The system changes the ownership of the cart from the anonymous user to the logged in user and deletes the cookie.

[chpapa]

1. Users doesn’t always use your feature as you wish, they would “misuse” it as long as it is convenient.

2. Ummm seems it is a bit off topics if this discussion is reflecting to our discussion on Tue product meeting. Since we were discussing if we have any other way to implement web anonymous users than simple cookies as token store; as web, unlike mobile, doesn’t have common secure vault standards. We wanted to decide if we want to implement the same feature for web now. Maybe just imagine the use case is now we need to develop the gaming project in web?

3. Agree there are no simple way for us to determine when can delete the anonymous users, so ignore this frequently asked question in our design make sense

[kiootic]

1. Users doesn’t always use your feature as you wish, they would “misuse” it as long as it is convenient

Yes I agree. However, I don't think we should let the 'misused' use-case to guide us in feature design.

2. Ummm seems it is a bit off topics if this discussion is reflecting to our discussion on Tue product meeting. Since we were discussing if we have any other way to implement web anonymous users than simple cookies as token store; as web, unlike mobile, doesn’t have common secure vault standards. We wanted to decide if we want to implement the same feature for web now. Maybe just imagine the use case is now we need to develop the gaming project in web?

Last time in the meeting, I suggested against implementing 'anonymous user' feature for web platform at the moment, since I can't see a concrete use-case that requires this feature that even if I throws out a design, I would not know if it would fit a real use-case.

Then, it is suggested that some websites may want to use 'anonymous user' feature to implement shopping carts for guest users. Therefore I opened this issue to see how 'anonymous user' feature can fit into this use-case on web platform.

After some researches (shown above), my opinion is that:

• Games is a valid and common use-case for 'anonymous user' feature on native platforms.
• Shopping carts is not a valid use-case for 'anonymous user' feature.
• I would like to avoid designing for a made up use-case just for completeness of supported platforms.

Next step would be researching how web games would like 'anonymous user' behaves and some existing implementations.

[chpapa]

@kiootic great thanks a lot. Just bare in mind if it is simple we just want to avoid the overhead of revisiting the feature. But if it is too complicated / take long time it might not worth and better wait. Your call.