Flutter Mobile Attribution: Tools by Use Case

Decide from three signals: activity inside the app, a campaign's attributed install and later events, or a click's in-app destination.

• Use Firebase Analytics when campaign parameters and first-open attribution answer the question your team is asking.
• Choose Branch when campaign links must open the right app content and you also want link attribution.
• Choose an MMP when paid campaigns, attributed installs, and post-install outcomes need one measurement workflow.
• Airbridge fits teams using Google, Meta, Apple Ads, or TikTok that want Flutter SDK verification plus revenue and funnel reports.

Flutter mobile attribution starts with one decision: do you need to understand app behavior, connect campaigns to installs and later events, or route a click into a particular screen? Those jobs can overlap, but they solve different problems. A small subscription-app team can avoid paying for a stack that answers questions it does not ask by defining the reporting job before adding another SDK.

This guide compares five options by their documented role, Flutter implementation evidence, event or reporting scope, link needs, platform setup, and published Airbridge Core pricing.

Decide which measurement job you need

Start with the question that will change what you do next week. “Which onboarding step loses new users?” is a product-analytics question. “Which paid campaign drove first opens and later trial starts?” is a campaign-attribution question. “Can the install open directly on the offer page a person clicked?” is a deep-linking question.

Product analytics organizes events inside the app. Campaign attribution connects an ad or campaign interaction with an attributed install and later activity, subject to platform privacy rules. Deep linking uses a link to open an app to a specific screen.

Use the same selection checks for every tool:

1. Flutter implementation: Is there an official Flutter package or plugin, and do its current setup instructions cover the iOS and Android builds you ship?
2. Decision measured: Does the product report app behavior, link engagement, campaign-to-install attribution, or the combination your team needs?
3. Post-install events: Can you send the events that matter to a subscription business, such as account creation, trial start, and paid conversion, and see them in the reports you will use?
4. Link routing: Do campaigns need a link that opens a product page, paywall, or other destination inside the app?
5. Platform behavior: Does the provider’s flow align with iOS privacy attribution, Android install signals, and your app’s routing configuration?
6. Cost and operating effort: Can the plan, usage terms, and implementation work fit a small team’s actual traffic and maintenance capacity?

Apple's WWDC24 presentation on AdAttributionKit describes SKAdNetwork as a privacy-preserving framework powered by crowd anonymity and AdAttributionKit as built on SKAdNetwork fundamentals; AdAttributionKit sends conversion information in a postback after a measurement period, with more data returned as crowd size grows.

The same WWDC24 presentation distinguishes ad clicks from ad views in the postback, and its coarse conversion values are low, medium, or high when crowd-anonymity conditions prevent sending a fine value. Teams can use those fields as structured campaign feedback when they review the iOS report.

Apple's App Tracking Transparency instructions tell developers to add NSUserTrackingUsageDescription to the app target, call requestTrackingAuthorization(completionHandler:) to present the authorization request, and check the authorization status. That permission flow is separate from the privacy-preserving attribution frameworks. On Android, Google Play Install Referrer returns referral information for an app installed through Google Play, including the referrer URL and install timestamps.

Tool	Start here when	First evidence to validate
Firebase Analytics	Flutter event logging and campaign details tied to first opens answer the measurement question	Campaign parameters, campaign_details, and first_open
Branch	Campaign links need to open relevant app content, with link-led attribution	Flutter link-session handling, app destinations, and downstream events
Airbridge	The developer wants an explicit Flutter SDK installation check	Separate iOS and Android initialization, SDK test, and the iOS target requirement
AppsFlyer	The team is evaluating its listed Flutter plugin and related event and OneLink materials	Plugin fit for the project and the separate event and link documentation

1. Firebase Analytics: use it for app behavior and straightforward campaign questions

Firebase Analytics fits a Flutter app when the team needs event logging and campaign details tied to first opens; Google's Flutter Analytics setup guide covers the plugin, and its event guide documents event logging. In Google's campaign measurement guide, teams can send campaign_details shortly after a first install to record source, medium, and campaign; first_open then uses the information in that event. This gives a lean team a way to connect tagged campaign information with the first app open.

Google's Flutter Analytics setup guide starts with registering the app in Firebase and initializing firebase_core, then adds the Flutter plugin with flutter pub add firebase_analytics. After creating a FirebaseAnalytics instance, Google's event guide documents the library's log methods for sending event data. The setup also recommends adding the AdSupport framework for additional features such as audiences and campaign attribution.

That fit works well during an early release when the team has a small campaign set and wants to validate onboarding behavior, campaign tags, or first-open volume in its existing analytics setup. For example, a founder can compare tagged campaign cohorts against the same defined app events and see whether one source produces more account creation or trial starts. The useful outcome is a practical signal for the next creative or onboarding change, using the event names and campaign parameters the team has actually implemented.

For example, suppose a campaign sends people to a subscription offer. Campaign parameters identify the source, first_open marks the first app opening, and a separately defined trial-start event records the next business step. If first opens appear for that campaign but trial starts lag, the team can inspect the onboarding and offer path while keeping the event definition consistent across acquisition sources.

Keep the reporting question specific. Google's install attribution guide lists auto-tagging, iOS universal links, Android app links, and the Play Store Install Referrer API as app-install attribution methods. Use consistent campaign parameter names and values across paid links so comparable campaigns retain the same source labels.

Firebase is enough when its reports answer the team's actual budget and product questions, and the team is comfortable implementing the relevant events and campaign tagging itself. When routine decisions combine campaign-to-install credit with later subscription outcomes, assess an MMP against that workflow and the provider's documented channels and event reporting.

For subscription apps, name events around business outcomes rather than screens alone. “Trial started” and “paid conversion” can help a team assess acquisition quality alongside “onboarding completed.” Define the event once, document when it fires, and keep event properties such as plan or currency consistent across app versions. That event plan can travel with the team if it later adds a campaign measurement product, preserving comparison across releases.

2. Branch: choose it when links must carry users into the right place

Branch is the clearest fit when acquisition links need to do more than send someone to an app-store listing. Branch's Flutter SDK overview covers deep links to app content, campaign measurement across Android, iOS, and Web, last-touch attribution, and downstream events in the Branch dashboard. The overview also identifies Branch standard events as a way to support ad campaign optimization.

A creator link could open a specific recipe, training plan, or subscription offer, while the team measures the campaign source and subsequent app events. A link destination can reduce the handoff from “I tapped the offer” to “I found the offer after the app opened,” which is useful when the campaign promise depends on a particular in-app page.

The Branch Flutter basic integration guide uses FlutterBranchSdk.listSession() to receive link-session data. Its example checks whether +clicked_branch_link is true to identify a Branch link click. That gives the developer a concrete point to connect incoming link data with the app’s own router and destination logic.

The Branch basic integration guide adds the package with flutter pub add flutter_branch_sdk and includes a FlutterBranchSdk.validateSDKIntegration() call for checking the integration. The guide says to remove that validation call after the check.

Choose Branch when link creation, routing, and attribution are one acquisition job. A team whose central need is a multi-channel paid campaign view should compare that link-led workflow with an MMP’s campaign reporting and event requirements. The categories can work together: product analytics can describe in-app behavior, a link tool can route users, and an MMP can organize paid-campaign attribution. A small team should assign each system a distinct job and decide which event source is authoritative for each metric.

Before using Branch links in a subscription campaign, map each URL to an in-app destination and a fallback destination for people without the app installed. Then test both paths on real iOS and Android builds. Confirm that a fresh install reaches the intended page, an existing install opens the intended page, and the downstream event is recorded once. Those checks keep routing behavior and campaign measurement aligned with what the creative promises.

3. Adjust: evaluate it for an SDK-based attribution and event workflow

Adjust fits a Flutter team evaluating an MMP workflow for campaign attribution and in-app events, with deep linking as an optional implementation need. Adjust's SDK integration guide describes an open-source SDK for attribution and in-app event measurement. Adjust has developers customize the SDK integration for selected features, including deep linking.

Adjust lists Admin, Editor, or Custom Editor as permissions needed for SDK integration. Assign the required account access before implementation begins.

The practical question for a Flutter project is whether the current Adjust integration path covers the Flutter version, iOS target, Android configuration, and app architecture in production. Keep the selected SDK version, native requirements, app identifiers, and initialization order together in the implementation ticket.

Define the app events the integration needs to measure, such as trial start or paid conversion, before selecting SDK features.

For a small team, compare expected engineering work as carefully as the dashboard. The work includes adding the package, configuring each native platform, defining events, testing install attribution, and keeping the integration current as the app changes.

4. Airbridge: choose it for supported paid channels and revenue/funnel reporting

Airbridge fits a Flutter subscription app buying campaigns on Google, Meta, Apple Ads, or TikTok when the team also needs revenue and funnel reports. Airbridge Core attributes campaigns on Google, Meta, Apple Ads, and TikTok, and includes revenue and funnel reports. That aligns the tool with a founder asking which of those paid campaigns bring users into the app and how their post-install path progresses.

Core also includes direct and deferred deep linking, branded short links, QR codes, and web-to-app banners.

Airbridge also provides an official Flutter implementation path. Airbridge's Flutter SDK setup includes separate initialization guidance for iOS and Android and a Flutter SDK Test to verify installation.

Airbridge Core pricing is a 30-day free trial followed by $40+/mo. Airbridge’s plan terms include 500,000 data points a month, then $0.0001 per additional data point, with no annual contract. For a founder watching paid acquisition costs, that usage-based model is easier to evaluate when the team forecasts expected data points and the resulting overage alongside media spend.

For example, if Airbridge collects 600,000 data points in a month, the first 500,000 are included and the extra 100,000 cost $10 at $0.0001 per additional data point.

A good Airbridge evaluation starts with event definitions. Decide how the app records the events that reflect the subscription funnel, then check that the same event means the same thing in the product and campaign report. A “trial started” event should fire at the actual trial start, for example, not when someone merely views a paywall. Revenue reporting is most useful when the team’s transaction events carry a consistent value and currency and are tied to a reliable purchase source.

Treat the billing system and attribution SDK as separate parts of the event path, and define how purchase and subscription events reach the reporting workflow you intend to use.

Airbridge Flutter SDK 4.11.0 and later requires an iOS deployment target of 12.0 or later and supports CocoaPods and Swift Package Manager. For SDK 4.11.0 and later, set platform :ios in the Podfile and the Xcode iOS Deployment Target to 12.0 or later.

Airbridge SDK settings use an airbridge.json file in the Flutter project and declare that file under Flutter assets. For SDK 4.11.0 and later, this asset declaration is a setup step added to the documented flow; on iOS installations using Swift Package Manager, the SDK settings are not applied without it. Teams upgrading from SDK 4.10.0 or earlier should include the asset declaration in the upgrade work.

5. AppsFlyer: evaluate the Flutter plugin with your campaign and link requirements

AppsFlyer belongs on the list when a team is evaluating an MMP with a documented Flutter plugin and wants to assess its wider campaign-measurement workflow. The AppsFlyer developer hub lists a Flutter plugin and links to the official appsflyer-flutter-plugin repository. The hub also organizes developer materials for in-app events and OneLink deep linking, giving the team distinct implementation paths to assess.

For a Flutter developer, the first decision is whether the plugin’s current version supports the project’s Flutter and native platform targets.

AppsFlyer can make sense when the acquisition team wants campaign-level attribution and has a concrete event and link plan to validate. Create test cases for a new install from a campaign, a returning user opening a link, and a post-install conversion event. Those cases let the team check that the user journey, event payload, and campaign report tell the same story before it shifts budget based on early results.

A Flutter attribution setup to validate before launch

Treat launch validation as a sequence. The order matters because a working SDK cannot make a poorly defined event useful, and a valid campaign event cannot route someone to the right screen unless the links are configured.

1. Write the reporting question and event plan. List the acquisition decisions the team expects to make, then name each event and define exactly when it fires. For a subscription app, the core set often includes account creation, trial start, paid conversion, and renewal. Choose one source of truth for each event and document value, currency, and plan fields where relevant.
2. Pick the tool by job. Use analytics for in-app activity, a link-led product for destination routing and link attribution, and an MMP when campaign-to-install and post-install reporting drives the decision. Keep a separate owner and purpose for each SDK in the app.
3. Confirm package and native requirements. Compare the provider's documented Flutter release, iOS deployment target, Android configuration, and initialization steps with the versions in your app. For Airbridge, run the Flutter SDK Test after installation. Build those precise instructions into the same ticket as the Flutter dependency update.
4. Configure the campaign fields and events. Use a consistent campaign naming convention across links and reporting. For an MMP, define the event mapping and any server-to-server or billing events required by your chosen implementation.
5. Set up app links when the journey needs them. Flutter's Android App Links recipe and iOS Universal Links recipe describe links that open a specific app screen through a URI with a scheme, host, and path. Android verification also needs an app-to-domain association; the Android App Links guide explains the website association and assetlinks.json file. Test the domain association on a device before campaign launch.
6. Check Flutter's deep-link handler and plugins. For iOS apps, Flutter's Universal Links recipe warns that Flutter's default handler can break third-party deep-link plugins; it calls for manual opt-in before Flutter 3.27 and setting FlutterDeepLinkingEnabled = NO when a third-party plugin handles links. Match the recipe to the Flutter version and plugin combination actually in the project.
7. Run clean-install and return-user tests. Test a campaign link with the app installed and on a device where the app is absent. Verify the destination, fallback, attribution parameters, first-open behavior, and one post-install event. Repeat on iOS and Android, following each platform's setup.
8. Check event quality before moving spend. Confirm timestamps, event counts, currency, value, and campaign labels in the report. Compare a small set of controlled test journeys with the app's own event logs. Then use the validated report to decide which campaign or product step deserves the next change.

Google's Install Referrer API response includes the referrer URL, client- and server-side click and installation timestamps, and the app version at first install. Run the referrer check through a Google Play distribution build so it matches the store path your users take.

Google's Install Referrer requirements specify a Google Play Store app version of 8.3.73 or later and a Google Play Console account. Per Google's API reference, the referrer information remains available for 90 days and does not change unless the app is reinstalled; Google recommends invoking the API once during the first execution after installation.

For iOS, validate what the attribution report can show under the app's privacy authorization and the privacy-preserving measurement method in use.

Bottom line

Before shifting paid spend, verify in one test journey that the chosen campaign source and its downstream subscription event appear together in the reporting workflow. Airbridge is a fit when Google, Meta, Apple Ads, or TikTok are in scope and its Flutter SDK, revenue reports, funnel reports, and usage-based Core Plan match the app. Validate native setup, privacy behavior, links, and event quality on both platforms before using attribution results to move budget.