At a glance: A reinstall occurs when a user installs an app, uninstalls it, and then reinstalls it. Reinstalls result in one of the following attribution types: non-organic reinstall, organic reinstall, or re-attribution (retargeting). Reinstalls help avoid multiple charges for users that uninstall and install again.
What is a reinstall
A reinstall occurs when an app user deletes an app and then reinstalls the app during the re-attribution window.
The reinstall can come from a retargeting campaign (re-attribution), an organic source, or a non-organic source.
Reinstalls that come from an organic source, or a non-organic source, and are in the re-attribution window, are referred to as reinstalls.
Reinstalls that come from retargeting campaigns are referred to as re-attributions.
They differ in how the reinstall and in-app events are attributed.
If an install occurs outside of the re-attribution window, the reinstall is called a new install. A new install is attributed to the media source (or organic if no engagement is recorded) and a new re-attribution window commences.
The table below shows what AppsFlyer would call different reinstalls
| Reinstall source | Is the re-attribution window valid? | Did the user interact with a retargeting campaign before reinstalling? | Did the user interact with a UA campaign before reinstalling? | What is it called |
|---|---|---|---|---|
| From a retargeting campaign | Yes | Yes | No | Re-attribution |
| From an organic or non-organic source | Yes | No | Yes or No | Reinstall |
| From an organic or non-organic source | No | No | Yes or No | New install |
Why are reinstalls important
As well as being a good indication that users are coming back to your app and that your campaigns are working, proper reinstall attribution is important to help avoid multiple charges for users that uninstall and install again within the re-attribution window.
Likewise, attributing in-app events from reinstalls to the original media source (first install) provides advertisers with a better picture of how users are engaged. It also shows how effective UA campaigns and Retargeting ads are. For more information see in-app events below.
Reinstall flow and outcome
Reinstall
After the first app install, the user uninstalls, then reinstalls during the re-attribution window. A reinstall can either come from organic or a UA campaign (see examples).
The following happens:
- The install is NOT attributed - it doesn't appear on the dashboard, nor on the data
- NO install postback is sent to any media source
- See in-app events for information on how in-app events are attributed
Re-attribution
The following happens:
- The install is attributed to the retargeting media source in the retargeting and unified view of the Overview dashboard
- The user acquisition view doesn't contain re-attributions
- All following in-app events are attributed to the retargeting media source (see in-app events for more information)
- An install postback is sent to the retargeting media source
For more Retargeting Attribution information, click here.
In-app events
Overview
In-app events performed by a user after a reinstall, are either attributed organic, attributed non-organic, or unattributed organic depending on the Post Reinstall Events attribution state (see below).
An example of an in-app event is a user who reinstalls an app and then makes an in-app purchase.
In-app events and how they are attributed
| Post Reinstall Events Attribution state | After a Reinstall | After a Re-attribution |
|---|---|---|
| Attributed as organic in-apps | unattributed organic | Retargeting |
| Attributed to the first install(1) | first install media source | Retargeting (2) |
|
(1) See limitations below (2) In the primary source field. The first install media source will be listed in the secondary source field (you will only see this in the raw data). |
||
Unattributed organic in-apps
Reinstall
- All in-app events are counted as organic or disregarded completely depending on the reporting method.
- In-app events will be reported with the conversion_type and campaign_type as "unknown".
-
The date used to aggregate data depends on the event:
- For most SDK-originated in-app events, the date of the app download is used to aggregate data; not the date of the reinstall.
- For ad revenue events (af_ad_revenue) sent by the SDK connector, the date of the reinstall is used to aggregate data.
Re-attribution
- All in-app events are attributed to the retargeting media source
Attributed to the first install
Prerequisites
Requires enabling. Reach out to your CSM to discuss.
Purpose
Provides advertisers with a better picture of how users are engaged. Shows how effective UA campaigns and Retargeting ads are by attributing in-app events to the original source rather than organic.
Reinstall
-
All in-app events generated from reinstalls are attributed to the original install (1)
Note
The install time of the attributed in-app event will be the time of the first install, not the time of the reinstall. For example, if there was an install on March 1st and then a reinstall on March 5th, and if the 'Post Reinstall Events Attribution' option is enabled, any purchase made after the reinstall will be attributed to the install time of March 1st.
Re-attribution
- All in-app events are attributed to the retargeting ad in the primary source and the original install in the secondary source. (2)
(1) See the limitations below.
(2) You will only see this in the raw data.
Note
Organic KPI data in the dashboard may show a lower value with Post Reinstall Events Attribution set to Attributed to the first install as some of those numbers may now be attributed to a non-organic media source.
Examples
With Attributed to the first install enabled.
Example 1
A user installs the app (day 0), makes a purchase for $10, and then uninstalls the app.
The next day (day 1), the user reinstalls the app and makes a purchase of $5.
Since the user already made a purchase before reinstalling, there will not be an additional unique user count.
|
Media source |
users |
Af_purchase: Unique users Day 0 |
Af_purchase: Unique users Day 1 (cumulative) |
Revenue Day 0 |
Revenue Day 1 (cumulative) |
|
Media_source_A |
1 | 1 | 1 | $10 | $15 |
We will see an increase in revenue under the same device_identifier.
|
Appsflyer_id |
Device identifier |
Media source |
Event name |
Event date |
| 111 | XXX |
media_source_A |
install | day 0 |
| 111 | XXX |
media_source_A |
af_purchase | day 0 |
| 222 | XXX |
organic |
reinstall | day 1 |
| 222 | XXX |
media_source_A |
af_purchase | day 1 |
Example 2
A user installs the app (day 0), makes a purchase, and then uninstalls the app.
The next day (day 1), the user reinstalls the app from a UA campaign and makes a purchase.
|
Media source |
Event name |
Event date |
Reinstall attribution |
In-app event attribution |
|
media_source_A |
install | day 0 | media_source_A | |
|
media_source_A |
af_purchase | day 0 | media_source_A | |
|
media_source_B |
reinstall | day 1 | media_source_B | |
|
media_source_B |
af_purchase | day 1 | media_source_A |
Limitations
-
Only users who have consented to share their device identifier (such as IDFA or GAID) with the app for both the install and reinstall will have their in-app events attributed to the original install
- Device identifiers in the first install and the reinstall must match
- The reinstall must occur within the re-attribution window of the last recorded install.
- Each install and reinstall will still have its own unique
appsflyer_id -
The dashboards do not differentiate between an in-app event following install or re-install
- It is possible to see this through the raw data
How does the data appear in the AppsFlyer dashboards
| Reinstall non-organic | Reinstall organic | Re-attribution | ||
|---|---|---|---|---|
| The Reinstall itself | Not seen | Not seen | Retargeting media source* | |
| In-app event attributions going forward | Post Reinstall Events set to Attributed as organic in-apps | Unattributed organic | Unattributed organic | Retargeting media source |
| Post Reinstall Events set to Attributed to the first install | First media source | First media source | Retargeting campaign | |
| *Only in the overview dashboard. | ||||
Reinstalls raw data reports
Prerequisites
Requires enabling. Reach out to your CSM to discuss this.
How the install and in-app events are attributed
| Reinstall non-organic | Reinstall organic | Re-attribution | Install non-organic | Install organic | ||
|---|---|---|---|---|---|---|
| Attributed to | UA campaign | Organic | Retargeting campaign | UA campaign | Organic | |
| Event attribution going forward | Post Reinstall Events set to Attributed as organic in-apps | Organic | Organic | Retargeting campaign | UA campaign | Organic |
| Post Reinstall Events set to Attributed to the first install | First install | First install | Retargeting campaign | UA campaign | Organic | |
Availability of reinstall reports
- Reinstall raw data reports are available using the delivery tools detailed in the table that follows.
- The reports have the same structure and are populated in a similar manner to install reports in that:
- Media source fields are populated using the media source that brought the reinstall or organic.
- Install time: Interpret as reinstall time, meaning the time of the first app open after the reinstall
- Event name: Reinstall
| Report delivery method | Non-organic reinstall | Organic reinstall |
|---|---|---|
| Export data | ✓ | ✓ |
| Pull API | ✓ | ✓ |
| Data Locker | ✓ | ✓ |
| Push API | ✓ | ✓ |