Solved

Diffrent original_app_user_id for one customer

  • 27 July 2021
  • 1 reply
  • 316 views
A
Badge +4

One of our customers make subscriptions and we receive this webhook:

{  "api_version": "1.0",  "event": {    "aliases": [      "$RCAnonymousID:***b501b80f91"    ],    "app_id": "app1bd0ad1cf1",    "app_user_id": "$RCAnonymousID:***b501b80f91",    "environment": "PRODUCTION",    "event_timestamp_ms": 1627351153536,    "original_app_user_id": "$RCAnonymousID:***b501b80f91",    "type": "INITIAL_PURCHASE"  }}

 

After one hour customer change product and we receive this webhook:

{  "api_version": "1.0",  "event": {    "aliases": [      "$RCAnonymousID:***b501b80f91",      "$RCAnonymousID:***776c3a98f0"    ],    "app_id": "app1bd0ad1cf1",    "app_user_id": "$RCAnonymousID:***776c3a98f0",    "environment": "PRODUCTION",    "event_timestamp_ms": 1627351457649,    "original_app_user_id": "$RCAnonymousID:***776c3a98f0",    "type": "PRODUCT_CHANGE"  }}

 

Why after product change RevenueCAT change “original_app_user_id” from ***b501b80f91 to ***776c3a98f0 and RevenueCAT ID ***b501b80f91 going from “original_app_user_id” to “aliases”? 

How do we understand that this is one user, we search for a user by “original_app_user_id”, so for us it's like two different users. Never encountered this before, “original_app_user_id” was always the first, assigned to the user, no matter how the aliases changes

icon

Best answer by cody 27 July 2021, 22:38

View original

1 reply

cody
Rank
Userlevel 6
Badge +8

Hey @Andrei!

It’s important to note that original_app_user_id isn’t guaranteed to be the exact same for a user in all cases- these IDs can be changed if different user IDs are merged together. In the event that two users are merged together, the ‘new’ original app user ID is the oldest between the two.

In this case, from the dashboard you can see that an alias occurred at almost the same time as a purchase- so it’s possible the original app user ID isn’t the ID you expected to see. As you can see from the product renewal event, you now have access to *both* user IDs in the ‘aliases’ field, so you can link it back to the correct user. If you’re keeping subscription status in sync from your server you should make sure you’re considering all of their aliases, and not necessarily relying on the original_app_user_id field.

You can also just ping our GET /subscribers endpoint with either of those aliases to get a snapshot of their current subscription status, too.

Does that make sense?

 

 

Reply


Terms & ConditionsCookie settings