In a normal sign in flow, i am creating an anonymous account first. And later using social sign in link the account.
the issue is, when the same player goes to a new device, that will create a new anonymous account first.
And the only way (that i could find) is to delete this anonym account and then try to sign back in with the social account.
This works, but i creating and deleting accounts, seems incorrect, vs merging accounts (if possible, i couldn’t find how to do that). Also, these are all extra I/O operations which get charged, so this seems incorrect. I’m sure im missing something here.
So, anyone please clarify how to handle this scenario?
It took me a while to find a flow that makes sense and works with Unity Authentication assumptions. You might get something out of this…
Make your default entry screen one that has options to “Play Now” (SigninAnonymously) or “Log In With My Account”
For any device, the user will see this on the first visit. If they click play now, create an anonymous account.
Save some data locally to PlayerPrefs (or the PersistentDataPath if it is longer term player data).
On future loads, first check if anything is saved locally, if you can find it, this is a return user and so bypass the opening screen and just log them in (but allow them to sign out elsewhere in your flow).
If a user clicks “Log In With My Account” (your chosen social options) then there are two outcomes. If they have an account then it will retrieve it. If they don’t have an account then it will createa a new one. You can query player data for creation time or linked accounts etc to work out whether this is a return or first time user in case you need to run any onboarding flows.
Elsewhere, create a flow to Link an anonymous account with a social account.
the solution seems very logical for the scenario. Thanks for sharing.
I considered the scenario you presented, but, the player can still press ‘play’ (instead of sign in with social) on the newer device at launch, which still creates the anonymous account.
I’m only hoping for a clean ‘merge’ of some sorts, because in a sign in process deleting an account seems very wierd.
Yes, if they click Play Now rather than click on a Linked account (assuming they had a linked account) it would create a new PlayerId, but that is how Unity Authentication works. The only path from there is for them to link an account or to sign out and resign back in with their previous account.
After the account has been created, I have another step after on-boarding that “sets up” the user on CloudSave. Up until that point, there is a Player Id but no CloudSave data.
I’m not too worried at this stage about these extra accounts, yes, they are “wastage” but I am more concerned about legitimate player accounts where the user has gone dormant or has deleted the app.
But in the future, I will likely write a script that is automatically triggered in CloudCode every week that will scan the user base for any PlayerIds that don’t have associated CloudSave data and that were created over XX (e.g. 30) days ago and just delete them. Likewise, at some point I will probably auto-delete any accounts where the user hasn’t played for over 12 months (after sending some push notifications to try and re-engage them).
@nmckean Thank you very much for your inputs. Glad to know i’m not messign up things and this is how the setup is from Unity.
I think your method of cleaning the accounts later is much cleaner and safer.
Just that being an indie engaging in more services (like CloudCcde etc) might potentially get costly, so as of now, just deleting the accounts as and when they are deemed redundant. But, i do agree with your approach. Thanks for sharing.