Festive Installs: New Users or Returning?

Your festive install count doubles. How many of those people already had your app?

Most teams cannot answer that question, and the ones who can usually find the number higher than they expected. It matters because the two groups cost different amounts to acquire, behave differently afterwards, and should be measured against different targets. Counted together, they produce a cost per acquisition figure that is wrong in a direction that flatters you.

What is a reattribution, and why does it cluster during festive?

A reattribution is an install event credited to a new campaign for a user who had already installed the app previously. The user is being re-acquired rather than acquired, even though most dashboards count them together.

It happens when someone who installed months ago, then went quiet or uninstalled, taps an ad and comes back. The prior attribution window has closed, so the new campaign takes credit. That credit is legitimate. The campaign did cause the return. The problem is only that the event lands in the same bucket as a genuinely new user.

Festive concentrates these for structural reasons:

• Reactivation budget peaks. Lapsed-user campaigns, dormant-user pushes and win-back offers all get scheduled into the festive window because that is when the offer is strongest.

• Retargeting spend rises alongside acquisition spend, and the two run simultaneously against overlapping audiences.

• Broad targeting reaches your own users. At festive budgets, prospecting campaigns widen until they inevitably serve people who already know you.

• Seasonal apps have large dormant bases by definition. If usage is concentrated around festivals, most of your user base is dormant in September.

So the same window that inflates your install count also inflates the share of that count which is not new.

Why this is expensive to get wrong

Three compounding costs.

You pay acquisition prices for retention outcomes. Winning back a lapsed user is usually cheaper than acquiring a stranger. If both sit in one campaign measured against one target, you will happily pay new-user rates for returning users and conclude the campaign is performing.

Your cost per install looks better than it is. Reattributions add to install volume. More installs against the same spend means a lower cost per install, which reads as improved efficiency. It is not efficiency. It is a denominator change.

Your lifetime value models degrade. Lifetime value models trained on mixed cohorts learn from two populations with different curves. Returning users often monetise faster, because they already know the product, which makes early revenue look strong and late revenue disappoint. The model is not wrong. The cohort definition is.

This is the same class of error as counting paid installs that would have happened organically, covered in our piece on how paid installs cannibalise organic growth. In both cases the attribution is defensible and the decision built on it is not.

What mixed cohorts actually look like

We are not going to quote a reattribution rate benchmark here, because we do not have one we would stand behind. Across Linkrunner projects the retargeting view returns too little volume to publish a defensible figure, which itself tells you something: most app teams are not separating these campaigns in the first place.

What we can show is how wide the gap gets between install counts and real users, which is the same measurement problem viewed from a different angle.

Across roughly 4.7 million installs at around 50 India-based apps running paid campaigns on Linkrunner between May and July 2026, the share of installs that reached the app's own defined activation event varied enormously:

• Median activation: around 67 per cent

• Middle half of apps: roughly 52 to 81 per cent

• Bottom quarter: around 35 per cent

For the bottom quarter, cost per activated user came out close to three times their cost per install. For the top quarter, roughly 1.2 times.

The point is not the specific numbers. It is that "installs" is a category that hides at least two populations, and the gap between the headline number and the meaningful number varies by a factor of three across apps that all look similar from the outside. Reattribution is one of the seams along which that category splits. If you have never checked where your own app sits, festive is an expensive time to find out.

Methodology: Linkrunner projects with a connected ad network account and INR base currency, May to July 2026. Activation is each project's own defined onboarding event, so definitions vary by app.

How to separate them in your own reporting

The good news is that this is a reporting problem, not a data problem. The information exists at install level; it is usually just not being surfaced.

1. Find the reattribution flag. Attribution platforms mark install events that were re-credited rather than newly attributed. In Linkrunner this is available at install level and exposed through the Data APIs, so it can be segmented directly rather than inferred.

2. Build two cohorts, not one. Split acquisition and reactivation before the window opens. Two cohorts, two targets, two sets of creative.

3. Separate the campaigns themselves. Reporting separation is the minimum. Campaign separation is better, because it lets you bid differently.

4. Set different success metrics. Acquisition should be judged on cost per activated new user and 30-day retention. Reactivation should be judged on cost per returning active user and repeat transaction rate.

Do this before the window opens. Retrospectively splitting a mixed festive cohort in December means reconciling user identifiers against install dates across two months of data, and the answer arrives long after the decisions it should have informed. Our guide to defining cohorts covers the mechanics of getting the definition right up front.

What changes once you can see the split

Bid differently. Returning users have known value. You can bid more aggressively for them because your uncertainty is lower, and you should bid more carefully on prospecting because your uncertainty is higher.

Report differently. A campaign that is 60 per cent reattribution is a retention campaign wearing an acquisition campaign's clothes. Once you can see that, the conversation with whoever owns the budget changes from "acquisition is expensive" to "we are spending acquisition budget on retention, and here is what that is worth".

Budget differently. A high reactivation share is not automatically bad. Reactivating dormant users is often the cheapest growth available to a seasonal app, and treating it as a first-class objective with its own budget line usually produces better returns than letting it happen accidentally inside an acquisition campaign. Our post on attribution for re-engagement campaigns covers running it deliberately.

The retention question this raises

Reactivated users and genuinely new festive users retain on different curves.

Returning users have already survived one round of your onboarding, so they tend to hold better than new festive installs, at least initially. New festive installs, acquired under broad targeting into a discount-driven moment, tend to be your weakest cohort of the year.

Blend them and you get a retention curve that describes nobody. It looks acceptable in December, which is the problem, because it hides a new-user cohort that is underperforming badly enough to change your festive plan for next year.

Split them, and you get two honest curves and a real answer to whether festive acquisition is worth repeating. That comparison is only possible if the cohorts were tagged when they arrived. Attribution data can then drive the retention response for each group separately.

Check the split before you spend

Pull your last 90 days, segment installs by the reattribution flag, and see what share of your "new users" are returning. It takes an afternoon and it will change how you read every festive report you produce this year.

If you would like to see that split on your own data before the window opens, request a demo and we will run the segmentation with you.

FAQ

What is the difference between a reattribution and a new install?

A new install is a user's first attributed install of your app. A reattribution is an install event credited to a new campaign for someone who had installed previously, then lapsed beyond the prior attribution window. Both appear as installs in most dashboards, but only the first is acquisition.

What is a normal reattribution rate for a mobile app?

There is no reliable published benchmark, and it varies enormously with how seasonal your app is and how much retargeting you run. Rather than looking for an industry figure, measure your own baseline outside the festive window and treat the festive delta as the number that matters.

Why do reattributions increase during festive campaigns?

Reactivation and win-back budgets are concentrated into the festive window, retargeting spend rises alongside acquisition spend, and broad prospecting at festive budgets inevitably reaches people who already have your app. Seasonal apps also carry large dormant bases going into the window.

Does a reattribution count towards my CPI?

In most default setups, yes. It adds to the install denominator, which lowers reported cost per install without any improvement in acquisition efficiency. This is precisely why the blended figure flatters festive campaigns.

Should reattributed users be measured against the same targets as new users?

No. Judge acquisition on cost per activated new user and 30-day retention. Judge reactivation on cost per returning active user and repeat transaction rate. Applying one target to both guarantees you misread at least one of them.