Mobile Attribution Explained: How It Works & How to Set It Up

Mobile attribution is the process of linking a user's install — and the events they trigger inside your app afterwards — back to the specific ad, campaign or channel that brought them in. It is the difference between knowing "we got 10,000 installs last month" and knowing "8,200 of those came from three campaigns, and only one of them produced paying users". One of those statements lets you make a spending decision; the other does not.

The problem attribution solves is structural. On the web, a tracking cookie and a redirect can follow a user from click to conversion on the same browser. On mobile, the journey crosses a hard boundary: a user taps an ad inside one app or browser, gets handed to the App Store or Google Play, installs your app, and opens it in a completely separate sandboxed environment. Nothing about that flow connects the two halves automatically. Attribution is the machinery that rebuilds the link across that gap.

It matters because every meaningful user acquisition decision depends on it. Cost per install, return on ad spend, the lifetime value of a cohort, which creative to scale, which network to cut — all of it is unknowable until you can say with confidence which spend produced which users. Without attribution you are not optimising a budget; you are guessing and calling it strategy.

It also matters because mobile budgets are unforgiving. A misattributed channel does not just waste the spend on that channel — it pulls budget away from the channel that actually works, so the cost compounds in both directions. The faster you can trust your numbers, the faster you can cut what is not working and double down on what is. That speed of confident reallocation, more than any single clever tactic, is what separates campaigns that scale profitably from campaigns that quietly burn cash.

Across our 300+ apps managed since 2013, the single most common reason a paid channel gets mis-judged is broken or naive attribution. A network looks cheap because it is claiming installs it did not cause, or a strong channel looks weak because its conversions are being credited elsewhere. Get the measurement right and the budget reallocations usually follow on their own.

Attribution works as a chain of four events: a user clicks an ad, the click is logged with identifiers, the user installs and opens your app where an SDK fires a signal, and a measurement platform matches that install signal back to the recorded click — then sends a postback crediting the campaign. Each step exists to carry information across the install boundary that the operating system otherwise breaks.

Walk it through concretely. When a user taps an ad, the ad network records that engagement — the timestamp, the campaign, and whatever device or identifier signals are available. The user lands on the store, installs, and opens the app. On first open, the attribution SDK embedded in your app sends a "new install" signal to the measurement platform along with the device's available signals. The platform compares that install against the pool of recent clicks, finds the best match, and decides which click — and therefore which campaign — earned the credit.

The final step is the postback: the measurement platform notifies the ad network "this install you claimed was attributed to your campaign", and notifies your own dashboards the same. That loop is what lets a network optimise its delivery and lets you compare channels on equal terms. Both AppsFlyer's attribution resources and Adjust's documentation describe this same click-install-match-postback shape, because it is the underlying model the whole industry shares.

The nuance is that "find the best match" is doing a lot of work in that sentence. How the platform matches a click to an install — and how confident it can be — is the heart of attribution, and it is where deterministic and probabilistic methods, lookback windows, and privacy rules all come into play. The rest of this guide unpacks that.

A mobile measurement partner (MMP) is a neutral third-party platform that sits between your app and every ad network, collects clicks from all of them, receives the install signal from one SDK in your app, performs the matching, and gives you a single deduplicated view of performance across channels. It is the referee that no individual ad network can be.

The neutrality is the whole point. If you trusted each ad network to report its own results, you would get a wildly inflated picture: two networks will both claim the same install because each saw a click, and self-reported numbers are never adjusted downward. An MMP applies one consistent set of rules across every network, deduplicates overlapping claims, and decides credit once. That is why the output is called a single source of truth.

Beyond matching, a modern MMP does several jobs at once: it records in-app events (purchases, sign-ups, subscriptions) so you can measure quality and not just install volume, it handles the privacy-preserving frameworks on each platform, it powers cohort and ROAS reporting, and it pushes clean data into your wider analytics and dashboarding stack. The SDK you integrate is the same regardless of how many networks you run, which is what makes an MMP scalable.

The three names you will encounter are AppsFlyer, Adjust and Singular, and they differ on pricing model, data-freshness, and feature depth rather than on the core mechanics. We have compared them in detail in our AppsFlyer vs Adjust vs Singular breakdown, so we will not re-derive that here — the relevant point for this guide is that whichever you pick, the job it performs is the one described above. In our portfolio, the teams that pick an MMP early and integrate it cleanly spend far less time later arguing about whose numbers are right.

A self-attributing network (SAN) — Google, Meta, TikTok, Apple Search Ads and a handful of other walled gardens — runs its own attribution internally and reports the installs it claims directly to your MMP, rather than letting the MMP independently match the click to the install. They are the large exception to the clean click-install-match-postback model, and reading your reports honestly means understanding why they behave differently.

The reason is structural. These networks operate closed ecosystems where the ad engagement and a logged-in user identity both live inside the same platform, and they do not expose click-level data to third parties. So the matching flow is inverted: your MMP sends the network a record of each new install, the network checks that install against its own logged-in engagement data on its side, and returns a verdict — "this install was mine" or not. The MMP then applies dedup and priority logic across every SAN claim plus its own deterministic and probabilistic matches, and decides final credit.

That inversion is the core difference. With an ordinary ad network, your MMP is the referee holding both halves of the evidence; with a SAN, the network is effectively grading its own homework and the MMP can only arbitrate conflicts and remove duplicates. Each SAN also applies its own attribution windows and view-through rules, and those defaults differ from one another, so two SANs reporting side by side are not measuring on the same basis until you normalise their windows. The standard definitions and window behaviour are documented in the MMP glossaries the whole industry shares.

The practical implication is that SAN-reported installs cannot be re-derived from raw logs the way an open network's can, so you cannot fully audit them after the fact. The discipline we apply across our portfolio is to trust but verify: lean on the MMP's dedup, run holdout and incrementality tests against SAN-claimed installs, and watch the organic baseline for sudden dips that mean a SAN is simply re-labelling installs you would have won anyway. The most common silent overstatement we see is two walled gardens both window-claiming the same install through generous view-through windows — neither is lying by its own rules, but the budget decision built on the doubled count is wrong.

Deterministic matching links a click to an install using an exact, shared identifier — so the match is certain — while probabilistic matching infers the link statistically from signals like IP address, device characteristics and timing, producing a confident estimate rather than a fact. The trade-off is precision versus coverage, and privacy rules have reshaped which one you can rely on.

Deterministic is the gold standard because it removes guesswork. The classic example is the device advertising identifier: when both the click and the install carry the same ID, the match is unambiguous. On Android, the Google Play Install Referrer plays a similar role by passing a referrer string from the store through to first open. When a deterministic signal is available, you should always prefer it — there is no estimation involved.

It helps to name the actual identifiers, because the privacy story is really a story about which of them you can still use. On iOS the cross-app advertising identifier is the IDFA, and since ATT it is only available when the user opts in; the IDFV (vendor identifier) survives but only scopes a single publisher, so it cannot link a click in one app to an install in another. On Android the equivalent is the Google Advertising ID (GAID), which a user can reset or, on newer OS versions, opt out of so it returns zeros. The shrinking availability of these consented IDs is exactly why a method that used to cover most installs now covers a declining share, and why the store referrer has become disproportionately valuable as the one deterministic signal Android still hands over freely.

Probabilistic matching steps in when no shared identifier exists. The platform looks at signals that are available on both sides — IP address, device model, operating-system version, the time gap between click and install — and calculates the most likely click that produced the install. It is genuinely useful, but it is an inference, and its accuracy degrades when many similar devices share a network or when the time window is wide. It is also the method most constrained by platform privacy policies, because it leans on device characteristics rather than consented identifiers — Apple in particular treats this kind of fingerprinting as off-limits regardless of ATT status, so its role on iOS is far smaller than it once was.

There is also a data-freshness reality that the deterministic-versus-probabilistic framing hides. Deterministic, user-level matches can appear in your dashboard within minutes, which is what makes same-day optimisation possible on the channels where they apply. The privacy-preserving frameworks deliberately do the opposite: postbacks arrive after a randomised delay measured in hours or days, deduplicated and aggregated, so a portion of your paid reporting is structurally late and lower-resolution no matter how good your setup is. Treat "the number is not in yet" as a normal state for that slice of installs rather than a bug, and never compare a fully-settled cohort against one that is still receiving delayed postbacks.

The practical reality in 2026 is a layered approach: use deterministic matching wherever a consented identifier or store referrer is available, fall back to probabilistic where rules permit it, and rely on the platform's privacy-preserving frameworks where neither is possible. No single method covers every install, which is exactly why the measurement stack has grown more than one layer — a theme we return to below.

An attribution model is the rule that decides which touchpoint gets the credit when a user saw several ads before installing — last-click gives all the credit to the final click within a lookback window, while multi-touch distributes credit across the journey. The model you choose silently determines which of your channels look profitable, so it is a decision, not a default to accept blindly.

Last-click attribution is the industry standard and what most MMPs apply out of the box. It is simple and reproducible: the last ad engagement before install, inside a defined lookback window, wins the install. Its weakness is obvious — it over-credits the channels that sit closest to conversion, like retargeting and high-intent search, and under-credits the upper-funnel channels that created demand in the first place.

The lookback window itself deserves more attention than most teams give it, because it is really two windows that behave differently. The click-through window governs how long after a click an install can still be credited to it, and is conventionally set to a few days because a click is a strong, intentional signal. The view-through window governs the same for an impression a user merely saw, and is deliberately kept much shorter — often a single day or less — because a view is a far weaker claim and a long view-through window is the single easiest way to let a network over-count installs it barely influenced. The two windows should never be the same length, and the moment you compare channels you must confirm they are all being judged on the same windows, or the comparison is meaningless. Returning users add a third kind of window — a re-engagement or inactivity window — which we cover in its own section below.

Multi-touch models try to correct that by splitting credit across multiple touchpoints — evenly, or weighted toward first and last, or by a custom rule. They give a fairer picture of how channels assist one another, but they are harder to implement, harder to explain to stakeholders, and still fundamentally based on the touchpoints your tracking happened to capture. View-through attribution — crediting an impression a user saw but did not click — adds another layer of judgement and is the easiest place to accidentally over-count.

Our working guidance is to run last-click as your operational default because it is consistent and comparable, but never to mistake it for truth about causation. Last-click tells you correlation with the final touch; it cannot tell you whether a channel actually caused incremental installs. That gap is precisely what incrementality testing exists to close, and we treat the two as complementary rather than competing.

An in-app event taxonomy is the deliberate, documented schema of which user actions you record, what you name them, and what parameters they carry — and it matters because attribution that stops at the install tells you volume, while events tell you value. A campaign that delivers cheap installs which never register, purchase or subscribe is not a cheap campaign; it is an expensive mistake measured at the wrong moment.

It helps to separate two layers of events. Structural events — install, first open, session start — are reported by the SDK automatically and tell you that someone arrived. Business events — registration, add-to-cart, purchase, subscription start, trial-to-paid conversion, and whatever your particular "aha moment" of activation is — are the ones you instrument deliberately, and they are what let you judge a channel on the quality of the users it sends rather than the count. A clean taxonomy is mostly discipline about the second layer: one canonical name per event, a single consistent naming convention, and no drift into "purchase" versus "Purchase" versus "buy" across teams and platforms.

Parameters are the other half of the schema. A purchase event is far more useful when it carries a revenue value and a currency, because that is what lets your MMP compute return on ad spend by cohort instead of just counting conversions. Get the parameters right once and the same events power ROAS, cohort lifetime-value curves, the optimisation signals you send back to self-attributing networks, and the conversion-value mapping on iOS — they all feed from the same well. A messy taxonomy poisons all of it at once, which is why renaming or restructuring events after you have scaled is so painful: it orphans the historical data you were relying on to make the decision.

The iOS privacy frameworks make taxonomy discipline non-negotiable rather than nice-to-have. SKAdNetwork and AdAttributionKit give you only a tiny fixed budget of bits to encode what happened after an install, so your conversion-value schema is literally your event taxonomy compressed into a few signals — and you cannot compress a mess. In our portfolio, the apps that defined a tight event taxonomy on day one had usable cohort ROAS within weeks; the ones that bolted events on later spent a quarter reconciling names before any number could be trusted. Define it before you scale, not after.

Deep linking routes a user to a specific in-app destination instead of the generic home screen, deferred deep linking preserves that destination across the install boundary, web-to-app attribution credits a mobile-web touchpoint with the app install it produced, and re-attribution and re-engagement decide how a returning user gets credited. These are the parts of attribution that govern returning and cross-surface users rather than first-time installers, and they are where most setups quietly leak.

Deferred deep linking is the mechanism that makes a paid click feel coherent. When a user taps an ad for a specific product, the click carries a payload — which product, which promotion — and if the user has to install first, that context would normally be lost across the install boundary. Deferred deep linking stores the payload, retrieves it on first open, and routes the new user straight to the intended screen instead of dumping them on a blank home page. It is also an attribution signal, because on Android that deferred payload travels inside the install referrer, giving you a deterministic carrier of campaign context as well as a better first experience.

Web-to-app and cross-platform measurement handle journeys that do not start in an app at all. Plenty of users meet you first on mobile web or desktop, and attribution there stitches a web click to an app install via the click record and the store referrer. True people-based, cross-platform measurement — recognising one human across web, iOS and Android — needs either a logged-in identity you control or a self-attributing network that already has one; without an identity to anchor on, cross-device stitching is probabilistic at best and should be read as an estimate, not a headcount.

Re-attribution and re-engagement are easy to conflate and costly to get wrong. Re-engagement means a campaign brings an already-active user back and earns credit for that touch within a re-engagement window. Re-attribution means a lapsed user — one who has been inactive beyond a defined inactivity window — is credited to a new campaign almost as if they were a fresh acquisition. The distinction matters because counting a re-engaged active user as a brand-new install double-counts your audience and flatters the campaign; setting the inactivity window deliberately is what keeps the two from blurring. On iOS, AdAttributionKit added re-engagement support so this returning-user credit can work inside the privacy-preserving model rather than outside it.

On iOS, App Tracking Transparency (ATT) requires user consent before an app can access the device identifier for cross-app tracking, and where consent is absent, Apple's SKAdNetwork — and its successor AdAttributionKit — provide privacy-preserving, aggregated attribution instead of user-level matching. This is the single biggest structural change to mobile measurement in the last several years, and it deserves its own treatment.

The short version: when a user does not grant ATT permission, your MMP cannot use the advertising identifier to match that user's click to their install deterministically. Industry opt-in rates have settled at roughly 35-50% in 2025 depending on the measurement methodology, which means a large share of iOS installs must be measured through Apple's frameworks rather than classic device-level attribution.

Those frameworks work differently by design. SKAdNetwork returns attribution via aggregated, delayed postbacks with deliberately limited conversion detail, so no individual user can be identified. Its successor, AdAttributionKit, extends the model with capabilities like re-engagement and view-through support while keeping the same privacy-first, aggregated philosophy. The practical effect is that paid-iOS reporting trades granularity for privacy.

The mechanics here change often enough that re-stating them in depth in a pillar would date quickly, so we keep this section deliberately brief and maintain a dedicated explainer instead. For the full comparison of how the two frameworks differ — postback structure, conversion values, what AAK adds — read our AdAttributionKit vs SKAdNetwork guide. The takeaway for this pillar is simply that iOS attribution is now a blend of consented user-level data and aggregated framework data, and any honest setup accounts for both.

Attribution fraud is any technique that fakes or steals credit for an install — click flooding, click injection, SDK spoofing, device farms and bots — and you defend against it with a combination of your MMP's fraud-protection layer, conservative attribution windows, and healthy scepticism toward any channel whose numbers look too good. Fraud is not only wasted spend; it corrupts the very data you use to allocate the rest of the budget, so it does double damage.

It is worth knowing the main techniques by name, because each leaves a different fingerprint. Click flooding (or click spamming) fires huge volumes of fake clicks hoping to win last-click credit for installs that were actually organic — its tell-tales are an abnormally low click-to-install rate and unusually long times between click and install. Click injection, an Android-specific attack, uses malware that detects an install beginning and injects a click at the last possible moment to steal the credit, which shows up as a near-zero time-to-install. SDK or install spoofing manufactures install signals that never came from a real device at all. Device farms and bots produce real-looking engagement at scale, betrayed by reset device IDs, anomalous conversion patterns, and events that never progress past the first step.

Detection is mostly the statistics of those fingerprints: the distribution of click-to-install times, conversion-rate anomalies, spikes in the ratio of brand-new devices, and funnels where installs arrive but value events never do. Modern MMPs ship fraud-protection modules that reject these patterns before attribution, so the fraudulent installs never enter your reports in the first place — the taxonomy of attacks and signals is documented in AppsFlyer's attribution and fraud glossary. The privacy frameworks incidentally close some vectors too, because an attacker cannot spoof a device ID that the framework never exposes, though aggregated postbacks introduce their own gaming concerns in exchange.

Prevention is mostly about sequencing and temperament. Enable the fraud layer from day one rather than after you have been burned, set your windows conservatively so flooding has less room to claim organic installs, and treat any channel whose self-reported numbers wildly beat your MMP as guilty until audited. We have caught networks across our portfolio whose impressive "performance" evaporated the instant a fraud filter and a holdout test were applied at the same time — the spend had been buying noise, and only a neutral count revealed it.

Setting up attribution correctly is a five-step sequence: pick one MMP, integrate its SDK once, define the in-app events that actually matter, wire each ad network's postbacks and tracking links, then validate the whole loop with test installs before you trust a number. Skipping the validation step is the mistake that quietly corrupts months of reporting.

1. Choose one MMP and commit to it: running two MMPs in parallel doubles cost and creates two conflicting sources of truth. Pick based on your platform mix, budget and reporting needs — our comparison covers the trade-offs.
2. Integrate the SDK cleanly: the SDK is the single component that reports installs and events. Integrate it once, initialise it on app launch, and make sure it fires before any event you care about can occur.
3. Define real events, not vanity ones: map the events that signal value — registration, purchase, subscription start, key activation — so you measure quality, not just install volume. On Android, confirm the Google Play Install Referrer is captured so store-side deterministic signals are not lost.
4. Wire the network postbacks and links: connect each ad network so attributed installs flow back to it, and configure the iOS privacy frameworks alongside classic tracking so your consented and aggregated data both land. Set your click-through and view-through windows here deliberately, and make them identical across networks so channels are judged on the same basis.
5. Configure deep links and the conversion-value schema: set up deferred deep linking so paid users land on the right screen rather than the home page, and map your in-app events into the iOS conversion-value bits before you spend, because that schema cannot be backfilled for installs that already happened.
6. Validate end to end: run real test installs from each channel and confirm the click, install and event all appear, correctly credited, in the dashboard. Do not assume — verify the loop closes for every network, and account for the framework latency so you do not mistake a delayed postback for a broken one.

The reason validation is non-negotiable is that attribution failures are silent. A mis-configured postback does not throw an error; it just under- or over-reports, and you only discover it when a budget decision built on bad data goes wrong. Build a short repeatable test plan — a known click, a known install, a known purchase event, checked against the dashboard for every live network — and re-run it whenever you add a network, change a window, or ship a major release, since each of those can break the loop without warning. Our analytics team runs exactly this validation as standard before any client trusts a campaign number.

The most common attribution mistakes are trusting self-reported network numbers, never validating the setup, treating last-click as proof of causation, mis-configuring lookback windows, and ignoring the iOS privacy frameworks until they distort a report. None are exotic; all are avoidable; together they account for most of the bad measurement we encounter.

• Trusting network self-reporting: ad networks over-claim by design. If a channel's own numbers look far better than your MMP's, the MMP is almost always closer to the truth — the deduplicated, neutral count is the one to spend against.
• Skipping validation: an unvalidated setup can run for months before anyone notices an event is not firing or a postback is mis-mapped. We have seen entire optimisation cycles wasted on data that was wrong from day one.
• Confusing correlation with causation: last-click tells you which touch came last, not which spend was incremental. Scaling a channel purely on its last-click ROAS is how teams pour budget into demand they would have captured anyway.
• Mishandling lookback windows: windows that are too long inflate credit and let one channel claim installs it barely influenced; too short and you lose legitimate conversions. Set them deliberately and apply them consistently.
• Ignoring iOS frameworks: pretending classic device-level attribution still covers all iOS installs leaves a large, growing blind spot in your paid reporting.

The honest conclusion is that attribution is necessary but not sufficient. It tells you who got credit under a set of rules; it does not, on its own, tell you what your marketing actually caused. That is why the mature measurement stack layers attribution with incrementality testing and media-mix modelling — the deeper spokes this pillar points to. If you want this built and validated properly rather than assembled from defaults, talk to our team and we will set it up so the numbers you act on are ones you can trust.