--- id: "integrations/attribution/getting-started" title: "Getting Started with Attribution Integrations" description: "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." permalink: "/docs/integrations/attribution/getting-started" slug: "getting-started" version: "current" original_source: "docs/integrations/attribution/getting-started.mdx" --- > **AI agents:** This is the Markdown version of a RevenueCat documentation page. For the complete documentation index, see [llms.txt](https://www.revenuecat.com/docs/llms.txt). 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](https://www.revenuecat.com/docs/integrations/attribution/setup-checklist) as a companion reference while you configure and test. ## Understand the common setup path Most attribution integrations rely on event forwarding: RevenueCat sends subscription lifecycle and revenue events to the provider after your app sends RevenueCat the identifiers or attribution values that provider needs for matching. In most cases, event-forwarding setup has four parts: 1. Provider SDK setup gives your app access to the provider identifiers or attribution data RevenueCat needs. 2. [Connecting your app to RevenueCat](#connect-your-app-to-revenuecat) stores those identifiers or attribution values on the RevenueCat customer. 3. [Provider communication](#configure-provider-communication) tells RevenueCat which events to send and how to authenticate with the provider. 4. [Testing before comparing dashboards](#test-before-comparing-dashboards) confirms the app-side data and dashboard configuration were both present before the test purchase. The provider's role can differ. A mobile measurement partner (MMP) is an independent attribution system that determines acquisition source and campaign attribution across multiple ad networks. An MMP may expose final attribution values to your app through its SDK, attribution callback, deep link, or another attribution path. Your app can pass those final values to RevenueCat using reserved attribution attributes such as `$mediaSource` and `$campaign`. RevenueCat stores these values for reporting and can include in downstream event forwarding. Other integrations may be ad platforms or reporting tools that receive events and apply their own matching, eligibility, or reporting rules without acting as the cross-network attribution source. [Apple Search Ads](https://www.revenuecat.com/docs/integrations/attribution/apple-search-ads) is the main exception to event-forwarding setup. 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. Some providers also rely on separate app-side or platform-side measurement paths. RevenueCat's server-side event forwarding can send subscription lifecycle and revenue events, but it doesn't replace every signal the provider SDK, ad platform, app store, MMP, or privacy-preserving attribution system may need for install attribution, campaign optimization, or aggregated reporting. Provider setup pages call out these extra requirements when they apply. ## 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. Consent, privacy settings, and platform rules can change which identifiers or attribution values are available to your app. If a value becomes available later, such as after tracking permission is granted, collect it again when the provider page instructs you to. Even when RevenueCat delivers an event successfully, the provider may still apply privacy thresholds, aggregation rules, attribution windows, or campaign eligibility checks before showing it in reports. 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](https://www.revenuecat.com/docs/integrations/attribution/setup-checklist#configure-provider-communication). 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](https://www.revenuecat.com/docs/dashboard-and-metrics/customer-profile#customer-details) and whether the purchase event in [Customer History](https://www.revenuecat.com/docs/dashboard-and-metrics/customer-profile#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](https://www.revenuecat.com/docs/integrations/attribution/provider-comparison) for requirements like sandbox authentication.