Revenue Attribution: A Billing Migration Setup Guide for Subscription Apps
Revenue attribution survives billing migrations with stable app-owned IDs; learn how to map lifecycle events and avoid duplicate collection in Airbridge.
Keep campaign revenue connected through every billing migration.
- Give each customer and subscription an app-owned ID that stays stable when provider IDs change.
- Keep a mapping from old billing IDs to stable app IDs and then to new billing IDs.
- Define trial, payment, renewal, cancellation, and refund events once, with consistent meaning.
- For Airbridge–RevenueCat, match user IDs and prevent duplicate subscription-event collection.
Revenue attribution stays intact through a billing migration when your app keeps its own customer and subscription IDs, preserves campaign-touch data, and maps each billing provider’s IDs to those stable keys. The billing provider remains the source of subscription transactions; the attribution layer joins those transactions to the campaign that acquired the user.
1. Keep identity stable while billing providers change
Treat the billing-provider ID as a pointer to a customer or subscription in that provider, not as your app’s permanent identity. Your app should own the customer key and subscription key, then store each provider’s customer and subscription IDs against them. When the provider changes, the provider IDs can change while the app-owned keys remain the same.
This creates a simple chain: campaign touch → app customer → subscription → revenue event → campaign report. The campaign touch identifies the acquisition context. The app customer and subscription keys connect the person and paid relationship to the billing records. The revenue event records what happened, and the attribution report joins it back to the original campaign.
Snowplow’s identity documentation identifies identifier-mapping tables as useful for marketing attribution and conversion-funnel reporting. Piwik PRO’s identity-resolution guide recommends a user ID that uniquely represents one person and is provided at sign-up, sign-in, or when the person’s identity becomes known. Apply that principle with an opaque internal account ID, rather than making a billing provider’s ID your cross-system key.
A customer key and a subscription key solve different problems. One customer can hold more than one subscription over time, so keep one durable customer key and a separate durable key for each subscription relationship. If a subscription is transferred, replaced, or split during the migration, record the relationship in the mapping table instead of overwriting the history.
2. Preserve IDs and acquisition context before cutover
Build the ID map before migrating active subscribers. Export the old provider’s customer ID and subscription ID, attach them to your app’s customer and subscription keys, then add the new provider’s IDs as they are assigned. Keep the old values as historical references so an event received after cutover can still be resolved to the same customer and acquisition record.
| Record | Stable app-owned value | Old billing provider | New billing provider | Why it stays in the map |
|---|---|---|---|---|
| Customer | customer_key | old_customer_id | new_customer_id | Connects billing records to the same app account |
| Subscription | subscription_key | old_subscription_id | new_subscription_id | Preserves the relationship and history for one subscription |
| Transaction | transaction_key or provider transaction reference | old_transaction_id | new_transaction_id | Helps identify the purchase or renewal record being reconciled |
| Acquisition touch | touch_id or install key | Original campaign fields | Original campaign fields | Carries source, campaign, creative, and touch time into subscription reporting |
Use this table as a starting schema, then adapt its field names and available references to your billing provider. Keep each provider’s ID in its own column or namespace; customer_42 from one provider should not be assumed to mean the same account as customer_42 from another. Use the app-owned key to join the records, and retain an effective date or migration batch reference so the team can see when each provider ID became active.
Keep the first-touch context with the customer or install record: attributed channel, campaign and creative identifiers when available, touch timestamp, and the app’s install or user key. Airbridge’s iOS SDK documentation describes tracking links passing touchpoint data to Airbridge when users click ads, and its attribution callback includes the attributed channel. These campaign fields preserve acquisition context alongside the billing transaction history.
Keep consent and collection status alongside campaign data. Apple’s App Tracking Transparency documentation requires the framework when an app collects end-user data and shares it with other companies for tracking across apps and websites; the framework presents an authorization request and provides the user’s tracking status. Preserve campaign identifiers only under the consent and privacy rules that apply to your implementation, and avoid using direct personal data such as email as an attribution key.
3. Give subscription events the same meaning in both systems
Before cutover, write an event dictionary that defines each business event independently of the billing provider’s event names. Include the event’s meaning, required IDs, time, currency, revenue basis, and mapping to your reporting name. That way, the new provider can use different labels while your campaign report still measures the same action.
| Reporting event | Meaning to keep consistent | Fields to carry with the event |
|---|---|---|
trial_started | A customer begins an eligible free trial | customer_key, subscription_key, provider IDs, event time, product |
trial_converted | A trial results in a paid subscription | The same keys, transaction reference, event time, amount, currency |
first_payment | First successful paid transaction for the subscription | The same keys, transaction reference, amount, currency, revenue basis |
renewal | A later recurring payment succeeds | The same keys, transaction reference, renewal time, amount, currency |
cancellation_requested | Renewal is turned off, with access potentially continuing | The same keys, cancellation time, provider status |
refund | A completed payment is refunded in whole or part | The same keys, original transaction reference, refund time, amount, currency |
The table is a suggested reporting contract. Your engineering and marketing teams should settle whether the revenue amount means gross proceeds, proceeds after store fees, or another agreed figure, then apply that definition consistently across providers. Keep event occurrence time separate from the time your system received the event, so late-arriving records do not move a renewal into the wrong reporting period.
Do not collapse cancellation and expiration into one event unless your reporting definition explicitly treats them as the same. A customer may turn off renewal before the paid-through period ends; the report should preserve the difference between a cancellation request and the end of access. Likewise, keep trial start, trial conversion, and first payment distinct if you use them to evaluate trial performance.
The Airbridge Android SDK reference lists transaction ID, transaction type, and renewal status as transaction-related attributes. Airbridge’s SDK setup guidance recommends agreeing on event names, parameters, and expected values between marketing and engineering before implementation. Record the old-to-new event-name mapping in the same shared dictionary.
4. Put Airbridge in the campaign-attribution step
Keep billing and attribution responsibilities separate. Your billing provider records subscription revenue and lifecycle events. Your app’s identity map connects provider-specific customer and subscription IDs to your durable keys. Airbridge connects supported subscription events to the campaign that brought the user in, so campaign reporting can include the path from trial conversion to payment and renewal.
Airbridge Core integrates with RevenueCat, Adapty, and Superwall. For connected events from those platforms, Core links trial conversions, first payments, renewals, and refunds to the acquiring campaign. This makes Airbridge the campaign-attribution and reporting step in the architecture, while the billing platform remains responsible for subscription transactions.
Airbridge’s RevenueCat integration guide instructs teams to send RevenueCat’s App User ID to the Airbridge SDK with events such as sign-up or sign-in, and to keep user IDs identical in both systems. Send the ID early enough for the subscription event to join the user’s prior campaign context. The guide’s default event mapping connects RevenueCat TRIAL_STARTED to Start Trial, INITIAL_PURCHASE, TRIAL_CONVERTED, and RENEWAL to Subscribe, and CANCELLATION to Unsubscribe.
5. Check campaign revenue before relying on the new reports
Use a staged cutover so the team can compare like with like. First, take a dated export or snapshot of the old provider’s active customers, subscriptions, and relevant transaction history. Then populate the ID map, create the new provider records, and record the mapping between old, app-owned, and new IDs before routing new billing events into reporting.
Use this cutover checklist:
- Reconcile identity links. Count the active customer and subscription records in the old-provider export, the migration map, and the new provider. Resolve every unmatched active subscription to an app-owned customer and subscription key before using campaign-level revenue totals.
- Confirm event definitions. Send test or controlled lifecycle events for trial start, trial conversion, first payment, renewal, cancellation, and refund. Confirm each provider event lands under the intended reporting name and retains its event time, transaction reference, amount, and currency.
- Pick a small set of test accounts with known acquisition sources. Confirm their app user IDs match the identifiers passed between the billing platform and Airbridge, and verify the resulting subscription events resolve to the expected campaign context.
- Prevent duplicate collection. Choose one source for each subscription event in Airbridge. The Airbridge RevenueCat guide requires matching user IDs and warns that subscription events imported from a third-party integration should not also be collected by the Airbridge SDK, because that can double count events.
- Compare totals by cohort and time. Compare old and new event counts and revenue for the same event types and time window. Break results out by subscription cohort and campaign, then inspect unmatched IDs, duplicate transaction references, and shifts in event timing before signing off.
- Keep the mapping after cutover. Store old IDs, new IDs, and the stable app keys for historical reporting. Send future events with the current provider’s IDs plus the same app-owned keys, and update the mapping table whenever an account or subscription changes.
For RevenueCat, configure its SDK to send Airbridge-collected device IDs to RevenueCat, as required by the integration guide. When Airbridge cannot find a matching RevenueCat user ID, it generates a random ID, which may increase the displayed user count for subscription-related events.
At sign-off, align the reports’ currency and agreed revenue basis, then investigate unmatched records and duplicate transactions before interpreting campaign-level changes. Once the identity map, event mapping, and campaign join pass those checks, use the new provider for future billing and keep historical campaign reporting on the same app-owned keys.
FAQS
FAQ
What does attributable revenue mean?
Attributable revenue is subscription revenue connected to an acquisition source, such as a campaign or channel. The connection depends on joining the billing event to the customer or install’s campaign context with a consistent identity key.
What does attribution mean in business?
Attribution means assigning a business outcome, such as a subscription payment, to a customer touchpoint or campaign under a defined measurement approach. For a subscription app, the practical test is whether a trial, payment, renewal, or refund can be connected to the campaign that acquired the user.
Can a billing migration preserve campaign revenue history?
Yes. Keep an app-owned customer and subscription key, map the old and new billing IDs to those keys, and retain the campaign-touch fields and historical events associated with them. Airbridge can join supported RevenueCat, Adapty, and Superwall subscription events to the acquiring campaign.
Which identifier should survive a billing-provider change?
Use an app-owned customer key for the account and a separate app-owned subscription key for each subscription relationship. Use an app-owned customer key and a separate app-owned key for each subscription relationship; for RevenueCat, send its App User ID to the Airbridge SDK on sign-up or sign-in, with identical user IDs in both systems.
Get Started Free
See how these criteria hold up on the real thing.
Related reading
