Redownloads for partners

A redownload is the first session recorded after an app was deleted from a device, as detected by Adjust SDK using OS metadata. Some redownloads qualify to be treated as new installs for attribution (redownload installs) based on clients’ app settings.

How it works

For a session to qualify as a redownload install, it must meet all three of the following requirements:

  1. Adjust SDK should track a session after the app was deleted from the device (we’ll mark such a session as a Redownload).
  2. Enough time should elapse since the previous install (original install or the previous redownload install). This time window is controlled by the Redownload exclusion window.
  3. The user should be inactive in the app long enough to generate a brand new conversion. This is controlled by the Redownload inactivity period and is measured since the last recorded session start.

Redownload exclusion window

The minimum time required since the previous “install start point”:

  • The last recorded redownload install time, if the device has had qualifying redownloads before
  • The original install time (first session of your app ever recorded by Adjust from a device) if no redownload installs were recorded for a device.

Settings

  • Default: 3 months (90 days)
  • Configurable range: 30-720 days (1-24 months)

Redownload inactivity period

The minimum time required since the device last had a recorded session activity for your app.

  • This window is measured from the last session time.

Settings

  • Default: 14 days
  • Configurable range: 1-30 days

Attribution behavior

Redownload install

A qualifying app redownload is recorded as a redownload install. When this happens:

  • A new install activity is tracked.
  • The redownload is treated as a new install for attribution and reporting, with a new attribution source.
  • Install time and install-related counters use the redownload timestamp.
  • Attribution follows the standard install attribution flow:
    • The session is attributed according to the attribution waterfall, resulting in either an organic install or attributed to a paid source.
  • Historical cohort performance for the attributed device resets and starts counting again from the redownload attribution time.
  • A new cohort measurement starts for this device (for both first and dynamic sources).
  • The ADID does not reset.

Redownload session / redownload reattribution

If the redownload session does not qualify to be an install, it is counted as a redownload session or redownload reattribution. When this happens:

  • The redownload is treated as a normal session and processed according to existing attribution logic.
  • It does not start a new first source cohort.

Callbacks

Redownload activity is available in callbacks based on how the activity is classified.

Placeholders

To provide visibility into redownloads reporting, the following placeholders can be added to your callbacks:

PlaceholderDescription
{is_redownload}Indicates whether this app activity is the first one recorded after the app was redownloaded.
{redownload_exclusion_window}The redownload exclusion window setting configured for the app in the dashboard. (Reported in hours)
{redownload_inactivity_period}The redownload inactivity period setting configured for the app in the dashboard.

For more information about the placeholders you can use for visibility into redownloads, and which activity types they’re available for, you can use our guide to Partner placeholders.