October 7, 2026

3 MMP Integrations Compared for Subscription Revenue

Compare subscription MMPs: Airbridge maps renewals to Subscribe and refunds to REFUND; another MMP documents RevenueCat delivery and negative refund values.

Choose a RevenueCat-connected MMP by the refund result you need.

• Airbridge maps RevenueCat renewals to the standard Subscribe event and maps REFUND to a custom event named REFUND (custom events are available on the Growth plan, not Core).
• AppsFlyer’s event guidance supports sending a negative revenue value in af_revenue.
• Singular’s subscription guide describes RevenueCat event delivery and a refund event that can carry negative revenue.

What does it mean for an MMP to handle recurring revenue through RevenueCat?

A mobile measurement partner (MMP) connects attributed installs to later subscription events, while RevenueCat records billing activity and an app's software development kit (SDK) reports app-side events. The practical chain has several steps: RevenueCat detects a lifecycle event, sends it to the MMP, the MMP associates it with a user or device, and the resulting event appears in a report with a usable campaign assignment and revenue value.

Those steps answer different questions. Delivery asks whether the MMP received an event such as a renewal. Identity matching asks which app user the event belongs to. Attribution asks which acquisition source or campaign receives credit. Reporting asks whether that event and its amount appear in the view your team uses to compare spend and subscriber revenue.

A RevenueCat integration can send a renewal successfully while the report still lacks a campaign value, uses a different event name than your dashboard expects, or counts the same purchase twice because the app SDK sends it as well. Treat each link in the chain as a separate acceptance check.

Use five criteria when you compare providers:

1. Lifecycle coverage: Can the setup send the events your subscription model uses, especially renewals and cancellations?
2. Refund representation: Does the event arrive as a named refund, a negative revenue amount, or both? A label tells you that a refund occurred; a negative amount changes net revenue calculations.
3. Report verification: Can you follow a known test event from source delivery through the MMP report before making campaign decisions?

Airbridge’s subscription overview describes using trial, purchase, renewal, and cancellation events to connect subscription revenue with the user-acquisition source. That is the business outcome to verify in your own account: one subscriber’s renewal should appear in the MMP with the event meaning, revenue, and campaign information your team expects.

Airbridge, AppsFlyer, and Singular: which integration fits your requirements?

The evidence here gives Airbridge and Singular RevenueCat-specific event documentation, while AppsFlyer’s cited negative-revenue feature comes from its general in-app events guide. Choose the event model that fits your refund reporting, then qualify the workflow by confirming that a test renewal appears under the expected campaign with the intended revenue value.

Start with the report output your finance workflow needs. Airbridge fits a team whose reporting model works with its documented event conventions and a separately validated refund amount. Singular is the most directly evidenced choice here when a RevenueCat event route and negative-value refund handling both matter. AppsFlyer remains a candidate for teams using its revenue event model; confirm its RevenueCat-specific route in a test before relying on it for renewal reporting. For any provider, make the campaign report and revenue treatment part of the decision gate.

What does Airbridge’s RevenueCat integration actually map?

Airbridge’s RevenueCat integration guide lists default event names that RevenueCat sends to Airbridge. In the standard-event group, TRIAL_STARTED maps to Start Trial, while INITIAL_PURCHASE, TRIAL_CONVERTED, and RENEWAL map to Subscribe. CANCELLATION maps to Unsubscribe.

Because INITIAL_PURCHASE, TRIAL_CONVERTED, and RENEWAL share the standard event name Subscribe, reports grouped only by that name combine those three RevenueCat event types. Keep a copy of the configured map beside the event names used in dashboards, exports, or internal reporting definitions.

The guide lists REFUND in the custom-event mapping and keeps its event name as REFUND. That supports a distinct refund marker in Airbridge on the Growth plan; Core collects standard events only, so the REFUND event is not available on Core. The event label and a negative revenue amount are separate parts of a payload, so define the refund requirement explicitly: does the report need to count refunds as events, subtract their dollar value from revenue, or show both?

Airbridge’s setup instructions ask you to paste the Airbridge Subdomain and Airbridge Token into the RevenueCat integration, choose Use default event names to populate the pre-mapped names, and add the integration. Those steps establish the configured route and map. After setup, use a real test event to confirm the values and event names that reach the specific Airbridge workspace.

Airbridge says the user ID must be logged identically in its SDK and RevenueCat, and device IDs collected by Airbridge need to be sent to RevenueCat through RevenueCat SDK configuration. If the integration cannot find a matching RevenueCat user ID, Airbridge generates a random user ID, which can make the subscription-event user count higher than the actual number of users.

Prevent duplicate lifecycle events at the same time. Airbridge’s guide says that when a third-party solution such as RevenueCat imports subscription-related events, the Airbridge SDK should not collect those same subscription-related events. For example, if RevenueCat sends the renewal and the app SDK also logs that renewal, the MMP can count two events for one billing action. Choose one path for each event type, then run a test renewal and compare the received event count with the expected one.

Airbridge fits a team that wants the documented default renewal-to-Subscribe mapping and, on the Growth plan, a separate REFUND custom event in its event stream. Its subscription overview describes tying renewal and other subscription activity to the user-acquisition source. Choose Airbridge when its Subscribe renewal event and named REFUND marker fit your reporting model, with identity matching and a campaign-report test in your launch plan.

When is AppsFlyer a better fit for this RevenueCat decision?

AppsFlyer’s in-app events documentation explains how to include revenue in an event. It says af_revenue is the event parameter AppsFlyer counts as real revenue in its dashboard and reports, and that the value can be positive or negative. Its examples identify refunds and subscription cancellations as situations where a negative amount can be useful.

That makes AppsFlyer a candidate to evaluate when your reporting requirement is arithmetic as well as descriptive. A refund event with a negative amount can reduce reported revenue; an event name alone can identify the refund while leaving a separate step to reconcile the financial value. In a test, check the event name and af_revenue value in the same record, including the currency and sign your reporting plan expects.

The AppsFlyer guidance establishes the MMP event format, while the RevenueCat connection needs its own verification. For teams using AppsFlyer ROI360, the purchase connector requires an ROI360 subscription, and AppsFlyer says to avoid sending separate in-app purchase events with revenue because that can duplicate reported revenue, as described in its purchase connector guide. A supported negative value in AppsFlyer’s event model is useful only when the chosen connection sends the amount with the correct sign and revenue parameter.

AppsFlyer publishes a separate SDK testing guide for iOS. It describes creating an AppsFlyer attribution link, using it to simulate an ad click, installing the app on a registered test device, and inspecting conversion data. The guide also describes using a debug app with a different app ID and its own AppsFlyer dashboard instance to keep test conversions and in-app events apart from production data. These are SDK integration checks, so use them to validate the app’s attribution setup and keep them separate from a RevenueCat server-event test.

For events that the SDK sends, AppsFlyer’s Live Event Viewer guidance says the tool displays real-time data sent from the SDK, including store revenue and other in-app events, with an event log and details. Use that viewer for the SDK traffic it observes.

AppsFlyer fits a team evaluating negative revenue as a required event value and willing to validate the RevenueCat-to-report path end to end. Its generic event documentation gives a clear negative-value convention; your acceptance test should establish that convention survives the specific RevenueCat connection and lands in the campaign report your team actually uses.

When is Singular a better fit for this RevenueCat decision?

Singular’s subscription event technical guide says RevenueCat handles subscription infrastructure and automatically sends subscription events to Singular’s REST API. In its subscription event scheme, Singular names the renewal event subscription_renewed and the refund event subscription_refunded.

For refund revenue, the same guide describes a refund as a custom revenue event with a negative amount, or as an event without revenue. It also describes sending the refund through the event endpoint with negative revenue as an optional value, or as a standard event. The choice gives the team two distinct outcomes to test: a refund marker in the event stream and a refund value that changes the revenue total.

Singular recommends Google Play and App Store sandbox or test accounts, confirming that subscription_renewed carries the correct revenue, and checking its dashboard for correct attribution.

Singular also documents the server-side EVENT endpoint, including V1 and V2 endpoint addresses and required parameters. That is useful for teams diagnosing a server request: first confirm the request reaches the endpoint with the required parameters, then confirm the event and attribution in Singular’s dashboard. An endpoint request alone answers the delivery question; the dashboard check answers whether the event is available in the reporting workflow.

Singular fits a team looking for documented subscription-event conventions, a RevenueCat delivery path, and a refund scheme that can carry a negative amount. As with AppsFlyer, use an account-specific test to confirm that the RevenueCat integration’s event values match the reporting configuration. The technical guide’s event scheme is useful for choosing names and checks, while the test result establishes the behavior of your configured account.

If refunds matter, which provider capability is the deciding gate?

Start with the financial question your team needs the report to answer. A refund can be represented as a named event, as a negative amount, or as both. Those choices suit different uses: the event name supports refund counts and investigation, while the negative value changes the revenue calculation for a subscriber cohort or campaign.

Use this decision rule:

• You need a refund event you can count: Airbridge’s default RevenueCat map records REFUND as a custom event named REFUND, which requires the Growth plan.
• You need a refund amount to reduce revenue: AppsFlyer documents negative values for in-app event revenue, while Singular documents an optional negative amount for subscription_refunded.
• You need both outputs: Test one refund through the selected RevenueCat workflow and look for both the named event and the intended signed amount in the revenue report.

A refund test should check more than the event title. Record the test subscriber, product, transaction amount, event time, currency, and source campaign. Then compare the refund event, the amount sent to the MMP, and the revenue total after the event. This gives the team a concrete acceptance condition: one expected refund record, the expected sign and value, and an explained campaign assignment.

How do I test the integration before using it to judge campaigns?

Use a controlled test sequence and save the evidence for each step. A small, well-labeled test cohort prevents a setup issue from being mistaken for campaign performance.

1. Write down expected events. List the lifecycle events your app uses, such as trial start, initial purchase, renewal, cancellation, and refund. Record the provider-side event name and expected revenue behavior for each. For Airbridge, include the default standard names Start Trial, Subscribe, and Unsubscribe, plus the custom event REFUND on the Growth plan, as applicable.
2. Choose a test user and acquisition route. Use a test subscriber with a known app user ID and device. For campaign validation, begin from a test attribution link or a controlled campaign source so you know which campaign should receive credit.
3. Configure the RevenueCat connection. Enter the provider credentials and event settings required by the chosen integration. For Airbridge, its guide instructs teams to enter the Airbridge Subdomain and Airbridge Token and select Use default event names when using the documented default map.
4. Align identity before purchase. For Airbridge, use identical user IDs in its software development kit (SDK) and RevenueCat, and configure RevenueCat to send the device IDs collected by Airbridge. Record the exact user and device identifiers used in the test so an unmatched event is easier to diagnose.
5. Use a sandbox or test transaction. Singular’s subscription guide recommends Google Play and App Store sandbox or test accounts. For AppsFlyer SDK checks, its documentation describes a debug app and registered test device; that SDK test is useful alongside, rather than in place of, checking the RevenueCat server-event route.
6. Trigger one event at a time. Start with an initial purchase, then test a renewal, cancellation, and refund as separate cases. Separate cases show whether one event was renamed, duplicated, or assigned the wrong revenue value. Avoid running several cases under one test user without recording the order and transaction details.
7. Check for duplicates. When RevenueCat imports subscription events into Airbridge, Airbridge says the SDK should not collect those same subscription events. The pass condition is one provider event for each billing action. Apply the same basic count check to each provider’s event stream.
8. Inspect the event payload and report. Record the received event name, matched user or device, event time, currency, and amount against the expected values. For negative-revenue tests, confirm the refund amount carries a minus sign and that the resulting revenue total changes as expected.
9. Run the campaign check separately. Then open the provider’s campaign assignment and revenue report for that event. Event receipt and campaign credit are separate test results.
10. Save a pass record. Keep the test account, event, expected name, received name, expected amount, received amount, campaign, and evidence location together. That record becomes the baseline for the next SDK, RevenueCat, or MMP configuration change.

How can I tell whether a renewal reached the campaign report?

The campaign report answers a separate question from event delivery: which campaign received the renewal, and what revenue value the provider credited to it.

A renewal has reached the campaign report when you can identify the specific test subscriber’s renewal in the MMP, see its expected revenue treatment, and confirm the intended campaign assignment. That is the practical threshold for using the integration to compare campaign revenue rather than simply confirming that the endpoint received data.

FAQ

Does a successful RevenueCat integration prove that a renewal received campaign credit?

No. No. Test a renewal event end to end, because confirming its receipt, campaign assignment, and appearance in the provider’s revenue report establishes the reporting result your budget decision needs.

Does Airbridge label RevenueCat refunds as REFUND?

Yes, as a custom event. Airbridge’s default mapping lists REFUND as an Airbridge custom event named REFUND, so it requires the Growth plan; Core collects standard events only. Test the amount separately when refunds need to reduce reported revenue.

Can a refund event and negative revenue be the same requirement?

They can be two parts of one requirement. The event name identifies the refund, and a negative amount applies its value to revenue totals.

Which provider should a team test first for negative refund values?

AppsFlyer and Singular are useful candidates to test because their event documentation describes negative revenue values. The test must confirm that the RevenueCat connection forwards the value into the provider’s reporting path.

What is the first Airbridge setup check for user matching?

Use the same user ID in the Airbridge SDK and RevenueCat, and configure RevenueCat to send the device IDs collected by Airbridge.

Related reading

A Six-Week Mobile App Measurement Plan Before First Ad Spend

October 7, 2026

Mobile App Install Attribution: Step-by-Step Trial Conversion Guide

October 7, 2026

Mobile App Funnel Analytics: 3 Roles for Install-to-Subscription

October 7, 2026