Skip to main content

Hi

We’re trying to configure a flow where user subscription is strictly bound to their account. In our mobile app we identify users by their personal accouns and provide a way to sign in / sign up and sign out directly in the app. So it’s possible to have a state when there’s no user id.

We used Block restores setting (btw, thanks for this update - it’s much simpler now!) and applied the recommended way of identifying users with login/logout mehtods as described here. 

However with this approach when we register a new user the RevenueCat creates a subscriber with anonymous Original App User ID and then aliases the actual user id and setups App User ID field with it.

While this is totally expected according to the documentation, it looks confusing in our flow where user can subscribe only with active account and thus already having actual identifier. What we’re trying to achieve is to always have users with single identifier (i.e. Original App User ID == App User ID) without aliases as we’re not going to support multiple accounts per subscription.

We tried to do this by using the old approach and call configure(withAPIKey:appUserID:) with user id when user logs in, and logout() when user logs out. And while it does what we want, it doesn’t seem entirely correct because we believe the configure method should be called only once on app launch. Besides of that the the logout method itself makes an additional network request to create a new anonymous user which seems redundant in our case. 

Is there a proper way to create a subscriber on RevenueCat with explicit user id but without using anonymous identifier before user authorizes in the app?

Is it possible to logout existing user without creating an anonymous user instead? 

 

Thank you in advance.

Great question! I’ll answer your question first (how to log in/out without aliases) and then add a few pointers for the rest of your post.

So the short answer is, it’s not possible to entirely avoid anonymous aliases with RevenueCat.

The long answer: Purchases can happen outside of an app before the user has even signed up or logged in - in other words, purchases can happen when users are anonymous to the app. Purchases originate from an Apple ID/Google account and are only connected to an app’s user after they sign up/log in, so apps need to account for the possibility of a purchase occurring before the user is properly identified. RevenueCat does this by creating an anonymous user ID on configure and logOut and aliasing them with the app user ID you provide after the user has logged in. You can find the aliasing rules in this guide on identifying users.

Some tips for working with app user IDs and aliases:

  1. configure should be called only once, as early as possible in your app’s lifecycle. That’s because configure contains a lot of initial setup that Apple strongly recommends to do as soon as the app launches. logIn basically does what configure does except with the possibility of aliasing an anonymous user to a non-anonymous user.
  2. Rather than focus on original app user ID, it’s better to take the whole set of original app user ID and aliases into account. The original app user ID roughly means “the first app user ID that was used” rather than “the real identity of the user.” For example, webhooks contain both the original app user ID and a list of all of the user’s aliases. You should always look through aliases when trying to match up the webhook notification to a user.
  3. RevenueCat now tries to limit the number of anonymous aliases when using logIn/logOut so you don’t have too many to sift through (usually, just one anonymous and one non-anonymous ID per user).
  4. If you collect emails as part of your sign up process, you can store them as subscriber attributes.This can make it easier to look users up in customer lists and identify users in webhook events.

Sorry for writing up a post that’s basically a no to your question, but I hope this helps clarify things!

 @sharif Thanks a lot for your quick response. It was helpful and clarified the correct approach for us.

Reply


Terms & ConditionsCookie settings