Mobile app attribution is the process of connecting the install of a mobile app and the user's activities inside the app to the marketing campaign that led to the installation.
Singular makes these connections by matching an ad view or ad click that happens on a mobile device to the install (or, more precisely, the first session) of a mobile app on that same device.
Note: Singular also supports SKAdNetwork, Apple's privacy-conscious attribution framework. SKAdNetwork-based attribution has a different flow and is set up separately. To learn more, see Introduction to Singular's SKAdNetwork Solution.
Singular's Install Attribution Process
1. Recognizing an Install
The Singular SDK/S2S embedded in an app reports to the Singular server whenever the app is opened. If the app is opened on a device unknown to Singular, Singular marks this as an app install and triggers the install attribution process.
In other words, install = the first app open on a new device.
2. Reconstructing the User Journey
For every install, Singular scans its database for relevant ad interactions (ad clicks and ad views) that originated from the same device in a certain time window before the install (see The Attribution Lookback Window below). In Singular, these ad clicks and views are known as touchpoints.
The goal is to reconstruct the user journey as the first step toward finding the touchpoint that most likely led the user to install the app.
There are several ways to determine if the touchpoint device is the same as the install device, and the different methods have different levels of reliability:
- Deterministic methods use a unique identifier to recognize the device.
- Probabilistic methods are less accurate and are used to match devices if deterministic methods are not available.
For more details, see Attribution Methods below.
3. Checking for Possible Fraud
After Singular collects all the relevant touchpoints that happened prior to the install, the Fraud Prevention Engine kicks into action, evaluating each touchpoint to determine if it is authentic or fraudulent.
For example, what appears to be a click on an ad may have been simulated in order for an ad network to receive credit for an app install illegitimately. Alternatively, the install itself may be fake. These and other types of fraud can cost you in excessive billing for CPI/CPA campaigns, so Singular looks for them before finalizing the attribution or reporting it to the ad network.
For more information on different types of ad fraud, Singular's prevention methods, and how you can customize your fraud protection by adding rules of your own, see Singular Fraud Prevention.
4. Prioritizing Touchpoints and Last-Touch Attribution
The touchpoints that were found to be valid are rated by importance (clicks are prioritized over impressions as they reflect a higher level of user intention) as well as the reliability of the device matching method. For the full details, see Touchpoint Prioritization below.
All else being equal, Singular prioritizes the touchpoint closest in time to the install. This is called a last-touch attribution model.
This way, Singular picks the touchpoint that is most relevant to the install and is able to attribute the install to the relevant partner network.
5. Sending Out Postbacks
After finalizing the attribution decision, the Singular system notifies the partner network that an install (or re-engagement) was attributed to it. This is done through a postback - a message posted automatically to a partner's API endpoint.
If you, as a customer, also want to receive real-time notifications about installs and their attribution decisions, you can set up Singular to send postbacks to your BI platform or advertising dashboard (see Configuring Internal BI Postbacks).
Accessing Your Attribution Data
There are several ways to view the data about attribution decisions in your account:
- For aggregated attribution stats, use Singular reporting. Whether you run reports in the Singular web app or through the Singular API, you can include metrics such as installs and re-engagements to see the aggregated attribution data per partner network, app, campaign, etc. See the Reports FAQ for all the information you need.
- For user-level data, see the attribution logs. Use the Export Logs page in the Singular web app to export raw user-level logs from Singular's attribution service. See Exporting Attribution Logs for details.
You can also set up Singular to send you postbacks in real time when an attribution decision is made. See Configuring Internal BI Postbacks for details.
Singular Attribution Methods
Singular employs the following methods to match the ad engagement device to the app install device:
||Android Only||This method, when available, offers the highest possible level of reliability. When a user clicks on an ad and reaches the Google Play store, a unique Singular referral ID is passed to Google Play. After the user installs the app and opens it, the Singular SDK passes on the referral ID to the Singular server, and Singular can use it to perform attribution.|
|Identifier Matching||Android + Apple||In this highly reliable method, the Singular tracking link that the user clicks on includes the Google Advertising ID (AIFA) or iOS Advertising ID (IDFA) of the device. Singular can then match an install event to the click based on the shared advertising ID.|
|Attribution for SANs||Android + Apple||Ad campaigns that you run through Self-Attributing Networks (SANs), such as Facebook or Twitter, do not allow the inclusion of Singular tracking links, so usual methods of attribution do not apply. Instead, Singular has a special partnership with SANs such as Facebook, Google Ads, Twitter, Apple Search Ads, Snapchat, and Yahoo Gemini. Singular reports installs to the partner, and the partner reports back on whether there was a matching ad click or view in the partner's advertising platform. For supported partners, Singular can track re-engagements in the same manner.|
|Deep Link||Android + Apple||This method is applied when the user clicks on an ad that deep-links the user directly into an already installed app. In this case, Singular knows for sure that the click device and the device on which the app is installed are one and the same.
Deep linking is almost always used for re-engagement attribution, with one exception: sometimes a user may have downloaded the app but not opened it yet (and therefore, Singular has not performed install attribution yet). In that case, the deep link actually causes the first app open and triggers the install attribution process.
|Probabilistic Attribution||Android Only
||Probabilistic attribution is used when install referrers and other unique identifiers aren't available. It is also the primary method in attributing cross-platform journeys, such as for connected TV to mobile app attributions. In this method, Singular's tracking URL is used to collect basic information about the device, such as IP address and model. The information is then compared to the install device. For more information, see the Probabilistic Attribution FAQ.
Note: On iOS, probabilistic attribution methods are not allowed or supported.
|SKAdNetwork||Apple Only||SKAdNetwork is an iOS framework for mobile app install attribution that preserves the end-user's privacy. Singular supports SKAdNetwork attribution in parallel with "traditional" attribution (deterministic attribution methods that are implemented through the Singular tracker). See Introduction to Singular's SKAdNetwork Solution and Understanding Singular's Conversion Value Management.|
Note: In accordance with Google and Apple privacy policies, Singular tracks unique devices and their attribution information using the user-resettable Google Advertising ID (AIFA) and iOS Advertising ID (IDFA). Singular retains a device’s install attribution information to ensure attribution and cohort accuracy. Re-engagements can be tracked any number of times with supported partners.
Touchpoints are all the relevant user engagements with ads prior to the install. In Singular, the option that the user installed the app organically is also considered a touchpoint - although Singular will attribute the install to it only if no other valid touchpoints exist.
The following table gives more detail about how Singular prioritizes touchpoints to determine attribution.
|Priority||Attribution Method||Used for Installs||Used for Re-engagement|
|1||Click with Install Referrer|
|Click with Device ID or click reported through a SAN|
|2||Click with Probabilistic Attribution|
|3||View with Advertising ID|
|4||View with Probabilistic Attribution|
The Attribution Lookback Window
The lookback window is a setting that determines how far back Singular searches for the touchpoint that led to an install (or re-engagement) event.
Singular attributes an install to an ad only if the time between the touchpoint and the install/re-engagement is lower than or equal to the number of days set in the lookback window.
For example: if the lookback window is set to 7 days, and a click happened 3 days before the matching install, the install may be attributed to that click. If a click happened 8 days before the install, that click is ignored.
If there are no touchpoints within the attribution window (or if all the touchpoints within the attribution window have been found to be fraudulent), the install is attributed as organic.
Default Lookback Window and Customization Options
The default lookback window when using deterministic attribution methods is 7 days, but you can set a custom window of 1-30 days for each of your apps for each partner network (see the Partner Configuration FAQ for details).
In addition, if you use Singular Links, you can set a custom lookback window for each individual tracking link when you create it. This lookback window will override the general lookback window set for the partner network. This allows for greater control when a partner has different types of channels that may benefit from different attribution windows.
The default lookback window when using probabilistic attribution is 24 hours. For more information, see How does probabilistic attribution compare to using device IDs?.
Tracking Post-Install Events and Uninstalls
Through the Singular SDK embedded in your app, Singular can identify user events that occur in your app after it has been installed. Events include:
- User sessions (i.e., every time the user opens the app)
- Revenue events (purchases made through the app)
- Any other events that are relevant to your app, such as sign-ups, tutorial completions, or level-ups. You set up these events when integrating the SDK.
Post-install events are attributed to the source of the original install (or the source of the last re-engagement, if any). This gives you endless flexibility in terms of optimizing your campaigns or creatives toward specific KPIs. You can track which ad network, campaign, or creative resulted in the highest number of sign-ups, tutorial views, game completions, etc.
The Singular SDK or S2S integration can track uninstalls through the mobile platform's push notifications if they are enabled. Uninstalls are considered a type of post-install event, and you can set them up and view them in your reports accordingly.
You can use Singular to track user re-engagements. In Singular, re-engagement is defined as the user's opening of an app that they have already used before, following a click on a retargeting ad (an ad that targets users who have already installed the app).
Learn more in the Re-engagement FAQ.
Tracking Android UTM Referrers for Unpaid Sources
This optional feature is not enabled by default for new customers. To enable UTM Referrer tracking for your Android apps, contact your Singular Customer Success Manager.
When Singular can't find a paid source to attribute an install to, the install is generally considered organic (see Touchpoint Prioritization) and appears in your reports with "Organic" in the Source field. However, you may be interested in getting more insights about where your organic traffic is coming from. One option offered by Singular is capturing the UTM referrer. This piece of data is sometimes included in the Google Play URL and indicates the source of the link that the user clicked on to get to Google Play.
For example, the following Google Play URL indicates that the user installed the app after clicking a link in the Facebook mobile app (probably in search results):
If you choose to enable UTM referrer tracking, unpaid traffic that has a UTM referrer will appear in your reports with the "UTM Referrer" in the Source column and the referrer string in the Tracker Source Name column. For example: