Skip to main content
Solved

User ID and restoring purchases from Anonymous ID

  • 22 December 2023
  • 5 replies
  • 421 views

Hello! I am architecting the backend for a mobile application and despite reading through a lot of documentation posts, I feel I’m going in circles trying to grasp some subtle points and would love to get some answers before committing a lot of development. 

So I understand the basics of user IDs and anonymous user ids. Our app will ONLY allow users to login (and get an explicit User ID recorded in our database) AFTER a purchase.

No problem: users get an anonymous ID, they sign in and we assign them a new, unique App User ID, which we record, and use login() to associate with their RC account.

 

The question happens when the same user logs into a fresh device (or reinstalls). They get a new anonymous ID upon starting up, but then what happens when they “Restore purchases”?

My hope is that we would be able to get access to the previously assigned App User ID. However, the documentation for Restoring Purchases mentions:

If an anonymous ID restores and the owner of the receipt is an identified App User ID, we will resort to the specified restore behavior and transfer the receipt to the anonymous user.

I’m reading that to mean that the owner would now be this “new anonymous id”, but what about the user id we created and assigned earlier? Is there a way we can get the App User ID from a fresh install → Restore Purchases, even if when first starting up a user will be assigned an anonymous ID?

If not, that means that at that point, when the user needs to log in to our system, we don’t "know” they are a prior user and have no way to link their purchase to the ID we previously assigned, causing us to potentially create a duplicate account for the same user (e.g. if they use a different login method to our database, etc.). 

I’m probably missing something very simple but any help would be greatly appreciated! Thank you!

That’s fair. In that case, I would just keep the restore behavior as Transfer to New App Id and make a button available to users to restore purchases if they ever need it.

Hi,

 

I’m reading that to mean that the owner would now be this “new anonymous id”, but what about the user id we created and assigned earlier?


That is correct. The purchase would be transferred from the original user ID to the new one.
 
In this case you could have a button in your app that says something like "Returning customer" where they log in to get their purchases back. This will at least guide your users to log in if they've logged in before.
 
Unfortunately there isn't a way to know which user originally owned the purchase. You could enable the "keep with original user" restore behavior to at least prevent the transfer in this case but you would need a support path for your users to follow to regain access to their purchase. One way this could happen is to have a user write in to your support with the order number of the purchase from their Apple/Google confirmation email and you look them up in our system and let them know which account to log into or do a manual transfer via the dashboard.

Thank you; so you are saying if a user installs on a 2nd or 3rd device, the purchase always gets transferred to the anonymous user?

If so, feels like the answer is simpler than I originally thought, then? In a scenario of logging in to our database to track a user and its data, is there even a point to having an assigned RevenueCat user ID, if a user ID always gets “overwritten” by new installs? 

Sounds like I just leave the RevenueCat system to keep assigning/aliasing anonymous IDs, solely for checking entitlement, and with regard to any user data I solely use our database login to manage data.

i.e.: RC would be just an entitlement check we leave as anonymous (that we can trust to follow the subscription state consistently in time and from device to device), and after that we use our login system/database to actually identify the user.

Does that sound about right? Was my tracking of the RC ID superfluous? I would think there is a large number of apps out there that only allow subscribed users to login; is that the usage pattern?

Thank you again for your detailed answers, it’s greatly appreciated!

so you are saying if a user installs on a 2nd or 3rd device, the purchase always gets transferred to the anonymous user?

That is the default behavior, although you can use only custom ids if you’d like, and never generate anon ids.

When you follow the linked instructions, new installs won’t “overwrite” the app user id.

I would think there is a large number of apps out there that only allow subscribed users to login; is that the usage pattern?

That is one usage, another is for not allowing users to make a purchase until they are logged in, as well.

 

You can choose to use only anonymous ids, but many of our customers with their own authentication system choose to connect it to RC’s identification (i.e., use your userIds as the RC appUserId, and don’t allow anonymous ids to be used), that way every user is positively identified with a single id.

 

I understand the simplicity of avoiding anonymous IDs, however for my app I want to avoid the friction of forcing users to log in to use the application. The application is relatively lightweight and the login system is a nice bonus to have but would be overkill for people just trying out the app.

It looks like not using anonymous IDs would require me to identify users (i.e. log in) as a condition for even just checking for entitlement.

Since some of the application features are based on entitlement, that means having users login on startup, which would be too much.

Reply


Terms & ConditionsCookie settings