It’s a common issue that comes up on every single analytics platform - in one system you have 3105 active trials, on another, 5046. What’s the deal?
These discrepancies are common, and can happen for a variety of reasons. This article covers why you can expect certain discrepancies between RevenueCat's analytics and other platforms, and what you can do if things don't seem right.
Common Discrepancies
Having a better understanding of how RevenueCat collects data and generates analytics can help a lot when comparing against other platforms. The following are the most common things to consider the vast majority of discrepancies can be attributed to.
What is the source?
The first thing to ask yourself when comparing analytics systems is to ask yourself, "What is the source of this data?". If the sources are different, then you should expect differences in the data as well.
RevenueCat only collects data that is sent through our in-app SDKs or REST API - there's no connection to any other sources like App Store Connect or Google Play. This is especially important to remember for apps that had existing subscribers and migrated to RevenueCat. If a legacy subscriber never sends us their purchase data (or never updates their app to the "RevenueCat version") then we won't be able to track them in our analytics.
The data RevenueCat collects for analytics is the encrypted "receipt" file that's generated by the app stores. We decrypt these files, validate they are real, then normalize and store them in a usable format. Since these "receipt" files don't contain all of the information that's needed by developers, we have our own algorithms that estimate certain values, like prices.
Fortunately, with RevenueCat you can integrate the same source of data into all of your downstream systems so everyone across the company is looking at data from the same source. That doesn't mean there won't be differences (see Specific Platforms below) but it's a great way to close the gap.
Event based vs. Receipt based
Most analytics systems show data based on events generated by your apps. RevenueCat works slightly differently in that we fully unpack the receipts we receive, and rely less on events coming from the app.
What's the difference? Event based systems will change as new events are received. An example where differences might appear between the two is with refunds. Let's say on Jan 1st, two users each buy a product for $100. Then on Jan 5th one of those users gets refunded. An event based system might show $200 in revenue on Jan 1st and (-$100) in revenue on Jan 5th, where a snapshot based system would show $100 in revenue on Jan 1st and $0 on Jan 5th. The result in this case is still the same (+$100 for the week), but the numbers and charts on a day-to-day basis are different.
New apps vs. migrated apps
The most important thing to consider when investigating discrepancies depends on whether the first launch of your app was with RevenueCat, or you had an existing app that you migrated onto RevenueCat.
For new apps that launched with RevenueCat the data source should contain every purchase. However, if you have an existing app that was migrated onto the platform, the data source will still only contain purchases that were sent to RevenueCat via our SDK or REST API.
If you've migrated your app to RevenueCat and it appears that data is missing, here are some things to check:
- What's my upgrade cycle like? There's no way RevenueCat can collect purchases for old users until they've updated to the "RevenueCat version" of your app. This can vary a bit from app-to-app. For example iPads tend to have slower upgrade cycles than iPhones, so if you're a kids app with heavy iPad usage this could take longer. Another thing to note is the percentage of active users on your latest release is different than the percentage of active subscribers on your latest release. There will be some subscribers who have an active membership but may have deleted the app - these subscriptions still won't be tracked in RevenueCat until they're sent via our SDK or REST API.
- Am I sending RevenueCat purchase data for existing subscribers? When your existing subscribers do open the "RevenueCat version" of your app, check that you're sending their purchase history to RevenueCat. If not, it will still be captured automatically at their next renewal but that could be a long period of time especially for annual subscriptions. See our technical guide on migrating subscriptions for more info.
- Can I bulk migrate all my users? If you have been saving the raw receipt files yourself already, we can help you move them into RevenueCat. This is the best way to migrate users since it doesn't require an app update to start collecting data. Contact support@revenuecat.com and we can help you get set up.
Specific Platforms
App Store Connect and Google Play Billing
App Store Connect and Google Play are the ultimate source-of-truth because, well, they pay you! RevenueCat never actually connects directly into either of these systems, so the analytics are based off of different data sources and you should expect discrepancies.
The largest discrepancies will occur for apps that migrated to RevenueCat (See "New apps vs. migrated apps" above). Since the stores have data for every subscriber, and RevenueCat only has data for subscribers who have sent purchase data via the SDK or REST API, the stores will often report higher numbers that you see in RevenueCat.
The second largest discrepancy usually occurs with pricing information. As was mentioned earlier, per-user pricing information is not provided by the stores so it's estimated through our proprietary system. Things like currency conversions, taxes, and price changes will affect what RevenueCat estimates the price to be versus what the stores know the price paid was.
In addition to these (usually larger) reasons for discrepancies, there will always be some minute differences since each system works slightly differently. For example:
- RevenueCat uses a calendar month for reporting, Apple financial reports are based off of their fiscal months.
- Currency conversion in RevenueCat is done at the time of the transaction. The stores convert currency at they payout date (for Apple this is usually 33 days after the close of the fiscal month, but varies).
- The stores can batch payments (to not pay credit card fees for small transactions) so the date of collection is not always the date the transaction occurred. e.g. a transaction at the end of January may get batched with other transactions and "charged" in February.
- RevenueCat uses UTC as the base time, Apple reports in Pacific time.
- If you're in the Apple Small Business program, make sure you've entered the dates of enrollment into the RevenueCat dashboard (see guide for more info).
- Charts across App Store Connect, Google Play Console, and RevenueCat can have subtle differences that can result in significant discrepancies, when in reality each chart is simply showing different perspectives on the same data. For example RevenueCat considers a trial conversion to be a new purchase, while Google considers it as a renewal, which can cause discrepancies between the two dashboards.
Attribution Networks
While RevenueCat itself is not an attribution network, we can integrate the revenue data we collect for your app with networks such as Appsflyer and Adjust which can help you get a more accurate picture of the revenue each of your ad campaigns generates.
Below are the common issues we see across networks, as well as some specific issues we're aware of at the time of writing.
I've configured the integration in RevenueCat, but no events are being sent?
In order for RevenueCat to send events into attribution networks, if first needs to collect some user-specific data from within the app, such as the IDFA. If no events are being sent, it means we have not received this data. Double check our integration guides and your debug logs to make sure things are configured properly.
I'm seeing more purchases in RevenueCat than are being sent to the attribution network?
If you've recently configured the integration, the events won't be delivered until users update to the latest version of your app with the configuration. Similar to the dilemma with "New apps vs. migrated apps", we need to collect the in-app data from the user before we can trigger the integration. If the discrepancy between RevenueCat and the attribution network is getting closer-and-closer over time, it's most likely update related.
Other things that depend on the network may apply as well. How do they handle users with limit-ad-tracking? Do they guarantee on-device attribution or is there an error rate? Also see more network specific issues below and if they may apply.
Appsflyer
Appsflyer displays events based on user install date, not event date. This can sometimes lead to confusion when comparing Appsflyer to other systems. Also, Appsflyer will ignore events from re-installations of your app inside the attribution window unless they originate from a re-targeting campaign. See their guide for more information.
We've seen significant delays between when events are delivered to Facebook and when they become visible in the dashboard.
Facebook Analytics also does not show analytics events for users that have enabled limit ad tracking. In some apps 30%+ of users will have this setting enabled.
ChartMogul and App Annie
ChartMogul and App Annie both provide visualizations of the data available in the downloadable App Store Connect financial reports. Since this is a different data source than RevenueCat, you can expect discrepancies for similar reasons as comparing to App Store Connect directly. Specifically, missing data for migrated apps and pricing differences due to currency conversions, taxes, and missing prices.
Other Analytics
Some analytics platforms offer "automatic purchase tracking" that may show huge discrepancies with RevenueCat. This is most often due to the fact that these systems aren't set up to track subscriptions so miss things like free trials, conversions, and renewals. It's recommended to disable any "automatic purchase tracking" from these platforms and use a RevenueCat integration into the platform instead.
Takeaways
Every analytics system is different. It's usually more important to focus on a single analytics system you trust and look at trends over time than getting into the minutia of individual digits and differences. Understanding the data source for each system and the effects that app updates have on metrics can explain most discrepancies.
We're happy to help clarify anything and see how these discrepancies might pertain to your specific situation. We're unfortunately unable to determine causes for exact differences in numbers between non-RevenueCat systems since we don't have insight into their analytics methodology.
