What is a reinstall?

Why it must be separated

A reinstall is not an acquisition. The user was already acquired, left, and came back — which is a retention outcome rather than a growth one.

Counting reinstalls as new installs inflates acquisition figures and understates true acquisition cost, because you are paying to reacquire someone you already paid for once. In products with high churn and active re-engagement campaigns, reinstalls can be a substantial share of what a blended install count reports.

The related distinction is with reattribution: a reattribution credits a returning user to a campaign, whether or not they reinstalled.

What reinstalls signal

• A high spontaneous reinstall rate suggests the product has real value the user missed — usually good news buried in a churn number.
• Reinstalls driven by campaigns need the same causal scepticism as any re-engagement activity.
• Reinstall then immediate churn points at an unresolved problem the user hoped had been fixed.
• Device change produces reinstalls that are not returns at all, and inflates the count on markets with fast device turnover.

How they are detected

Detection depends on recognising a device or user that was seen before, which the privacy changes made harder. Where a first-party account exists it is straightforward. Where it does not, platform-level signals are partial and imperfect.

In practice most teams accept that reinstall detection is incomplete, and the important discipline is to report the reinstalls they can identify separately rather than blending an unknown share of them into acquisition.