What Re-attribution Is
Re-attribution is how an attribution platform handles users who come back. A user installs your app from a Meta campaign in January, uninstalls in March, then sees a Google retargeting ad in May and reinstalls. Without re-attribution, that reinstall is either ignored as a duplicate or credited back to the January Meta campaign. With re-attribution, the May reinstall is credited to the Google campaign that actually brought the user back.
Re-attribution is what makes retargeting measurable. Without it, every campaign aimed at lapsed users looks like it drives nothing.
The Two Windows
Two settings decide whether a returning user can be re-attributed.
The inactivity window is the minimum time a user must have been inactive before a new campaign can claim them. A 7-day inactivity window means a user who opened the app 3 days ago cannot be re-attributed, while one who last opened it 10 days ago can. The window keeps retargeting from taking credit for users who were already active.
The re-attribution window is the maximum gap between uninstall and reinstall for the reinstall to count as a return. Past that gap, the user is treated as a new install, because their earlier history is too old to matter.
Separately, the campaign's own click must fall inside the lookback window, just as it would for a new install.
Re-attribution Versus Re-engagement
The terms overlap and are often used loosely.
- Re-attribution usually means a reinstall: the user removed the app and installed it again through a campaign.
- Re-engagement means the user still has the app and opens it through a campaign, usually a deep link in a retargeting ad, push or email.
Both credit the comeback to the campaign that caused it, and both sit in retargeting reports rather than user acquisition reports.
How Reinstalls Are Detected
To re-attribute a reinstall, the platform has to recognize the returning device or user. Common methods are:
- the advertising ID on Android, or the IDFA on iOS when the user granted ATT consent,
- data the app restores from device backup on reinstall,
- a customer user ID or login that links the new install to an existing account.
On iOS, users who decline ATT are hard to recognize as returning, so some reinstalls are counted as new installs. See reinstall for more.
Re-attribution in Linkrunner
Linkrunner re-attributes returning users through two reactivation events: an app reinstall after the user uninstalled, and a deep link open by a user who still has the app. For a user to be re-attributed, they must have been inactive for at least the inactivity window, which defaults to 0 days and is based on the last app open, and a reinstall must happen within the 90-day re-attribution window.
Reinstall detection uses GAID on Android and IDFA on iOS, with Android backup configured in the SDK. On iOS, ATT permission is needed for reinstall re-attribution. Deep link re-engagement needs deep linking set up and the SDK's handleDeepLink function called on open.
On the Campaigns page, the Retargeting view splits returning users into reinstalls and re-engagements per campaign, and the reporting API returns the same numbers. Re-attributed installs are billed like any attributed install; re-engagements are free. See retargeting.
Setting the Windows
- Short inactivity window for apps used daily, where a few days away is a meaningful lapse.
- Longer inactivity window for apps used occasionally, such as travel or shopping, so retargeting only claims users who had really drifted.
- Check network settings. Ad networks have their own re-engagement windows. Align them where you can, or expect gaps between network and MMP retargeting numbers.