Skip to main content

I have a question about initializing the Purchases SDK, based on the following points from the docs:

  1. If no App User ID is provided, RevenueCat will generate a random App User ID and cache it on the device.
  2. The SDK should generally be configured early in the app lifecycle.

Many apps allow users to purchase subscriptions before creating an account. This reduces friction between opening the app and making a payment.

But, this means that I'll need to instantiate the Purchases SDK before receiving a User ID from my authentication system. This results in the creation of an anonymous RevenueCat ID for everyone who opens the app, even if they don’t create an account or make a purchase.
 

Assuming a typical conversion rate (e.g., 5%), this would mean that 95% of the users in my RevenueCat dashboard are likely people who opened the app once and then deleted it, which seems highly inefficient.
 

Is there a more efficient way to handle this situation without generating so many unused anonymous users?

Thanks,

Chris

Hi ​@Chris Thornham! Thanks for the detailed question. Many apps have the flow you described, of starting with an anonymous user, presenting a paywall, then logging in the anonymous user with a custom app user ID after they register.

If an anonymous user signs up and is given a custom app user ID, we will alias (merge) the anonymous and identified users together, and these users will be treated as the same user going forward. We will also exclude aliased users from charts, so they won’t be double counted in this case.

One approach is to delay configuring the SDK until just before you show your paywall. If, for example, you have an onboarding sequence, you could generate the anonymous user on the screen just before you show your paywall. This way, users who don’t make it through onboarding won’t be counted as a “New Customer”. 

Another approach is to forego anonymous users altogether and only configure the SDK when you have a custom app user ID, but I understand this approach may not work for your use case. Social login options have made this a viable approach, but it still introduces friction.

Thanks ​@jeffrey_bunn . That makes sense. I’ll work around the issue the best I can. 

Have a great day,

Chris

Terms & ConditionsCookie settings