Mobile attribution for a Flutter subscription app

The scenario

A fictional subscription app is preparing to test paid acquisition. The marketing team needs campaign reporting, while the product team needs to understand onboarding and trial activation. The reference setup would give those teams a shared event vocabulary without expecting two analytics systems to produce identical counts.

Write one event plan with clear owners

Define a small set of meaningful events: onboarding completed, trial started, subscription renewed, and subscription cancelled. Each event would have an owner, trigger, timestamp meaning, and property schema. A purchase button tap would be a different event from a server-confirmed subscription.

AppsFlyer’s Flutter plugin would provide the mobile attribution integration. Amplitude would receive the product events needed for activation and retention analysis. A shared analytics adapter in the app could map domain events to each destination, keeping vendor-specific names out of individual screens.

Treat identity and attribution as separate concerns

An internal account identifier would connect authenticated activity where the configuration and permissions allow it. The team would document what happens before login, after logout, and when two devices use one account. Email addresses would not be used as convenient analytics identifiers.

Deep links would resolve to an allowlisted destination in the app. Tests would cover an installed app, a fresh install, a logged-out user, and an expired destination. Platform privacy settings and SDK configuration would be tested explicitly; missing campaign data would not be filled with a guessed attribution value.

Reconcile definitions before reconciling dashboards

Subscription confirmations would come from the billing source of truth. The backend would record a stable event ID and forward eligible events to the selected analytics destinations. A retry would preserve that identity. For Amplitude HTTP V2, insert_id is a deduplication aid within its documented device and time scope, not a replacement for backend event ownership.

A release checklist would compare test journeys across the app, backend, MMP, and product analytics. Differences would be investigated using event definitions, reporting windows, time zones, and attribution rules. A written reconciliation note is more useful than forcing every dashboard to show the same number.

What to validate

• A trial starts only after the defined source confirms it.
• Login and logout do not attach another account’s events.
• Deep links work across install and authentication states.
• Test events are separated from production reporting.

The tradeoff

Sending every event to every tool increases noise and maintenance. Keep the initial event plan small, choose one MMP for attribution, and expand collection only when there is a specific product or campaign question.