Skip to main content

Hello,
We’re implementing RevenueCat and I’m trying to handle this case:

  1. Install the app, receiving an anonymous ID $RCAnonymousID:123
  2. Log into an account with a Provided ID XYZ for the first time. RevenueCat aliases the Anonymous ID with the Provided ID.
  3. Switch to a different device and install the app, receiving a new Anonymous ID $RCAnonymousID:456
  4. Create a subscription under this Anonymous ID
  5. Log into the account with Provided ID XYZ.

If I understand the documentation correctly, RevenueCat will not create a new alias because XYZ already has an anonymous alias. XYZ does not have an active subscription, so upon logging in, the PurchaserInfo will indicate that they are not subscribed, and the user loses their entitlements.

This seems to match the behavior I see on-device, but I’m wondering if this is this correct. Shouldn’t $RCAnonymousID:456 and XYZ be aliased? How is this normally handled?

This post may have gotten missed - just wondering if there's a way to handle this use case. The only solution I can think of is to ask the user to restore purchases after logging in, but that feels really hacky.

It seems like maybe RevenueCat previously supported many anonymous IDs linked to an account, but now it only supports one. Is that accurate?

Hi @Bryson Thill,
 

It seems like maybe RevenueCat previously supported many anonymous IDs linked to an account, but now it only supports one. Is that accurate?

Yes, what you’re seeing in the documentation is the correct behavior. We ran into some issues in the past with certain users having tons of aliases so we redesigned this with our latest Identify behavior.

For the edge case you’re describing, it doesn’t seem like most users will run into that, but we recommend requiring the user to sign in before they make any purchases. 

I see, thank you for your response @sundeep! I hope that RevenueCat will consider supporting multiple aliases again in the future, or somehow merge the accounts in this case. I believe that requiring sign-in before making purchases would significantly impact my project’s revenue, so this seems like a pretty major regression in functionality.  😕

Reply


Terms & ConditionsCookie settings