Attribution Source Filter

The Attribution Source filter controls which source attributions are assigned to in the dashboards and reports. It works in combination with the Attribution Status filter, which determines which users are included.

Key concepts

Attribution source

Attribution source is any source to which Adjust attributes an install, redownload install, or reattribution:

• First source – the attribution source associated with the user's current install state, which can be either the original install source or a redownload install source. For most users, this is the original install source. However, if a redownload install happens, the redownload attribution becomes the user's new first source from that point forward.
• Dynamic source – the most recent attribution source at the time of in-app activity. For users who have never been reattributed, this is the same as the first source.

Redownload installs

A redownload install is the first qualifying session recorded after a user deletes and reinstalls your app, provided the redownload meets the configured exclusion window and inactivity period thresholds.

When a redownload install happens:

• The redownload is treated as a new install for attribution and reporting, with a new attribution source.
• Historical cohort performance for the device resets and starts counting from the redownload attribution time.
• A new cohort measurement starts for this device for both first and dynamic sources.
• The user's first source becomes the redownload attribution source (not the original install source).

For full details on redownload configuration and behavior, see Redownloads.

Attribution status

While the attribution source filter controls where attributions and in-app activity are assigned, the attribution status filter controls which users are included:

• Installed refers to users who are still attributed to their original install source and have not been reattributed since their most recent install (or redownload install).
• Reattributed refers to users who have been reassigned to a different attribution source after their most recent install (or redownload install).
• All includes all users, regardless of their current attribution status.

How each mode works

First source

All in-app activity including events, sessions, and reattributions is associated with the user's install source, regardless of any subsequent reattributions.

If the user has a qualifying redownload install, the redownload attribution becomes the new first source. Activity after the redownload is pinned to that new first source; activity from before the redownload is attributed to the previous install source.

Example scenario (with reattribution):

A user installs via Source A → completes Event 1 → is reattributed to Source B → completes Events 2 and 3 → is reattributed to Source C.

Source A receives credit for everything. Source B and C show no activity.

Example scenario (with redownload install):

A user installs via Source A → completes Event 1 → deletes the app → redownloads and qualifies as a redownload install attributed to Source D → completes Events 2 and 3.

Source A retains credit for activity before the redownload. Source D becomes the new first source and receives credit for all activity after the redownload install.

Dynamic source

Each in-app activity is assigned to whichever source the user was attributed to at the exact moment the event fired. This distributes activity across all attribution sources over time.

Example scenario (with reattribution):

A user installs via Source A → completes Event 1 → is reattributed to Source B → completes Events 2 and 3 → is reattributed to Source C.

Activity is split accurately across sources based on when each event occurred.

Example scenario (with redownload install):

A user installs via Source A → completes Event 1 → deletes the app → redownloads and qualifies as a redownload install attributed to Source D → completes Events 2 and 3.

In this case, the result is identical to First Source because no reattributions occurred after the redownload install.

Combined filter behavior: Attribution Source × Attribution Status

These two filters must always be used together. The combination you choose determines both which events are included and how they are assigned to sources.

Attribution Status = Installed

Includes only events that occurred while the user was in an installed (not yet reattributed) state. All events from reattributed periods are excluded. Reattribution and deattribution KPIs are always zero.

• First source: Identical to Dynamic. Since you are only seeing the pre-reattribution period, the user's first source and dynamic source are the same (the install source), so both views produce the same result.
• Dynamic source: Same as First. Events are attributed to the install source.

Attribution Status = Reattributed

Includes only events that happened while the user was in a reattributed state. All events from the initial installed period (before the first reattribution) are excluded. This is the complementary set to Installed.

• First source: All reattributed-period events — including reattributions, deattributions, and in-app events — are pinned to the install source.
• Dynamic source: Reattributed-period events are distributed to whichever reattribution source was active at the time of the event. Reattributions and deattributions are assigned to the new source (the one the user was reattributed to).

Attribution Status = All

Includes all attributions and in-app activity across all users, regardless of attribution status.

• First source: Every conversion is pinned to the user's current install source (which may be a redownload install source).
• Dynamic source: Conversions are distributed to whichever source was active at the time of the event.

FAQ