App user id detection methods #560
Conversation
|
Preview this PR here: https://dev-docs.revenuecat.com/pr-560/ |
docs/platform-resources/server-notifications/google-server-notifications.md
Outdated
Show resolved
Hide resolved
| To ensure smooth functionality: | ||
| 1. Confirm that you **are not** using the "Keep with original App User ID" or "Transfer if there are no active subscriptions" setting in combination with this feature, **or** | ||
| 2. Check that you **are not** setting `appAccountToken` or `obfuscatedExternalAccountId` fields, **or** | ||
| 3. Verify that any `appAccountToken` or `obfuscatedExternalAccountId` set for your customers will match their [RevenueCat App User ID](/customers/user-ids#logging-in-with-a-custom-app-user-id) **and** the app user ID is a valid UUID (RFC 4122 version 4). | ||
| 3. If you are [using RevenueCat without our SDK](/migrating-to-revenuecat/sdk-or-not/sdk-less-integration), verify that any `appAccountToken` or `obfuscatedExternalAccountId` set for your customers will match their [RevenueCat App User ID](/customers/user-ids#logging-in-with-a-custom-app-user-id) **and** the app user ID is a valid UUID (RFC 4122 version 4). | ||
|
|
||
| **For Google Cloud Pub/Sub:** | ||
| If you select the "Use anonymous App User ID" App User ID detection method, there are no conflicts or issues with any restore behavior. |
There was a problem hiding this comment.
I really don't like this section and how complicated it can get now with the new app user ID detection method we're trying to introduce. Going to think this through some more and perhaps just make a diagram
| To ensure smooth functionality: | ||
| To ensure smooth functionality, please refer to the diagram below before proceeding: | ||
|
|
||
|  |
There was a problem hiding this comment.
TODO: add additional info about legacy restore behaviors - https://revenuecat.slack.com/archives/C06PN87TRU0/p1734541427817289
There was a problem hiding this comment.
Updated it - if this all looks correct
There was a problem hiding this comment.
I am not sure if we should say "You can proceed with enabling this feature" for lagacy behavior here.
AppUserID conflict could actually block purchases and a manual restore would be required to fix the issue in these cases. I would consider this broken behavior for the subscribers. Would it make sense to follow the same flow like "Keep with original App User ID" and "Transfer id there are no active subscriptions" for legacy behavior too?
There was a problem hiding this comment.
Thinking more about this today. I guess the real issue here with the legacy behavior is only if the customer also has the allowSharingAppStoreAccount setting set to false as well right? In that case, if we process the S2S notification first with an app user ID that doesn't match the SDK's, then we'll throw an error that the receipt belongs to another subscriber. But if they have it set to true, wouldn't those two app user IDs alias instead for the same steps?
Motivation / Description
Slack convo
Figjam diagram - app user ID detection method
Figjam diagram - restore behavior
Changes introduced
Linear ticket (if any)
Additional comments