Skip to main content
Solved

CloudKit RecordName as RevenueCat appUserID

  • 18 April 2023
  • 3 replies
  • 71 views

I want to use RevenueCat only with non-anonymous appUserIDs.

I am using the CloudKit recordID.recordName of the user as a unique user ID. This recordName should be consistent across reinstalls and across devices as long as the user is logged in with his same AppleID.

I am getting that userID async during launch of my app and it may not yet be available when I call Purchases.configure().

My question: Will the customerInfo that gets created during .configure() be alway associated correctly with the customerInfo of the user with the appUserID (CloudKit recordName) if I call .configure() first at app launch and typically a few moments later .login() with the appUserID?

Or does this create lots of “dangling” anonymous customerInfo records in RC that have no future use?

 

I have read the login alias information in the docs: https://www.revenuecat.com/docs/user-ids

But I am still not certain about what happens. Especially line three in that table

“Anonymous    Yes    Yes    CustomerInfo transfers to Provided ID, no aliases created.”

leaves me with the question whether this means that

  • RC will create a new anonymous user/customerInfo each time the app launches.
  • The first time this happens the newly created anon customerInfo is merged with the appUserID at .login() that is happening moments later.
  • The second time this happens (at next app launch), there is again a new anon user created, but at .login() this time the appUserID is already known by RC and has an associated alias already (from the first app launch). This means that the customerInfo of the known appUserID is used according to the table line 3 (i.e. the newly created anon customerInfo gets not merged).
  • Does this create lots of “dangling” anonymous customerInfo records in RC that have no future use?

Hey @KlausM ,

 

I will try and answer your questions below: 

  • RC will create a new anonymous user/customerInfo each time the app launches.

This will happen if you call configure without a specific app user ID. If you don't provide an App User ID when configuring the SDK, we will generate a new random App User ID for you and cache it on the device. In the event that the user deletes and reinstalls the app, a new random App User ID will be generated. You can configure on launch with a specific app user ID so that doesn't happen on your end and no transfer event would happen. More information on this can be found here: https://www.revenuecat.com/docs/user-ids#provide-app-user-id-on-configuration

  • The first time this happens the newly created anon customerInfo is merged with the appUserID at .login() that is happening moments later.

This is likely because you are configuring without a specific user ID, then logging in with the login() method which will cause those to merge together and transfer the proper entitlements to the logged in user. 

  • Does this create lots of “dangling” anonymous customerInfo records in RC that have no future use?

These aliases ID’s simply just get transferred and will not be shown as extra customers, but they are now attached to the merged ID’s and can be seen in things like webhooks in the aliases field.

 

The best way to probably solve this would be by just configuring with a specific app user ID on launch, so everything is verified and the correct user is logged in instantly without calling login so nothing would need to be merged. 

 

Please let me know if you have any other questions! 

@Michael Fogel ,

thank you for your quick reply!

Does this mean one custom appUserID in RevenueCat can have multiple anonymous aliases associated with it?

Or

Does it mean that in a scenario like shown in line 3 of the table in the docs under “login() method alias behavior” (https://www.revenuecat.com/docs/user-ids#login-method-alias-behavior) that temporary anonymous app user ids created by RC are thrown away? Like in the following flow:

  1. an anonymous app user id is created by RC as the current user id because configuration happens without a custom appUserID provided
  2. the user logs in with his custom appUserID. Lets assume there is already an alias associated with that appUserID in RC
  3. the table states that in such a case there is no alias created. What happens to the temp anon app user id created by RC in step one? Is it “thrown away”?

Hey @KlausM ,

 

We will create an anonymous ID every time configured is called without a specified ID. These ID’s would just become aliased once a restore is triggered and they would depending on your restore behavior either transfer, alias, or the restore would be blocked. So technically one customer appUserID could have multiple anonymous aliases, but they are basically not looked at once the custom one is set and defined. 

Reply


Terms & ConditionsCookie settings