Custom trials vs. RevenueCat trials?

Hey ​@user-0a9831, 

Thank you for reaching out. I'll be happy to help! 

I recommend using RevenueCat's user ID management instead of relying on UUIDs, given that they could be easily "hackable" by uninstalling and installing the app again. When you configure the SDK without passing a User ID, RevenueCat generates a new anonymous ID. Once a user registers on your app, you should call the SDK login method, which will alias your anonymous IDs with the custom User ID you created for that user in your backend.

Another recommendation for managing credits is to use RevenueCat's Virtual Currencies. When the user is anonymous, you won't need to do any extra mapping between your app's user and your backend, as you would update and fetch the remaining credits for the user directly from RevenueCat using the assigned User ID. Virtual Currencies can also help you manage trial amounts, as you can set up how many credits you would grant when the trial starts. You can read more about Virtual Currencies here, and how you would see events in the dashboard here.

I hope this helps. Please let us know if you have any questions!

Best, 

Hi ​@alejandra-wetsch 

thanks, yes I’ve more questions, 

• could you please explain how exactly RevenueCat’s anonymous user ids are safer than my UUIDs? how do you remember the user if they uninstall and install again the app? are you using device ids / hardware fingerprinting?
• using RevenueCat’s virtual currencies would mean that I’d need yet another intermediate call when calling the OpenAI API, right? Thinking about latency to the users..

Hey ​@user-0a9831, 

Thank you for following up!

I've included the answers to your questions below. 

could you please explain how exactly RevenueCat’s anonymous user ids are safer than my UUIDs? how do you remember the user if they uninstall and install again the app? are you using device ids / hardware fingerprinting?

RevenueCat does not persist the anonymous ID across uninstalls. If a user installs your app, makes a purchase, uninstalls it, and then installs it again, they could restore the purchase, and RevenueCat will allow the user to regain the entitlement. This is because RevenueCat relies on the Store Account that made the purchase, meaning that RevenueCat checks the Store Receipts for the phone's Store Account to understand if the user has already made a purchase. 

However, suppose virtual currency is granted via consumable purchases and anonymous trials, and the user reinstalls the app. In that case, the credit balance will not be restored because it’s not tied to a persistent user identity or a restorable entitlement. However, if you use a subscription or non-consumable-based product to apply credits, the restore will work as expected, and the user won't be able to abuse the trial, as they won't be able to re-purchase the same product.

using RevenueCat’s virtual currencies would mean that I’d need yet another intermediate call when calling the OpenAI API, right? Thinking about latency to the users..

Yes, you will need to make an extra backend call to update the user's credits after calling OpenAI's API. The integration strategy you choose will determine which method to use when checking the user’s current balance. I recommend reading this documentation to learn more about the different approaches to integrating this feature.

I hope this clarifies! 

Best,