Debugging Integrations

  • 1 July 2021
  • 0 replies

Userlevel 3
Badge +7

When integrations aren't working as expected, debugging can be challenging. This guide is designed to walk you through the steps you should take to identify what could be going wrong, and steps you can take to resolve any issues.


Identifying the issue

When debugging integrations, we usually hear about three categories of issues:

  1. No events are being sent from RevenueCat into third-party
  2. Only some events are being sent from RevenueCat into third-party
  3. All events appear to be sent, but the data in third-party does not match RevenueCat

We'll dig into each of these categories further in the sections below.


Check that events are being sent

The first thing to check is if any events are being sent from RevenueCat into the third-party. This is easy to check in the RevenueCat dashboard under the integration settings for your app.

Below every integration configuration, you'll see a table of Recent Events (example below).  

(Tip: click on any event in the table to see the payload that was delivered)

If you don't see any recent events, it means nothing has been delivered. There are three things that could cause this:

  1. The integration is not configured properly in the RevenueCat dashboard. Make sure that you've filled out all of the required fields for the integration (e.g. any API keys and event names).
  2. The integration requires device data but none has been sent. Check in the RevenueCat documentation and confirm if the integration requires any device data, such as a specific third-party identifier. If this data has not been sent to RevenueCat, no integration event can be dispatched. The following section goes into further detail on debugging this scenario.
  3. No purchases or renewals have occurred since the integration was set up. If you just set up the integration, make sure a purchase or renewal has come through that would have generated an event.


Check that events are being sent

An often trickier problem is if "some" events are being dispatched, but not all of them. The best way to begin debugging is to locate an individual event and/or user where the integration did not complete as expected.

Since RevenueCat Support does not have access to the third-party system, we're unable to compare events dispatched vs. events received and isolate "missing" events.

Once you're able to locate an individual event (or a handful), use the flow chart below to help understand what may be going on and the steps to resolve.

Start at the top of the flow chart and work your way down, following the instructions at each block.

Some apps run a different code path on app launch for new users versus signed-in users. This could be a good initial place to investigate, or at least keep this in mind as you run through the diagram below. For example, we've seen scenarios where developers had only attached the required device data for new users signing up, and not already signed in users, or vice-versa. 


Data in RevenueCat doesn't match third-party

Significant data discrepancies are usually the result of apps migrating to RevenueCat and all subscribers haven't been synced yet. It is extremely difficult for RevenueCat to know why all data discrepancies occur, since we're not experts in every system we can only be sure about what is going on inside of RevenueCat.

We've put together an article on data discrepancies that summarizes most of what we know, and is definitely worth a read:

RevenueCat Support is unable to answer questions such as "Why does System A report X but System B reports Y?" - simply because we don't know how every system operates. The best way to start understanding the source of the discrepancy is to narrow it down to an individual user/event and go through the flow chart above. 


Common Issues

App update effects

If you've recently updated your app to include a new RevenueCat integration that requires device data, it can take some time for active subscribers to update to the latest version of your app, and RevenueCat won't be able to send events for those users until the device data has been received.

A good thing to check is if the number trial starts and/or initial purchases are inline with what you expect. Since most users starting trials and/or buying for the first time will be on the latest version of your app, any app update effects will be mitigated for these events.

Note that active users are not the same as active subscribers. Even if most active users are on the latest version of your app, a subscriber could have deleted the app but kept their subscription active - they may never open the app again but remain "active".

Facebook integration and "limit ad tracking"

If you're using the Facebook integration, note that events for users with "limit ad tracking" enabled will not appear in Facebook Analytics unless the `fbAnonId` attribute is attached to the user in RevenueCat.

Appsflyer "app id" prefix

If you've configured an Appsflyer integration, make sure the "iOS app id" field in the RevenueCat dashboard contains the complete app id including the "id" prefix.

The iOS app id includes the “id” prefix so it’s in the correct format.

Entering a wrong or incomplete app id will result in the events silently failing on Appsflyer servers.

This post has been closed for comments