Have a question?

Today, we are launching two big improvements. Continue reading for all the nitty gritty details, but let’s start with the big advantages you have with the new features: You can now share subscriptions not only between versions of the same app on different platforms (e.g., between iOS and Google Play Store), but also between different apps on the same platform. We now support the Amazon Appstore for your Android apps. For more information, see our documentation on installing the SDK and configuring Amazon Appstore products. To enable these changes, we’ve completely overhauled our model for how apps are created and set up. Logging into your RevenueCat dashboard, you will notice that the “Apps” dropdown menu has been replaced with “Projects”:A Project is a set of Apps. Each App is specific to one platform. For example, a typical Project might contain one iOS App and one Google Play Store App. All Apps within one project share the same basic setup, including entitlements, offerings, integrations, and webhooks. Apps within the same Project also share the same App User ID namespace, which means that they also share subscriptions. A user logged in to the same user ID in different Apps of the same Project will have access to the same entitlements. This allows sharing of subscription status between different Apps, even on the same platform. All of your existing apps have been converted to Projects. You will not need to make any changes in order to keep your RevenueCat setup functional. For example, an app that was set up for both iOS and Google Play will have been converted to a Project with an iOS App and a Google Play App.When checking out the new interface, you might notice that there are new, app-specific public API keys shown for each app. Please note that while your existing API keys are not shown in the interface anymore, they will continue to work. Newly created projects will only have app-specific public API keys.Here are some of the most important differences you may notice in the RevenueCat interface: Platform-specific configuration can now be found in the settings for the App of the platform, located under “Apps” in the left navigation (this includes StoreKit Testing, which used to have its own section in the left navigation and has been moved to the iOS App settings). References to “apps” have been replaced with “projects” everywhere, including in charts and customer lists. Public API keys are now app specific and can be accessed from the “API Keys” section in the left navigation. Restore behavior can now be configured in the Project’s General settings, accessible from the left navigation. The “integrations” section of the left navigation was cleaned up to only show configured integrations. New integrations can be configured through the “+ New” button. Our documentation has been updated to reflect the modified interface.

There are currently 6 engineers dedicated to supporting you, and keeping our community and documentation up-to-date. Since you’ll be seeing a lot of us around here we wanted to take some time to introduce ourselves! @ryanHowdy y'all! Ryan here, I'm on our developer experience team here at RevenueCat, writing in from my home base in San Diego, California (Cardiff-by-the-sea to be exact). I'm really excited to be a part of the RevenueCat Community. Most of my engineering background has been on the iOS side, but I've worked on a few server projects as a backend for mobile apps. I'm looking forward to learning from everyone here, and hoping to share as much knowledge as I can as well.When I'm not building things on computers, I like building physical (e.g. real world) things - it's a great creative outlet that helps me balance screen time. My favorite projects are building custom surfboards. It's so satisfying to be out in nature riding waves on something that you made by hand.Thanks for reading! I look forward to meeting all of you and growing a community where everyone can share and learn from each other. @sharif😺 I’m Sharif, a RevenueCat developer support engineer📍 New Jersey (shout-out to all the Rutgers fans)📱 I’m a hobby app developer (🍎🤖 🪟 🌎)🔍 Exploring new places is one of my favorite hobbies🐦 I spend too much time on Twitter (Say hi @msm697)🍕 ’nuff saidExcited to meet you all in the community! @codyI'm Cody, one of the developer support engineers here at RevenueCat. Like the rest of the RevenueCat team, I work remotely -- I was born/raised and currently live in Ohio, so I'm active during normal-ish EST work hours.I was an indie iOS developer for nearly a decade before joining the team, and I love all things Apple. It's known by many that my favorite week of the year is WWDC (yes, I install the iOS/iPadOS betas on my main devices 😱). I have endless side projects I'm regularly working on, and I hope to actually finish one some day 😅A bit more about me: my wife and I live on a few acres here in Ohio (surrounded by corn fields, of course), which gives plenty of room for our pup to run around. I like spending time outside, when it’s not too hot and my allergies allow it 🤧Thanks for stopping in to meet me- I hope to see you around! @tinaHi! I’m Tina, a Developer Support Engineer based out of Orange County, California. 🍊 I first learned iOS development at the University of California, Berkeley (go 🐻s!) and joined the RevenueCat team after graduating.Some things I enjoy:👩‍🍳 Cooking and trying new recipes🙌 DIY projects, ranging from room improvements to building mechanical keyboards🍿 Finding new shows on Netflix and HuluI also love meeting new people. Happy to help and looking forward to learning from you as well. See you around the community! 👋 @jazmineHi I’m Jazmine! I’m a developer support engineer here at RevenueCat. I’m based out of Redmond, Washington.When I’m not at my computer you can find me at the gym or exploring the beautiful PNW with my two puppies ( French bulldog and a Beagle).Excited to get to meet all of you and grow our community!

If you're still testing in sandbox, it's most likely a configuration issue that's preventing the products from being retrieved from Apple/Google. Your product identifiers are set in RevenueCat, but the actual products that your users purchase can only be retrieved directly from Apple/Google. Because this communication happens between your app and the stores, RevenueCat doesn't have any visibility into the API requests, however there are some common requirements to go through.iOS and AndroidThe product identifier set in RevenueCat matches exactly with the store You're testing on a physical device and not a simulator The bundle ID in Xcode [iOS] or package name [Android] match what's in App Store Connect or Google Play If you have both development and production environments for your app, be sure to double check you are using the correct bundle IDs [iOS] or package names [Android].iOS OnlyProducts are in the in the 'Ready To Submit' state All of the products are in the Ready to Submit state - great!  You've signed your 'Paid Applications Agreement'   In this screenshot the Paid Applications Agreement needs to be signed.   If you're trying to fetch products from the App Store, ensure you're not using a StoreKit Configuration file  Changing the reference name in App Store Connect can also cause products to not fetch on iOS. Create a new product with a different identifier, fill out any missing metadata, and attempt to fetch products again.Android OnlyThe subscription product is in the Active state. Follow our guide on setting up Android products to make sure your products are set up correctly. This product needs to be activated before it can be tested in RevenueCat.The subscription is now active.  Your app is published on a closed track and you've added a tester  Live Apps (public on the App Store/Play Store)If your app is live and everything was working during testing, you should check that:All products are in the 'Approved' state in App Store Connect [iOS] Products have been approved for 24hrs+. Due to store propagation time, it can take 24hrs+ for new products to become available after being approved - this is the same for new apps and adding new products to existing apps.App ReviewIf your products fetch fine in Sandbox and Testflight, but App Store Review is unable to fetch products, ensure that you are submitting your in-app purchases with your app for review. More details in our App Store rejections documentation.The App Review environment is notoriously flaky and can cause issues when the reviewer tests in-app purchases. Submitting a video to Apple of the in-app purchase flow working in Testflight could help with App Review.For more information on rejections, view our post on App Rejections: If you’re still stuck…If you’ve gone through all of the steps above, and you’re still stuck, you can look through the ‘Empty Products’ tag in the community to see how other developers have resolved the problem: https://community.revenuecat.com/search?q=Empty+Products&search_type=tag.If we ever learn new reasons for this issue we’ll be sure to update the post here.

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 basedMost 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 appsThe 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 PlatformsApp Store Connect and Google Play BillingApp 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 NetworksWhile 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. AppsflyerAppsflyer 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. FacebookWe'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 AnnieChartMogul 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 AnalyticsSome 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. TakeawaysEvery 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.