Skip to main content

Attribution Troubleshooting

Troubleshoot RevenueCat attribution provider integrations by symptom

AIAsk AIChatGPTClaude

Use this page when RevenueCat attribution-provider events don't appear, are rejected, or appear in the provider but don't attribute or report as expected.

RevenueCat delivery and provider-side attribution are separate steps. A successful delivery means the provider endpoint accepted the event from RevenueCat. The provider still decides whether that event can be matched to a user, attributed to a campaign, used for optimization, or included in a specific report.

Symptoms​

No provider delivery row appears in RevenueCat​

If a purchase or lifecycle event has no delivery row for the provider in Customer History, RevenueCat didn't attempt to send that event to the provider.

Causes in this section:

Cause: Required identifiers or attributes were missing when the event was processed​

RevenueCat only sends provider events when the required identifiers, device attributes, or attribution data are present at processing time. If attributes are set after the purchase, future events can use them, but the earlier event may not be sent.

Solution:

  • Check the customer's Customer Profile for the provider's required attributes before the purchase event.
  • If the attributes were missing, configure the RevenueCat SDK first, then collect and set provider identifiers before the first purchase whenever possible.
  • If the provider SDK exposes its identifier asynchronously, set the RevenueCat attribute when the identifier becomes available.
  • Adjust exposes the ADID asynchronously, so it may not be available before the first purchase. Set $adjustId in RevenueCat when the ADID becomes available.
  • If $adjustId was missing when RevenueCat processed the event, RevenueCat doesn't create an Adjust delivery attempt for that event. Setting $adjustId later doesn't reprocess the past event.
  • Adjust SDK v5 removed adid from ADJAttribution on iOS and AdjustAttribution on Android. Fetch the ADID from the Adjust SDK instead.

Cause: The integration or credentials aren't configured for this environment​

RevenueCat needs the provider integration enabled for the correct project and credentials for the environment being tested. Sandbox purchases often require separate sandbox credentials.

Solution:

  • Confirm the provider integration is enabled for the correct RevenueCat project.
  • Check production and sandbox credentials, app tokens, event tokens, API keys, dataset IDs, or other required provider settings.
  • If the provider requires separate sandbox authentication, configure sandbox values before testing sandbox purchases.
  • For Conversions API, confirm the Dataset ID and Conversions API Token come from the Meta dataset you want RevenueCat to send events into.
  • CAPI can support iOS App Events datasets and isn't limited to web Pixels. The dataset ID doesn't need to match the Meta App ID, but the dataset must be linked to the app and accessible from the correct Meta business portfolio.
  • Sandbox purchases require sandbox credentials in RevenueCat: a Sandbox Dataset ID and Sandbox Conversions API Token for CAPI, or a Sandbox App ID and Sandbox Client Token for App Events API.

Cause: The event type isn't supported or enabled​

RevenueCat may send some provider events while skipping others if the provider doesn't support that lifecycle event, or if the event is optional and not configured.

Solution:

  • Confirm the provider supports the RevenueCat event type you expected to send.
  • If the event is optional, configure it in RevenueCat before testing that event type.
  • Adjust uses provider-issued event tokens, not readable event names. For each platform section in RevenueCat, copy the token from the matching Adjust app and event.
  • Don't reuse a token across different RevenueCat lifecycle events unless you intentionally want Adjust to report them as the same event.

RevenueCat shows delivery, but provider attribution or reporting is wrong​

A Sent, 200, or successful delivery state means RevenueCat delivered the event to the provider. It doesn't guarantee that the provider attributed the event to a campaign, improved match quality, counted it in Ads Manager, or aligned ROAS with RevenueCat dashboards.

Causes in this section:

Cause: Delivery succeeded, but the provider couldn't match or attribute the event​

The provider owns attribution and matching. If the event doesn't include enough identifiers, arrives outside a provider attribution window, or isn't eligible for a campaign, dataset, app, or optimization configuration, it may be accepted but still appear as Organic, Unattributed, or missing from a specific report.

Solution:

  • Check the identifiers RevenueCat sent to the provider, then compare them to the provider's matching requirements.
  • Review the provider's campaign, dataset, app, event, and optimization configuration.
  • Check attribution windows and other provider-side eligibility requirements.
  • When available and privacy-compliant, set additional matching attributes to improve the provider's ability to match events to users or campaigns.
  • Meta owns campaign attribution, Event Match Quality, Ads Manager optimization, SKAdNetwork, and Aggregated Event Measurement readiness.
  • RevenueCat's Conversions API integration is limited to values that are on the RevenueCat customer profile and mapped into Meta's payload. The Meta SDK may provide richer on-device context for app-open events, while RevenueCat can send subscription events that occur when the app isn't open.
  • Set $fbAnonId, collect device identifiers, and set additional matching attributes like $email or $phoneNumber before the purchase event when privacy rules allow it.
  • For iOS campaigns, CAPI delivery doesn't update SKAdNetwork conversion values or configure Aggregated Event Measurement. Complete those steps in Meta, Apple, your app, or an MMP.

Cause: Attribution fields were set from fallback or placeholder values​

RevenueCat stores reserved attribution attributes as write-once values. If your app sets a fallback or placeholder value like Organic, Unknown, or No User Consent before the final provider attribution value is available, RevenueCat can't replace that value later for the same customer.

Solution:

  • Check the customer's Customer Profile for reserved attribution attributes such as $mediaSource, $campaign, $adGroup, or $creative.
  • If a fallback or placeholder value is already stored, test with a new customer after updating your app to set only final attribution values.
  • Set attribution fields only after your app has final values from the provider SDK, attribution callback, or another attribution source.

Cause: The provider report is delayed or filtered differently​

Provider dashboards often have their own processing delays, date bases, attribution filters, cost data, and report defaults. A successful RevenueCat delivery can appear before the provider dashboard has finished processing the event.

Solution:

  • Wait for the provider's expected reporting delay before comparing dashboards: some providers process event reporting within hours, while attribution data for newly configured campaigns can take several days.
  • When comparing ROAS, make sure provider cost data, report filters, attribution windows, and date ranges match the comparison you are making in RevenueCat.
  • AppsFlyer reports in-app events by install date.
  • If you compare RevenueCat event dates with an AppsFlyer install-date report, delivered events can look missing from the selected date range.

Cause: Revenue basis differs between RevenueCat and the provider​

RevenueCat's Sales Reporting setting controls whether RevenueCat sends gross revenue or revenue after commission and/or estimated taxes. If the provider report uses a different revenue basis, ROAS and revenue totals can differ even when all events were delivered.

Solution:

  • Use the same gross or post-commission/tax basis in RevenueCat and in the financial report where the provider data will be used.

The provider rejects events​

Provider rejection messages usually come from the provider endpoint. The event was attempted, but the provider didn't accept it.

Causes in this section:

Cause: Provider authentication is incomplete or mismatched​

Some providers require additional authentication for server-to-server events. This can be separate from the SDK keys or app identifiers used in your app.

Solution:

  1. Check the provider error text in RevenueCat Customer History or integration delivery details.
  2. Compare the error to the provider's API documentation and the provider setup page.
  3. If the error points to authentication, confirm that all required server-to-server credentials are configured in RevenueCat.

  • If the Adjust delivery response says Missing authentication token, RevenueCat sent the event without an OAuth token, but Adjust requires one for authenticated S2S event requests.

  • Configure the matching OAuth token in RevenueCat.

  • Example error:

    {"error":"Event request failed (missing authentication token)"}

Cause: The provider rejected malformed or ineligible event data​

Providers may reject malformed identifiers, invalid device data, unsupported event properties, or events that don't meet API requirements.

Solution:

  • Confirm the required identifiers and credentials are valid before retrying.
  • If the provider error names a specific field, fix that field first before testing with a new event.

Provider revenue appears duplicated or too high​

Duplicated revenue usually means the provider counted more than one event for the same purchase or subscription lifecycle event.

Cause: RevenueCat and the provider SDK both sent the same revenue event​

RevenueCat sends purchase and subscription events to most attribution providers server-to-server. If the provider SDK also tracks purchase or revenue events in your app, the provider may count both copies.

Solution:

  • Turn off duplicate provider SDK purchase or revenue tracking, or intentionally configure deduplication in the provider.
  • In most setups, let RevenueCat send subscription purchase, renewal, and trial conversion revenue, while the provider SDK continues sending non-revenue install, activation, and usage events when needed.

Provider revenue appears missing or too low​

Lower-than-expected revenue can come from event coverage, provider support, or revenue values rather than delivery failure.

Causes in this section:

Cause: The provider or integration doesn't support the event or revenue value​

Some integrations don't send every RevenueCat lifecycle event by default. Some providers also don't support negative revenue, zero-revenue events, or very small revenue values.

Solution:

  • Confirm the event type is supported by the provider integration.
  • Configure optional event types for every optional event you want to send.
  • Check whether RevenueCat omitted revenue for free trials, zero-revenue events, refunds, negative revenue, or values below the provider's minimum supported revenue amount.
  • Adjust doesn't accept events with revenue less than 0.001, so free trial events are sent without a revenue property.
  • RevenueCat's Adjust integration doesn't support negative revenue, so refund events are sent without a revenue property.

Cause: Revenue is being compared on different bases​

If RevenueCat sends post-commission/tax revenue but the provider report expects gross revenue, provider revenue may look lower than RevenueCat dashboards.

Solution:

  • Use the same gross or post-commission/tax basis in RevenueCat and in the financial report where the provider data will be used.

Historical or backfilled events behave differently​

Historical imports, migrations, and replayed events can behave differently from live events.

Cause: Providers apply timestamp, ordering, or attribution-window rules​

Providers may validate event timestamps, reject out-of-order events, or apply different attribution windows to historical events.

Solution:

  • Confirm whether the provider accepts historical timestamps for the event types you plan to send.
  • Test a small representative batch before sending a full backfill.
  • Compare provider warnings with RevenueCat delivery results.
  • Meta's Conversions API may reject events whose event_time is more than seven days old.
  • Meta may still reject retried or replayed events after a configuration fix if the original event_time is outside Meta's acceptance window, so prioritize validating and fixing your Meta configuration early.
Was this page helpful?