Getting Started with Attribution Integrations
Prepare your app, dashboard configuration, and tests for attribution provider integrations
Use this guide before enabling an attribution provider integration or testing a new app version. It explains how attribution integrations fit together, which setup choices affect reporting, and why testing should use fresh customer data. Use the setup checklist as a companion reference while you configure and test.
Understand the common setup path
Most attribution providers rely on event forwarding: RevenueCat sends subscription lifecycle and revenue events to the provider after your app sends RevenueCat the identifiers that provider needs for matching. In most cases, event-forwarding setup has four parts:
- Provider SDK setup gives your app access to the provider identifiers or attribution data RevenueCat needs.
- Connecting your app to RevenueCat stores those identifiers or attribution values on the RevenueCat customer.
- Provider communication tells RevenueCat which events to send and how to authenticate with the provider.
- Testing before comparing dashboards confirms the app-side data and dashboard configuration were both present before the test purchase.
Apple Search Ads is the main exception. RevenueCat collects Apple attribution data so you can segment Charts by Apple Search Ads campaign fields and forward Apple Search Ads context to supported downstream integrations. If you use Asapty or SplitMetrics Acquire, configure Apple Search Ads attribution collection before enabling them.
Connect your app to RevenueCat
The app-side work gives RevenueCat the data it needs before a purchase event happens. For many providers, this means the RevenueCat SDK is configured first, then your app calls collectDeviceIdentifiers() and the provider-specific setter documented on that provider page.
Timing matters because RevenueCat can only include the identifiers and attribution data it already has when it processes a purchase event. Required customer attributes should be present before the first purchase whenever possible. Some identifiers can also become available later, such as after prompting for tracking permission, so the app may need to collect them again.
If your app sends attribution fields to RevenueCat, only set final values. RevenueCat stores reserved attribution attributes as write-once values, so fallback or placeholder values like Organic, Unknown, or No User Consent can prevent the final attribution value from being stored later.
Configure provider communication
The dashboard setup tells RevenueCat which events to send and how to authenticate with the provider. These settings are project-specific, and some providers use different credentials, app tokens, event tokens, or sandbox authentication for different environments.
Many event-forwarding providers receive a core subscription lifecycle set from RevenueCat. Provider setup pages explain how each event is represented for that provider: it may be mapped automatically, sent with a configurable event name, or sent with a provider-issued event token. For the shared event definitions, see the setup checklist.
This is also where you choose settings that affect downstream reporting. Sales Reporting mode changes whether RevenueCat sends gross revenue or revenue after commission and/or estimated taxes, so it should match the financial reports where provider data will be used. Duplicate counting can happen if the provider SDK tracks the same purchase or revenue events that RevenueCat sends server-to-server, unless those duplicate SDK events are turned off or intentionally deduplicated.
Test before comparing dashboards
A useful integration test starts with a new customer after the SDK, customer attributes, and RevenueCat integration settings are configured. A purchase that happened before identifiers or attribution data reached RevenueCat usually can't prove the integration is set up correctly.
RevenueCat-side validation focuses on whether the required attributes are present in the Customer Profile and whether the purchase event in Customer History has the expected provider delivery row. Provider-side validation depends on the provider's sandbox, debug, or reporting tools.
Provider dashboards often process data on their own schedule. For example, Meta Events Manager may take up to 24 hours, and Apple Search Ads attribution data can take up to 7 days for new campaigns or newly configured integrations. See the provider comparison for requirements like sandbox authentication.