Skip to main content

SUGGESTION: Allow custom ANONYMOUS AppUserIDs

  • May 31, 2026
  • 1 reply
  • 11 views
C
Forum|alt.badge.img+5

It would be helpful for the SDK to allow apps to submit custom Anonymous App User IDs with their Configure() calls. These would be used instead of generating a $RCAnon app user ID, but would still be Aliased if/when the user subsequently signs in and the app calls .login().

In my case, my app can provide a more persistent anonymous identifier than what $RCAnon accomplishes, which leads to a better user experience, but we refrain from doing so because we get undesirable Transfer Purchases to New App User ID behavior instead of the aliasing that happens with $RCAnon.

It we could get that aliasing behavior with a custom AppUserID, we would supply our persistent anonymous identifier and the end-user would have a better experience.

1 reply

Tarek
RevenueCat Staff
Forum|alt.badge.img+6
  • Tarek
  • RevenueCat Staff
  • June 2, 2026

Hi Carlos,

Thanks for the suggestion, this is Tarek from the RevenueCat Developer Support team, happy to dig into this with you.

 

You've described the behavior exactly right, and it is intentional.

The alias-on-login path only kicks in when the current App User ID is one of our anonymous IDs (the $RCAnonymousID:... value the SDK generates). Any ID you provide yourself is treated as an identified user, so a later .login() follows your project's Transfer behavior instead of merging the two profiles.

 

The reason it is scoped that way is to avoid accidental merges. If provided IDs could alias freely, an app that reuses or hardcodes an ID could end up chaining large numbers of unrelated users into a single customer, which is very hard to unwind later.

 

Here are a couple of options you could use in the meantime:

  • If you want the merge behavior with the least friction, keep letting the SDK generate the anonymous ID for the pre-login phase, then call .login() when the user signs in. That aliases the way you would expect. The tradeoff is the one you called out, our anonymous ID is less persistent than your own.
  • If you would rather use your own persistent identifier, you can .configure() anonymously and then immediately call .login(yourPersistentID). Because the current ID is still anonymous at that point, your persistent ID gets aliased in, and since it is your own value, it will survive reinstalls. One thing to keep in mind, once the user is logged in on that custom ID it counts as identified, so a later .login() to a different authenticated ID would transfer rather than merge. This works best when your persistent ID is the identity you intend to keep going forward. If you do need that second hop, the reliable pattern today is to keep the ID mapping on your side and reconcile on login.

Here is the doc that lays out the rules, the table under "logIn() method alias behavior" is the part that applies here: https://www.revenuecat.com/docs/customers/identifying-customers

 

So far, we didn't encounter cases where a different model was necessary. Don't hesitate to share the overall problem you're trying to solve, perhaps there is a different way I can help you figure out.

 

Let me know if that makes sense and if there's anything else I can help with!

 

Best regards,

Terms & ConditionsAccessibility statement