attribution

Also called: mobile attribution, marketing attribution, install attribution, attribution model

Assigning credit for a new user or purchase to a channel or campaign. On mobile it now relies on privacy-preserving store frameworks with aggregated, delayed data.

Attribution decides which channel or campaign gets the credit for an install, a signup or a purchase. Classic web attribution follows one person across touchpoints and applies a rule: last touch, first touch, or credit split across several touches (multi-touch).

Mobile attribution in 2026 works under much tighter privacy rules:

Tracking needs permission. On iOS, linking a user across other companies' apps and sites requires the user's explicit consent, and a large share of users decline. On Android the advertising ID can be reset or deleted by the user, and platform privacy rules keep evolving. Covert fingerprinting (matching devices by IP address and device traits) is against the platforms' rules.
The app stores' privacy-preserving attribution frameworks fill the gap. When an ad leads to an install, the platform itself sends the advertiser a report (a postback) that the campaign produced an install, plus a coarse conversion value the app sets from early in-app behavior. These reports are aggregated (no user IDs), delayed by a random interval, arrive in a few time windows over the first weeks, and include less detail for small campaigns so that no individual can be singled out.
Your own links stay deterministic. Invitation links, referral links and deep links you generate yourself tell you exactly where a user came from, because they're first-party data.

The practical consequence: user-level, real-time ROI per ad is gone for most paid traffic. Teams combine several imperfect views: store-framework postbacks for campaign-level results, first-party links for owned channels, cohort LTV by channel where it can be observed, incrementality tests to check what paid spend really adds, and increasingly marketing mix modeling, which estimates each channel's contribution statistically from spend and outcomes over time. The "organic" bucket always contains some installs that paid campaigns actually drove but couldn't be attributed.

Example

Halves gets 12,000 installs in October. Theo's attribution view:

Source	Installs	How it's known
Invitations	3,600	Halves' own invite links (exact)
Store search ads	700	the store's campaign report
Paid social	2,100	store-framework postbacks (aggregated, delayed)
Unattributed ("organic")	5,600	everything else
Total	12,000	3,600 + 700 + 2,100 + 5,600 ✓

The paid social platform's own dashboard claims 3,000 installs, 900 more than the postbacks, because it also counts users who only saw an ad and uses its own modeling. Neither number is "the truth": the postbacks miss installs where the details were withheld or the report hadn't arrived yet (the last days of October are still incomplete), and the platform's claim includes users who would have installed anyway.

Theo reports paid social as "2,100 attributed installs, some share of the 5,600 organic installs likely also paid-driven; incremental effect to be checked with a geo test", rather than picking the flattering 3,000.

Common mistakes

Adding up every platform's claims. Each channel's dashboard credits itself; the sum often exceeds your real installs.
Reading the last few days as final. Store-framework reports arrive with a delay; recent periods always look weaker until they settle.
Treating "organic" as free users. Part of it is paid traffic that couldn't be attributed; cutting spend can shrink "organic" too.
Equating attribution with causation. Being credited with an install doesn't mean the ad caused it; test incrementality.
Chasing user-level data with fingerprinting. It breaks platform rules and privacy laws; design for aggregated data instead.