How to combine AppsFlyer and Firebase in a commerce app
AppsFlyer and Firebase should not report two competing truths. AppsFlyer handles install, campaign and deep-link attribution; Firebase/GA4 handles in-app behaviour; and the backend owns purchases, refunds and order value. Shared identifiers and a documented event contract connect the layers.
Responsibility split
AppsFlyer records install, re-attribution, campaign source and deep link. Firebase captures screens, search, cart and checkout. The backend confirms payment, order, refund and final value. This split reduces discrepancies and makes auditing possible.
Identifiers and privacy
Do not send email addresses or personal data as event names or open parameters. Use a pseudonymous customer_id after authentication, transaction_id for the order and campaign_id for campaigns. Consent and ATT must control the relevant SDKs before collecting data that requires permission.
Deep link from ad to product
A link should open the intended product or promotion, retain campaign context and handle the no-app case. After installation, a deferred deep link takes the customer to the correct destination. Campaign, product-open and purchase events need shared identifiers without duplicating when the app returns from the background.
QA and report reconciliation
Before campaign launch, complete a controlled purchase with a known source. Confirm that AppsFlyer shows the campaign, Firebase shows the funnel and the backend has one order with the same value. Do not hide discrepancies with dashboard adjustments; identify the layer that lost or duplicated the event.
Common integration failures
The most common failure is two independent purchase events: one from the app and one from the server, without a shared transaction_id. Other problems include losing campaign context after login, firing the deep link again on foreground, inconsistent currencies and sending a user identifier before consent or authentication.
A second failure class is release mismatch. Marketing launches a campaign before the new app version reaches enough users, so part of the audience cannot emit the new events. Reporting should always support segmentation by app_version and platform.
A safe three-step rollout
Start in a test environment and on internal devices. Then release to a small user share without increasing campaign spend. Scale acquisition only after confirming funnel completeness, no duplicates and revenue reconciliation with the backend.
- Debug: one device, one scenario, complete log.
- Canary: small user share and controlled order sample.
- Scale: monitor discrepancies, errors and app-version share.
Sources
AppsFlyer SDK integration: https://dev.appsflyer.com/hc/docs/rn_getting_started
Firebase Analytics: https://firebase.google.com/docs/analytics
Apple ATT: https://developer.apple.com/documentation/apptrackingtransparency
Frequently asked questions
- Which system should report purchase?
- The order backend should be the source of truth. It can forward the confirmed event to analytics and attribution tools using the same transaction_id.
- Does AppsFlyer replace GA4?
- No. AppsFlyer focuses on mobile attribution and campaigns; GA4/Firebase focuses on behaviour and product reporting.
- How do we avoid duplicate purchase reporting?
- Choose one system to emit confirmed purchase, use a shared transaction_id and deduplicate in destinations. The app can report payment start but should not compete with the backend for the final outcome.
Content updated: August 26, 2026
Google Preferred Sources
See GMI more often in Google
Add gmi.software as a preferred source. Google may highlight our new articles more often in Top Stories and supported AI experiences.