October 7, 2026

7 Mobile Subscription Attribution Tools, Compared by Stack Role

Compare Airbridge and subscription event sources by setup, mappings, and validation checks, then choose a documented campaign-reporting route.

Shortlist the subscription event source and the campaign attribution provider separately.

• RevenueCat sends subscription events into an attribution setup; Airbridge documents mappings for trials, purchases, renewals, and cancellations.
• Airbridge Core names RevenueCat, Adapty, and Superwall among up to two third-party integrations.
• AppsFlyer, Adjust, Branch, and Singular each document ways to handle subscription or purchase events, with different setup paths.
• Apple App Store Server Notifications can supply subscription-status events for auto-renewable subscriptions.

If paid acquisition costs money before it produces a paid subscriber, a clean install count only answers part of the question. Your stack needs a subscription event source that can report what happened after install, plus a campaign attribution provider that can connect those events to acquisition reporting. For a small app team, the practical shortlist includes RevenueCat and Apple App Store Server Notifications as event routes, and Airbridge, AppsFlyer, Adjust, Branch, and Singular as provider candidates.

A subscription event source reports lifecycle facts such as a trial start, a first purchase, a renewal, or a cancellation. An attribution provider handles campaign attribution through its documented event and attribution route. For example, Airbridge maps RevenueCat lifecycle events to Airbridge events, while Apple describes ad attribution as postbacks sent to ad networks. A subscription event reaching its destination confirms that the event was received and mapped; the campaign attribution result is a separate part of acquisition reporting.

The seven options by stack role

RevenueCat and Apple App Store Server Notifications are event-source options in this shortlist; Airbridge, AppsFlyer, Adjust, Branch, and Singular are attribution-provider candidates.

1. RevenueCat: use it as the subscription-event source

RevenueCat belongs in the event-source slot when it is already part of the app's subscription setup and you need its lifecycle activity to reach campaign reporting. Airbridge's RevenueCat integration guide says a team can send RevenueCat subscription events to Airbridge, and requires the RevenueCat SDK to be set up first. That gives a team a concrete route to evaluate when its billing layer is RevenueCat and its reporting destination is Airbridge.

Other RevenueCat events can also arrive as custom events with the original RevenueCat event names, with event data in custom attributes; custom events are available on the Growth plan, not on Core. This is useful when your reporting question depends on a particular source event rather than a broad standardized category. For example, an analyst comparing first purchases with trial conversions should preserve that difference in the chosen event setup and reports instead of treating every Subscribe row as the same business outcome.

In the documented Airbridge route, RevenueCat supplies subscription events and Airbridge receives and maps them for reporting. Choose the lifecycle events that match your acquisition decision, then use a provider route documented for your subscription source. If the app uses a different subscription platform, use its corresponding event route rather than assuming RevenueCat's mapping applies.

2. Apple App Store Server Notifications: use App Store status changes as events

Apple's App Store Server Notifications are relevant when the team needs status changes for auto-renewable subscriptions from the App Store. AppsFlyer's server-to-server subscription guide describes Apple's notification service as providing real-time changes in subscription status and says those notifications and their data can be used to send subscription-related events to AppsFlyer.

AppsFlyer's documentation labels this specific server-to-server subscription feature as legacy. Choose this route when App Store notifications for auto-renewable subscription status changes fit your planned event flow.

3. Airbridge: consider it for the campaign-reporting layer

Airbridge fits as the attribution provider when you want campaign reporting alongside subscription revenue and your subscription system is among the supported integration choices. Airbridge Core supports up to two third-party integrations, and the named examples are RevenueCat, Adapty, and Superwall. That gives a subscription app a direct reason to include Airbridge when one of those platforms is already in the stack and the team wants subscription events in its campaign measurement workflow.

For RevenueCat, Airbridge documents an actionable setup rather than a vague integration label. Set up the RevenueCat SDK first, copy the Airbridge Subdomain and Airbridge Token from Airbridge's third-party integration settings, then add them under RevenueCat's Attribution integration settings. The guide also says to configure RevenueCat to send the device IDs collected by Airbridge. Those steps make identity alignment part of the implementation work, not an afterthought.

Airbridge's RevenueCat guide also requires user IDs to be logged identically in the Airbridge SDK and RevenueCat, and says teams must prevent event double counting. Keep those IDs aligned and inspect test events for duplicates before using subscription totals in campaign decisions.

Core includes ad network attribution for Google, Meta, Apple Ads, and TikTok, along with Revenue, Funnel, Retention, and Cohort reports, cost and ad spend aggregation, subscription revenue aggregation, and Predictive LTV. For a founder asking which campaigns generate subscribers and revenue, the practical value is that these capabilities bring campaign cost, subscription events, and revenue reporting into the same product context. Core supports up to two third-party integrations, so a team using both a subscription platform and another third-party tool should make sure the combination fits that allowance.

Airbridge is a strong fit in this shortlist when the required source is documented and the team wants campaign and subscription reporting in one workspace. RevenueCat has explicit setup and mapping guidance; Adapty and Superwall are named as Core integration examples, but the event mapping described above is specifically for RevenueCat. Keep those product facts separate when planning implementation.

4. AppsFlyer: compare the implementation path carefully

AppsFlyer belongs on the provider shortlist when your team needs campaign measurement and can implement subscription events through the specific route its documentation describes. Its in-app subscription attribution guide says the app can send an event after it knows a subscription was purchased or renewed. It gives fields for subscription revenue, currency, subscription name or code, and whether the event represents a new subscription or a renewal.

Those fields connect an event to a business question. Revenue and currency make the purchase amount interpretable; a product or subscription code differentiates plan types; and a renewal flag separates a recurring charge from an initial purchase. AppsFlyer also recommends setting the customer user ID so subscription-related events carry the customer ID and match the customer with app users as they appear in AppsFlyer.

AppsFlyer's server-to-server subscription guide describes Apple's notifications for auto-renewable subscriptions.

AppsFlyer's in-app and server-to-server subscription guides both label those specific paths as legacy. For a lean team, choose an event route that fits your billing source and engineering capacity.

5. Adjust: compare the subscription-event mapping you need

Adjust suits teams that need selected subscription events shared from Adjust to Meta and can map those events to Meta's supported values. Adjust's Meta integration instructions direct users to map the subscription events they want to share to values Meta can receive. Adjust also says unmapped event data is not shared with Meta.

When trial starts, initial payments, and renewals drive different campaign decisions, map each relevant event to the Meta value that represents it.

Trigger a test for one mapped lifecycle event and confirm the receiving platform shows the intended Meta event. Repeat the test for each subscription event that supports a separate campaign decision.

6. Branch: consider it when Branch Events fit your app's route

Branch's mobile SDKs can represent subscription and in-app purchase activity as Branch Events. Its event-tracking documentation says the iOS and Android SDKs can convert standard purchase events from Apple and Google into Branch Events without first creating and populating a Branch Universal Object. That is a specific fit for app teams that already implement the Branch SDK and want to translate standard store purchase events into Branch's event model.

Branch also documents an Attribution API that can send INSTALL, REINSTALL, and OPEN events with attribution properties, with a server-side option for information Branch mobile SDKs provide by default. These install and open events describe an attribution-related API path, while the Branch Event purchase functions cover subscription and in-app purchase events. Keep the two event families distinct when diagramming your implementation: a purchase event records subscription activity, and attribution properties convey acquisition context.

There is a specific server-side condition for teams running Meta campaigns on iOS. Branch says an event sent by server-to-server call must include the OS version for proper Meta attribution in that situation. A small team choosing server delivery should add that value to the test payload and verify that it reaches Branch. This condition ties event payload quality to the ad channel and operating system you use.

Branch can fit when the SDK-based purchase event path matches your stack or when the documented server-side attribution route aligns with how you send install and open data. Compare the actual event source and route in your app, because Branch's standard Apple and Google purchase-event handling is not the same as a RevenueCat-to-Airbridge mapping. The reported event names and identifiers must match the provider-specific setup you implement.

7. Singular: check RevenueCat's SDK and SDID requirements

Singular documents a RevenueCat subscription-event route that uses SDID through Singular Event Endpoint V2. In its subscription-event technical guide, Singular sets the RevenueCat SDK minimum at version 5.87.0 for iOS and 10.19.0 for Android.

Compare the RevenueCat SDK versions in your app with the platform minimums before choosing this route. Singular says SDID cannot run in parallel for event forwarding with certain customer data platforms, including Segment and mParticle, or with third-party subscription providers such as Adapty. When SDID is enabled, Singular says parallel forwarding through those services can lead to incomplete or broken attribution.

Singular's testing checklist gives concrete checks for subscription implementation. It calls for test accounts for Google Play and the App Store, a new subscription event with the correct amount and currency, trial-start and trial-end events, renewal revenue, cancellations, restore filtering to avoid duplicate events, dashboard inspection for correct attribution, and cross-device subscription syncing. The team can use that sequence to catch errors that a successful API call alone will not reveal.

Choose Singular when RevenueCat is your event source, your app meets the stated SDK minimums, and your planned event forwarding fits Singular's SDID conditions.

Choose the combination that answers your acquisition question

Choose the subscription source first, then name the acquisition question your report needs to answer. For example, decide whether you need to compare trial starts, paid subscriber revenue, or renewals across campaigns. Then pair that source with a provider route documented for it; RevenueCat teams can compare the Airbridge and Singular routes described here.

Second, pick the acquisition question before you map events. A team trying to learn which campaigns produce trial starts needs a trial-start event and a provider report that can connect that event to campaign context. A team comparing paid subscriber revenue needs event data with purchase value, currency, and a way to distinguish an initial purchase from a renewal. A team measuring churn needs a cancellation or unsubscribe event. This event plan keeps the integration tied to a real decision rather than sending every available event without a reporting use.

When ad spend appears without subscription revenue, trace the event from its source through destination mapping, then inspect its value, currency, and identity fields. When subscription events appear without campaign names, inspect the provider's campaign report and attribution setup for the same test event.

Choose the candidate whose documented event path matches your subscription source and whose setup your team can implement.

Integration checks before you rely on subscription ROAS

A small validation plan catches event delivery problems before they become budget decisions. Finally, inspect the campaign report that your team uses to evaluate acquisition.

• Record the event source: Note which system emits each trial start, purchase, renewal, and cancellation event. Record whether each event comes from the app SDK, a subscription platform, or a server notification.
• Match event names: For each lifecycle event, record the source event name and the provider's mapped event name. Airbridge's default RevenueCat mapping groups initial purchase, trial conversion, and renewal under Subscribe, so preserve the distinction through event details when the analysis needs it.
• Include the required identity: List the user or device identifiers required by the integration and confirm they appear in a test event. Airbridge's RevenueCat guide requires Airbridge device IDs to be sent to RevenueCat; AppsFlyer's in-app subscription guide recommends setting the customer user ID.
• Verify event values: Compare revenue and currency on a test purchase and renewal with the source record. AppsFlyer's guide lists revenue, currency, subscription name or code, and a renewal flag in its event example; Singular's checklist calls for validating subscription amount and currency.
• Test restores for duplicates: Restore a purchase and confirm that it does not create an extra purchase event. Singular's checklist includes restore filtering.
• Test cross-device behavior: Restore or sync a subscription on another device and compare the resulting account events. Singular recommends testing subscription syncing across devices.
• Confirm campaign context: Trigger a test attributed install or other known acquisition route and check whether the subscription event appears with the expected attribution context.

FAQ

Does RevenueCat assign campaign credit to an install?

In the documented Airbridge integration, RevenueCat sends subscription events to Airbridge, which maps them for reporting.

What subscription events does Airbridge map from RevenueCat by default?

Trial starts map to Start Trial; initial purchases, trial conversions, and renewals map to Subscribe; cancellations map to Unsubscribe. Other RevenueCat events arrive as custom events that retain their original names and include event data in custom attributes; custom events require the Growth plan and are not available on Core.

Can an event arrive without proving that the campaign match is right?

Yes. Airbridge's RevenueCat integration maps subscription events, while Apple describes ad attribution as postbacks sent to ad networks, making event delivery and campaign attribution separate steps. Validate both the event record and its campaign context in reporting.

Which provider should I evaluate first with RevenueCat?

Start with the route your app can implement and validate. Airbridge documents device-ID setup and default RevenueCat mappings; Singular documents RevenueCat SDID requirements and platform-specific minimum SDK versions.

How should I test a subscription attribution setup?

Use a sandbox purchase, trial, renewal, cancellation, and restore flow where applicable. Confirm names, amounts, currency, identity, duplicate handling, and the final campaign report before relying on the numbers for spend decisions.

Related reading

Attribution Platforms Compared by Use Case and Billing Model

October 7, 2026

5 Attribution Pricing Models: E-commerce MTA vs. App MMPs

October 7, 2026

3 Attribution Routes for a Five-Person Team With No Analyst

October 7, 2026