Conversion tracking audit checklist for mobile subscription apps
Conversion tracking audit checklist checks event delivery, duplicates, identity, and billing matches, showing whether funnel data is ready to trust.
A conversion tracking audit checklist helps you decide whether subscription-funnel data is ready to trust.
- Define which billing or backend record is authoritative for each subscription state.
- Inventory trial, payment, renewal, cancellation, and refund events.
- Test delivery from the app or billing provider through to each reporting destination.
- Match event records against billing records, then review campaign attribution separately.
A conversion tracking audit checklist should follow a subscription event from the action that creates it to the report where your team uses it. Treat billing or validated backend records as the reference for subscription status, and treat campaign reports as an attributed view of those outcomes. Airbridge Core connects trial conversions, first payments, renewals, and refunds from RevenueCat, Adapty, or Superwall to the campaign that brought the user in.
A reliable audit checks event coverage, delivery, identity, and reconciliation. The steps below suit a lean subscription-app team that needs to know whether trial and paid-conversion numbers are sound before changing a paywall or campaign.
What complete conversion tracking means
Complete tracking means every business-critical subscription transition creates the expected record, reaches the destinations that use it, and matches the underlying subscription record. It also means your team can distinguish one subscriber from several billing events generated by that subscriber over time.
Event collection and campaign attribution answer different questions. An event record captures an action such as a trial start or payment; attribution connects eligible app activity or attributed installs with an acquisition source under that platform's measurement rules. A campaign report therefore helps compare acquisition outcomes, while the billing provider or validated app backend establishes subscription status and transaction history.
Pick the system that resolves each user's current entitlement as the operational reference. For purchases through Apple or Google, that reference should incorporate the store's transaction or subscription status and the provider or backend record that your app uses to grant access. Google Play Real-time developer notifications signal a purchase-state change, and developers use the Google Play Developer API to retrieve full purchase status and update their backend.
Subscription conversion tracking audit checklist
Use one row per lifecycle action, and write down the event name your implementation actually sends. This keeps a difference in naming from hiding a difference in meaning.
| Lifecycle action | What the row means | Identity and evidence to compare | Audit result |
|---|---|---|---|
| Trial start | A customer enters a free or introductory trial. | App user or subscription identifier, product, event time, and the provider's trial-start record. | One expected start record appears at the source and each configured destination. |
| First paid transaction or trial conversion | The first paid period starts, including a trial that converts to paid. | Subscriber or subscription identity, transaction or order reference, product, paid status, amount, and currency where available. | Count the successful paid transition once; keep trial starts separate from paid conversions. |
| Renewal | A later subscription period is paid or renewed. | Subscription identity, transaction or renewal reference, period dates, status, amount, and currency. | Each successful renewal appears once, and the period belongs to the right subscriber. |
| Cancellation or renewal turned off | The customer or store changes future renewal status. | Subscription identity, event time, cancellation or renewal-status reason, and current entitlement end date. | Report the status change separately from the end of paid access. |
| Expiration or failed renewal | Access ends, or renewal payment fails and enters a retry or grace period. | Subscription identity, current status, effective date, and grace or retry status. | The event does not get counted as a successful payment. |
| Refund or revocation | A completed purchase is refunded or access to the transaction is revoked. | Original purchase or subscription identity, refund or revocation state, effective time, and amount when supplied. | The refund is linked to its purchase and appears in the appropriate revenue view. |
Keep cancellation separate from expiration. A customer can turn off auto-renewal while a paid period remains active, so a cancellation event does not by itself mean the subscription has already ended. Apple's App Store Server Notifications documentation uses separate notification types for renewal-status changes, renewals, expiration, and refunds; Google's RTDN reference distinguishes cancellation, renewal, recovery, revocation, and grace-period events.
Define the count beside each event. For example, one person can start a trial, convert to paid, and renew several times. A trial-start count measures starts, while a paying-subscriber count should use the intended unique-subscription or unique-customer definition for the report.
Where each event starts and where it should arrive
Map the actual route for your app rather than assuming every subscription event starts in the app SDK. The user may begin the purchase in the app, while the store or subscription platform records the payment, renewal, cancellation, or refund and then sends the lifecycle information onward.
| Checkpoint | Typical source | What to verify |
|---|---|---|
| User action | App purchase or paywall flow | The intended product and trial or purchase action are identified. |
| Subscription state | Billing provider, store transaction, or backend entitlement record | The selected record is the reference for a subscription's trial, paid, renewal, cancellation, or refund status and effective time. |
| Event integration | Configured provider connection, SDK, webhook, or server route | The event name, subscription identity, and event properties reach the next system. |
| Acquisition reporting | Analytics or mobile measurement destination | The mapped event appears in the right report and, where available, is associated with an attributed campaign. |
For eligible integrations, Airbridge Core connects RevenueCat, Adapty, or Superwall subscription outcomes to acquisition campaigns. In Airbridge's RevenueCat integration guide, TRIAL_STARTED maps to “Start Trial”; INITIAL_PURCHASE, TRIAL_CONVERTED, and RENEWAL map to “Subscribe”; and CANCELLATION maps to “Unsubscribe.” Those mappings make the event's meaning visible in the campaign-reporting layer, while your billing or backend records remain the reference for whether payment or access actually changed.
Airbridge's Adapty integration lets teams report subscription-related revenue with the Subscription Revenue (App) metric and choose the user's currency or USD. With Report proceeds selected, reported amounts are after App Store or Google Play Store fees; Exclude historical events leaves out events from before Adapty SDK installation. These settings determine which amounts and event dates appear in the comparison, so record their selected values with the audit.
How to check conversion tracking end to end
Run controlled tests for the important paths, and capture evidence at each handoff. A connected status confirms integration configuration, and a matching test record in the billing source and destination confirms that the event completed the route.
- Prepare a test identity and product. Use a designated tester account, a known subscription product, and a test environment supported by your store and billing provider. Record the platform, app build, product, and expected test action so the resulting records can be found later.
- Run the action in the app. Complete the trial-start or purchase flow on a test device. Note the test user, local time, product, and the result shown in the app.
- Match the app action to the corresponding state or transaction in the billing provider or validated backend, using the same test identity, product, and event time. Verify that a trial remains identified as a trial and a successful payment carries paid status.
- Trace the event through the provider event log, webhook or integration delivery record, and receiving analytics or measurement event view. Compare the event name and subscriber identity at each handoff.
- In the attribution destination, match the mapped event to the test and record the campaign fields shown for that event. Record event receipt separately from whether a campaign receives credit.
- Where the test environment supports them, validate trial conversion, renewal, cancellation, expiration, and refund as separate state changes. Keep the test period and event status with the evidence.
On iOS, Apple's StoreKit subscription testing guide explains that sandbox renewals happen at an accelerated rate, with auto-renewable subscriptions renewing up to 12 times after the initial purchase. This lets a team exercise repeated renewal paths faster than waiting for full production billing periods. Keep sandbox records labeled as tests so they do not become production conversion totals.
For app-side Firebase Analytics events, Firebase DebugView shows raw events from development devices in near real time, with event timestamps and associated parameters. Firebase Analytics generally batches standard app events for about an hour; debug mode on a development device uploads them with minimal delay. Use DebugView to test the app-side event, then inspect your billing and campaign destinations as separate checkpoints.
How to find missing or duplicated events
Compare expected lifecycle transitions with observed records by subscription identity and event meaning. A healthy event stream contains one logical record for each transition that your implementation defines, even when a transport retries delivery or a second integration observes the same purchase.
Look first for missing handoffs. A successful trial conversion at the billing source with no destination record locates the gap along the provider-to-destination route; the provider event log, integration configuration, credentials, and event mapping identify the handoff to repair. If the event appears at the provider but not at the destination, the break is downstream from the provider record.
Then look for repeated records. Search for the same event identity, subscription or original-transaction identity, product, and event time across the app, billing provider, and reporting destination. A repeated delivery may be a transport retry; two separate records may also reflect two valid lifecycle events, such as a renewal and a later refund. Compare the records' state and timestamps before labeling them duplicates.
Choose and document a deduplication key that matches the event source. Prefer a stable provider event identifier when available; otherwise combine the purchase or subscription identity with the event type and lifecycle period or timestamp. Also document whether both app-side and billing-side integrations send the same transition. A single event arriving by two routes can inflate counts even when both integrations work as configured.
For Google Play, use the RTDN as a prompt to retrieve current purchase status rather than treating the notification as the full transaction record. Google's reference identifies purchaseToken as the token supplied to the user's device when the subscription was purchased, and directs developers to call the Developer API after receiving a notification. This helps distinguish a state-change notice from the authoritative details your backend should reconcile.
How to reconcile events with billing or backend records
Reconcile a defined time range and event type, then match records before comparing totals. Use the same timezone and date field on both sides, and note whether the report groups by event occurrence time, transaction time, or ingestion time.
- Export or query the source records for one event type and a settled time range, such as trial conversions for a completed week.
- Export the matching destination records using the same date range and event definition.
- Match each source event to a destination event using the stable identity available in both systems, plus product and event time.
- Classify each unmatched item as missing at the destination, extra at the destination, duplicated, or delayed.
- Compare paid status, amount, currency, and refund state for matched transactions. Record differences caused by reporting settings, such as currency conversion or store-fee proceeds.
Apple's App Store Server Notifications documentation includes transaction identifiers and timestamps for matching subscription lifecycle records. It also identifies fields such as originalTransactionId and productId for the original transaction and product, and revocationDate for the refunded transaction's timestamp. Use store and billing fields with the same meaning when matching records; a customer identifier alone may cover more than one purchase or subscription.
Compare event counts and money separately. Renewal counts can match even when revenue differs because one report uses post-fee proceeds or a different currency. Use the currency and proceeds settings already recorded in the audit to interpret amount differences before labeling one as a missing event.
How privacy limits and attribution windows affect the result
Privacy-limited attribution adds its own reporting windows and delivery schedule.
Apple's SKAdNetwork conversion-window guide defines three windows from the user's first app launch: days 0–2, days 3–7, and days 8–35. The system prepares the first postback after the first window ends unless the app enables a lock in a conversion-value update, which triggers preparation at that call; it sends the postback after a random 24–48-hour delay.
Record the attribution method and window for each acquisition destination, then allow for its documented reporting delay before comparing campaign results.
When the funnel is ready to trust
A funnel stage is ready for optimization when each critical event has a named source and destination, controlled tests show the expected event path, repeated events have a defined deduplication rule, and billing reconciliation explains the remaining differences. A useful audit closes with a short scorecard:
- Pass: Every critical transition has a source record, the expected mapped event reaches its destination, and reconciliation differences have a known explanation.
- Needs follow-up: A source record exists, but a handoff, identity match, or reporting setting still needs correction.
- Attribution-limited: The event is present, while campaign credit is delayed or unavailable under the applicable attribution method.
Keep the test evidence with the event inventory: app build, test product, test identity, source record, destination record, timestamps, and any matching or currency rules. Repeat the affected checks after changes to purchase code, provider settings, event mappings, or attribution integrations. Once trial starts, first paid conversions, renewals, and refunds pass their own checks, you can use the funnel to judge campaign and paywall performance with a clear view of which parts are verified.
FAQS
FAQ
How to check conversion tracking?
Follow one controlled test event from the app action to the billing or backend record, through the configured integration, and into the destination report. Match the records by identity and event meaning, then check campaign credit separately.
What should be included in an audit checklist?
Include trial starts, first paid transactions or trial conversions, renewals, cancellation or renewal status, expiration or failed renewal, and refunds. For each event, record its meaning, source, identity, destination, expected count, and test evidence.
What is conversion tracking?
Conversion tracking records a defined user or subscription action, such as starting a trial or paying for a subscription, and sends it to reporting systems. Attribution adds the eligible campaign or channel associated with an event under the destination's measurement rules.
How do I set up conversion tracking?
Define the event inventory first, then configure the app or billing-provider event route and map those events in each destination. Test the path with a controlled purchase, verify the source and receiving records, and reconcile paid status and revenue against billing or backend data.
Get Started Free
See how these criteria hold up on the real thing.
Related reading
