Skip to main content
Solved

Help Me Solve Anonymous User ID Bloat

C
Forum|alt.badge.img+2

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

Best answer by jeffrey_bunn

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.

View original
Did this post help you find an answer to your question?
This post has been closed for comments

2 replies

jeffrey_bunn
RevenueCat Staff
Forum|alt.badge.img+6
  • jeffrey_bunn
  • RevenueCat Staff
  • 268 replies
  • Answer
  • January 7, 2025

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.

C
Forum|alt.badge.img+2
  • Chris Thornham
  • Author
  • Active Member
  • 11 replies
  • January 7, 2025

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

Have a great day,

Chris

jeffrey_bunn
1 person likes this
  • jeffrey_bunn
    jeffrey_bunn

Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings