Skip to main content

Installs

Install widget dashboard

In the context of justtrack, an install is defined as any user attribution event. There are two such event categories:

  • New installs
  • Reattributions

The install metric is important for understanding the success of your campaigns, especially if you use the cost-per-install (CPI) optimization model.

In this document, you'll learn about different types of installs and how they're used in justtrack. But here's a quick overview to get you started:

Install overview diagram

New installs​

A new install occurs when a user installs your app and opens it for the first time. In the event of a new install, justtrack determines the advertising partner that originated the install, if there was one, and attributes the install to that partner.

info

For an install to be recorded in justtrack and a partner to be awarded an attribution, the user must actually open the app, not only download it.

Reattributions​

When users who used your app in the past have stopped using it, they're considered churned users. They may be subjected to advertising campaigns that encourage them to open and re-engage with the app. When a churned user opens the app, a new attribution is awarded to the partner who originated the re-engagement. This new attribution is called a reattribution because the user who was previously attributed to an advertising partner gets reattributed to either the same partner or a new one. Reattributions are considered installs in justtrack, and are presented as such in the dashboard.

info

The user is considered a churned user when they have been inactive for the entire duration of the retargeting window.

In justtrack, we define two types of reattributions:

  • Attributed reinstalls
  • Re-engagements

Attributed reinstalls​

A attributed reinstall occurs when a once-active user:

  1. Uninstalls your app
  2. Engages with an advertising campaign
  3. Reinstalls your app
  4. Opens your app

Re-engagements​

A re-engagement occurs when a once-active user:

  1. Becomes inactive, but keeps the original install on their device
  2. Engages with an advertising campaign
  3. Opens your app

Distinguishing between reattributions​

While you can't distinguish between reattributions in the justtrack UI, you can if you receive raw data exports. Specifically you can do this with instance IDs.

When a user installs your app, the justtrack SDK generates an instance ID. The instance ID is stored in the app's cache and represents the current install instance. As long as the user doesn't uninstall the app or clear cache, this instance ID will remain constant. This is true even if the user triggers a reattribution event.

There are two reasons for storing an instance ID. The first is to be able to provide an identifier to partner SDKs during initialization without having to wait for an install ID to come back from our servers. The instance ID is generated immediately on-device, so we can provide that directly to partner SDKs.

The second reason, and the one more relevant to reattributions, is that you can use it to distinguish between attributed reinstalls and re-engagements. Because the instance ID remains constant until the user uninstalls the app, you can determine a reattribution is:

  • An attributed reinstall if the instance ID is unique.
  • A re-engagement if the instance ID is the same as a previous install.
info

Note that this logic is an approximation because the user can manually regenerate an instance ID by clearing cache.

Cost-per-install campaigns​

So why are reattributions considered installs, even if the user never uninstalled the app? This is because we need to be accurate with how we communicate the success of your ad campaigns.

The most common cost model for ad campaigns is cost-per-install (CPI). In this model, you as the advertiser pay for every install that's attributed to your ad campaign. The advertising partners, in this case, make money by optimizing ad placements such that they result in more installs. Because you can choose CPI as your cost model for any advertising campaigns, it's important to consistently show and report both new installs and reattributions as "installs" in the dashboard.

There is, however, an "install" case that's not counted toward your install numbers: non-attributed reinstalls.

Non-attributed reinstalls​

A non-attributed reinstall occurs when a once-active user:

  1. Uninstalls your app
  2. Reinstalls your app without having engaged with an advertising campaign
  3. Opens your app

This is similar to an attributed reinstall. The difference is, in the case of a non-attributed reinstall, the user didn't engage with an advertising campaign. Because the user organically reinstalled the app, this type of event doesn't record a new attribution. Therefore, non-attributed reinstalls aren't counted as installs in the justtrack dashboard.

Installs in the justtrack dashboard​

As our definition of an install states, "installs" count all new installs plus all reattributions. This is how installs are represented in the dashboard. Typically these two types of installs are grouped together. However, on the Statistics page, you can separate installs with the User Type dimension:

If the User Type is acquisition, it refers to a new install. If the User Type is anything else, it refers to a reattribution.

Installs in the raw data​

In our raw data, which you can access with our raw data export feature, we handle installs a little bit differently. There, we have two tables:

  • installEvents: This table tracks new installs, reattributions, and non-attributed reinstalls.
  • attributionEvents This table tracks new installs and reattributions.
Further Reading

Reference the schema documentation for these tables for more information on all available fields.

Here are the cases that result in a new row for each table:

CaseinstallEventsattributionEvents
New install
Non-attributed reinstall
Reattribution

The major difference between the raw data and how it's presented in the dashboard is what these events are called. In the dashboard, new installs and reattributions are called "installs". However, in the raw data, these map to the attributionEvents table, not the installEvents table.