Inaccurate Install and Active Users displayed on Dashboard

Badge +3

The total installs and active users displayed on my RevenueCat dashboard overview are way off. I believe it’s at least double the amount of installs, and I would guess the active users count is also around double.

It’s been like this for almost a year now, I just haven’t decided to report this until now.

Is RevenueCat counting anonymous ids as a user as well? I’ve checked in my code and I'm positive that I'm just identifying the user once when authenticating.

Am I the only one experiencing this?


Current SDK:

react-native-purchases – 3.2.0


Best answer by sundeep 1 September 2021, 03:23

View original

10 replies

Badge +4

I have been experiencing a similar issue over the last year. Have not reported it because I have been using apple as the “source of truth” for installs, but it would be great if this would be fixed.

Badge +3

Yeah it would be useful to have fixed. Essentially the trial start rate chart is basically useless for those effected. 

Userlevel 3
Badge +8

Hi @Calvin Cheng!

When we say installs, we're referring to the number of unique App User IDs that have been generated for the app. So the way you set up your identity logic can impact this. If you're seeing a dramatic discrepancy, you may want to double check that (i.e. are you calling reset() excessively? That can produce a new anonymous ID, which counts as an install)

Is RevenueCat counting anonymous ids as a user as well?

Yes, anonymous IDs will count separately toward the installs until they’re aliased with a provided ID.

In general, a new App User ID can be generated through Purchases initialization or through reset(). If Purchases is initialized multiple times, that could mess with install count. It's also possible users are simply deleting and reinstalling the app often, which generates a new anonymous ID.

Badge +3

We are in the same boat - install count is not reliable. We have spent time investigating the SDK setup and we can’t find any issue. It’s not massively out, but 10-20%. We have to ignore the number and use AppsFlyer’s count.

Can RevenueCat support help me to understand if there are any known differences in the way RevenueCat vs. AppsFlyer would count an install that would lead to a 10-20% different in the count, assuming both SDK’s are installed/setup correctly?

Thank you.

Userlevel 3
Badge +8

Hi @John J,

The main difference is that RevenueCat tracks unique App User IDs as installs, just as I stated in my post above. Anonymous IDs will also count as separate installs until they are aliased (which happens when they restore transactions or make purchases, and if they don’t do that, they are never aliased). New anonymous IDs can be generated by deleting and re-installing the app, or when a user logs out. So these situations might lead to a larger number of installs in RevenueCat than AppsFlyer.


AppsFlyer actually has a document that goes over their data discrepancies that might be useful to look at: At the bottom of the table, you can see that AppsFlyer has a reattribution window where users who delete the app and re-install within 3 months (default window) would still be considered the same user. With RevenueCat, when a user deletes and re-installs a new anonymous ID is created so this might also contribute to a larger number of installs in RevenueCat than AppsFlyer.

If you’re curious about any other data discrepancies, we have a good article on it here on the community: 



Badge +3

I am definitely not calling reset() excessively, as I’m only calling it explicitly on logout. BUT, I think I might have found the issue, but would like to confirm.

So I instantiate the SDK on launch every single time with setup() only providing the SDK key but never with the optional user id parameter. I then call identify() later on. My guess is that the setup call is generating a new anonymous ID each time the app is launched.

@sundeep do you think this could be the reason I’m observing this behaviour?

If this is, I believe it would make sense if the SDK would cache the user ID in this case, seeing as I believe this is quite standard behaviour from other SDKs.

Userlevel 3
Badge +8

@Calvin Cheng the SDK does cache the anonymous ID, you can see this mentioned in our Identifying Users doc if you’re curious (it also goes over how IDs will be merged/aliased if you want to read about that): 

A new anonymous ID won’t be generated with every launch by that anonymous user - only if they delete and reinstall the app. So additional counts could happen like that occasionally. If the user logs in on different devices anonymously and never logs in, or never restores or makes purchases such that the IDs would be merged together, that could also count separately toward your installs. A new anonymous ID is generated when a user logs out as well (though this is also cached) so that’s something to keep in mind.

Badge +1

@sundeep I observed a related issue, but I think it’s a bit different:

The number of new customers and active users tripled (!) overnight. This seems incorrect.

What’s odd: If I go to Customers to view a list of all customers I can see what I believe is the correct number on top.

Why does the dashboard show 3x as many customers/users as the customer list? Keeping in mind that the dashboard shows only the customers of the last 28 days while the customer list is supposed to show all. 

Thank you!


Userlevel 3
Badge +8

Hi @dom, thanks for reaching out. The tripling you saw was likely due to an incident we had but have since fixed, you can read more about it on our status page: 

You should now see correct metrics in the overview page, but let me know if you’re still experiencing any discrepancies.

Badge +1

Thanks for the quick reply, @sundeep! Metrics are back to normal!