While it's true that re-engagement (retargeting) campaigns are aimed at existing users of your product, your reports may show that the campaigns resulted in some installs (i.e., new users) as well.

This is due to the technical definition of "re-engagement event" vs. "install" in Singular. When Singular receives a first user session from a device - i.e., a session from a device is not listed in the Singular database as having the app installed on it - it is counted as an install, even if the campaign type is re-engagement/retargeting. 

This can be caused by a discrepancy between the data pulled through the tracker (re-engagements) and the data reported by the network (whether a campaign is a retargeting campaign or not). This can happen even with self-attributed networks (SANs). For example, there are cases in which Facebook does not mark a campaign as a retargeting campaign but still claims a session attributed to that campaign as a re-engagement.

In general terms, re-engagement with a mobile app is a renewed use of the app by a user who has already installed the app in the past. 

Re-engagement is the result of successful retargeting. A retargeting campaign is one that targets existing users of a product, aiming to get them interested in the product again.

In Singular, re-engagement is defined as the user's opening of an app they have already used before, following a period of inactivity and then a click on a retargeting ad.

In other words, Singular counts a re-engagement event if the user:

1. Used the app in the past,
2. Stopped using it for a certain period of time,
3. Clicked a retargeting ad, and
4. Has now opened the app.

Once Singular recognizes a re-engagement event, it triggers a process of re-engagement attribution to credit the partner network that caused the engagement.

Re-engagements are tracked as a metric in the same way that Singular tracks app installs, and you can see their numbers in your reports.

See also: How do I configure a Singular Link for re-engagement/retargeting?

Once Singular recognizes a re-engagement event, it triggers a process of re-engagement attribution. This works similarly to install attribution. The goal is to credit the partner network that caused the engagement.

After Singular performs re-engagement attribution for a user, any following in-app events (such as purchases or level-ups) are attributed to the source of the re-engagement rather than the source of the original app install.

The inactivity window or inactivity period is the time that has to pass without the user using the app for that user to be eligible for a re-engagement process.

By default, the inactivity window is 7 days. This means that a user who used the app less than 7 days ago and now clicks on a retargeting campaign does not trigger a re-engagement attribution.

You can customize the inactivity window per app by going to Settings > Apps.

For example, if the inactivity window is 7 days, then the user must be inactive for at least 7 days and then click a retargeting campaign ad to open the app for the activity to count as a re-engagement event.

In Singular, retargeting is a dimension that indicates whether a campaign is marked as a "retargeting campaign" or not.

A retargeting campaign is one that targets existing users of a product, aiming to get them interested in the product again.

Usually, re-engagement is the result of successful retargeting.

In Singular, "retargeting" denotes a type of campaign that targets existing users of the app.

Therefore, Retargeting is a dimension (breakdown) you can add to your report to have it broken down by whether each campaign was configured as a retargeting campaign or not.

In contrast, Re-engagements is a metric that shows the number of re-engaged users (per app, campaign, source, etc.) in the given date range.

In Singular, retention is measuring how long your users keep using your product after conversion. For example, you can run a report to see "Retention 7d" for an app for a certain date range: this will show you how many of the users who installed an app on those dates were still using it seven days later.

A re-engagement event actually resets the retention counter for the user, as it is considered a new conversion for the same user.

See the Retention FAQ for more definitions and information.

Re-install means installing the app again after uninstalling. This does not necessarily signify re-engagement. 

Like any user session, the first session after a re-install may or may not trigger a re-engagement attribution process, depending on whether the user has been inactive for the required period of time (the inactivity window) and whether this session is coming after a click on a retargeting ad. 

In the context of re-engagement, the attribution lookback window determines how far back Singular looks for a click on a retargeting campaign to determine whether a session is a re-engagement session.

When you set up your partner in the Partner Configuration page, you can customize the attribution lookback window. The same window applies to install attributions and re-engagement attributions.

When you create a tracking link, you can override the default attribution window for the partner and set a different window for each individual link (see the Singular Links FAQ). 

The date of re-engagement is the date on which the user opened the app after clicking the retargeting ad.

For self-attributing networks (SANs):

In self-attributing networks, such as Facebook, Apple, Twitter, or Google, re-engagement tracking may be enabled by default. When you set up a SAN in the Partner Configuration page, you can deselect the Enable re-engagement option. Before you do so, make sure you are not running any re-engagement campaigns through that partner. 

For other networks:

You enable re-engagement per tracking link. When creating the Singular Link, expand the Attribution Settings section and select Enable re-engagement tracking.

For more information about configuring tracking links, see the Singular Links FAQ.

To track your retargeting campaigns' performance, include the following fields in your reports:

• The Retargeting dimension: Lets you know whether each campaign was defined as a retargeting campaign or not.
• The Re-engagements metric: Contains the number of re-engagement events attributed to a campaign.

Re-engagement postbacks to partners and internal BIs are based on the same templates as the install and event attribution postbacks.

In case of a re-engagement postback, the {IS_RE_ENG} macro can be used to differentiate between install and re-engagement attributions, and relevant timestamp fields would apply to the re-engagement event instead of the install event. For more information about the postback fields, see the Postback Macros and Passthrough Parameters.

There is no limit on the number of re-engagements per user.

The re-engagement attribution process is similar to the install attribution process, with some of the main differences being:

For every user session that is not the first session on the device, Singular performs the following process:

• Singular looks at the inactivity window defined for the app and checks whether the user has been active within that period.
• If the user has been inactive for the required period of time, Singular looks back in its touchpoint database to see if there has been a click on a retargeting ad from the same device. Singular needs the ad campaign to be marked as a retargeting campaign. You do this by enabling re-engagement attribution when you create the Singular tracking link. Note that not all partner networks support this type of campaign.
• For Self-Attributing Networks (SANs), which do not support Singular tracking links, Singular just sends the session information to the network and receives back information on whether the user has clicked on a relevant retargeting ad in the network.

If Singular finds one or more clicks on retargeting ads prior to the session, it starts the re-engagement attribution process, based on the last-touch attribution model.

Non-Self-Attributing Networks:

1. A customer creates a tracking link with re-engagement enabled (a prerequisite for this is that the partner is also marked as one that supports re-engagement).
2. Singular receives a user session and recognizes that it is a repeat session (not the first session seen for that device).
3. Singular checks whether the session passes the inactivity window (meaning that the previous session was more than 7 days ago, or however many days were configured for the app). If so, it is marked as a re-engagement.
4. Singular starts the attribution process, looking for matching clicks on re-engagement tracking links.
5. If Singular can attribute the re-engagement, the event (click) is flagged as retargeting = true. This means that the same campaign can have rows where retargeting = true and rows where retargeting = false. However, re-engagements are all mapped to rows where retargeting = true.

Self-Attributing Networks (SANs):

1. For each session, we send the details to the SAN.
2. The SAN tells us whether they take credit for the session or not. 
3. If the session was the first session for the device, Singular interprets it as a new install. If the session was not the first session, Singular interprets it as a re-engagement. 
4. However, similarly to how we treat installs with SANs, Singular may override the SAN's statement, either because the click reported by the SAN does not fall within Singular's lookback window, or because Singular identifies another click that is relevant to the user session and that is more recent than the SAN's click.

An engaged view is a user impression of a video ad that lasted more than 10 seconds. It's required by Google to count engaged views and click-throughs as click-through attributions.

In Singular's user-level logs, engaged view conversions are reported under "interaction_type" = "engagement" in the "passthrough" field for conversion/event data attributed to Google.

In aggregate reporting, engaged view conversions are reported under "conversion type" = "click-through".