Apsalar Attribution

Last Updated: Jun 09, 2016 06:35PM PDT

Apsalar Attribution Methodology


Apsalar supports the following methodologies for tracking attributions: When it comes to determining the source of attribution for your app's users, we use the above methodologies to match an install to identifiers retrieved from the Apsalar SDK.  

These identifiers are the following:

Identifiers - iOS Advertising ID

The iOS advertising ID is an software-resettable  identifier made available with iOS 6.0 and on, which is the identifier used for Apsalar attribution tracking on iOS platforms.  Apsalar supports tracking via the raw, the SHA1 hash, or the MD5 hash of the advertising ID.  You can see how to reset the iOS advertising ID here.

The iOS advertising IDs is a upper-case identifier containing hyphens, usually resembling the following:  5E665288-BC02-4C55-AE8A-3BCD1A5A12FF


Identifiers - Android Advertising ID

The Android Advertising ID is an software-resettable identifier made available with Google Play services which allows apps to access a identifier for advertising purposes.  This is a unique and resettable identifier which takes the place of the legacy Android ID for tracking purposes. You can see how to reset the advertising ID here.

The Android advertising ID is a lower-case identifier containing hyphens, usually resembling the following: 3c53dc71-cd11-47db-af9c-ba9859094b80

For more information on the usage of the Android Advertising ID, or what it is, please see Google's article here.


Identifiers - Android ID

The Android ID is a persistent identifier.  Prior to 2013, this was the primary method of tracking an Android ID for advertising purposes.  Since then, Google has made the Android advertising ID available for this purpose.  With the introduction of the advertising ID, Google has continued to promote the continual adoption of the advertising ID.   As this initiative continues, attribution providers such as Apsalar will continue to promote this adoption as well.

"Beginning August 1st 2014, the Google Play Developer Program Policy requires that all updates and new apps uploaded to the Play Store use the advertising ID (when available on a device) in place of any other device identifiers for any advertising purposes. Developers will be responsible for ensuring their apps are in compliance with policies regarding its usage, as well as all Play policies."

As per Google guidelines, legacy tracking via the Android ID is supported, but only if the device does not have an advertising ID.  

The Android ID is a lower-case identifier, usually resembling the following: 
32c0a88b3e74f151
 

Attribution Flow - Client-side Attribution

A client-side attribution is the most common of the mobile attribution integrations.  This integration is recommended and allows for the advertiser to use their configured destinations in Apsalar, as well enables full use of Apsalar SmartTag and Destinations.

The attribution flow is as follows:
1. Device clicks on ad served via an ad networks' conversion pixel
2. Ad network conversion pixel redirects to Apsalar attribution tracking URL
3. Apsalar tracks the click, and serves a redirect to the app store or deep-link
4. User downloads and opens app
5. Install is tracked by Apsalar and the last click for the device is awarded the attribution
6. Any configured install postbacks are distributed
 

 

Attribution Flow - Server-side Attribution (S2S)

A S2S integration has the same flow as a client-side attribution, with the exception that the ad network performs the app store or deep-link redirect, and Apsalar click notifications are served by an ad networks' server.

The attribution flow is as follows:
1. Device clicks on ad served via an ad networks' conversion pixel
2. Ad network server receives click, serves a redirect back to the device, and sends Apsalar notification of a click
3. Apsalar tracks the click
4. User downloads and opens app
5. Install is tracked by Apsalar and the last click for the device is awarded the attribution
6. Any configured install postbacks are distributed
 
 
If you are interested with integrating S2S attribution, please contact Apsalar Support team at support@Apsalar.com

Attribution Flow - Re-engagement Attribution

Re-engagement tracking is shares many similarities to standard install attribution flows.  The primary difference is the tracking of any app open activity on the device, rather than an install.  The following example details a client-side re-engagement flow, though both client-side and server-side methodologies are available.

The attribution flow is as follows:
1. Device clicks on ad served via an ad networks' conversion pixel*
2. Ad network conversion pixel redirects to Apsalar re-engagement tracking URL
3. Apsalar tracks the click, and serves a redirect to the app store or deep-link
4. User downloads and opens app
5. App-open is tracked by Apsalar and the last click for the device is awarded the re-engagement
6. Any configured re-engagement postbacks are distributed
 
*device IDs required for re-engagement clicks
support@apsalar.com
http://assets0.desk.com/
apsalarinc
Loading
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
about
Invalid characters found
/customer/en/portal/articles/autocomplete