Skip to end of metadata
Go to start of metadata

Following are the user identifier values that should be passed in an AdCel request for mobile web, and applications (iOS and Android), in order of preference.  If you do not have any of these values available, please contact Verve to discuss possibilities.  In any event, it is critical that the user identifier "source" ("uis") parameter accurately represent the identifier you're passing.

iOS (iPhone & iPad) Applications

In general, for iOS 6.0+, we'd like to see Apple's advertisingIdentifier ("IDFA"), as supplied by the ASIdentifierManager class.  For iOS versions prior to 6.0, we'd like to see an unsalted, MD5 hash of the uniqueIdentifier ("UDID"), as supplied by the UIDevice class.

Note that, in some circumstances, ASIdentifierManager returns an invalid advertisingIdentifier of all zeros (this is the case as of iOS 10 if limit ad tracking is enabled).  You should use an alternate identifier instead of this invalid IDFA.  Additionally, we recognize that the availability of UDID is somewhat tenuous.  When our preferred identifiers are unavailable, a valid (non-zero) identifierForVendor (from UIDevice on iOS 6.0+) or a random identifier that's persistent with the app installation are acceptable.

Additionally, when IDFA is passed, the "uis" parameter must indicate the user's tracking preference (advertisingTrackingEnabled in ASIdentifierManager).  Verve honors this preference and will utilize the identifier only for conversion tracking and delivery control when tracking is not enabled.

Following are acceptable iOS identifiers and their source values, in order of preference:

Identifier (ui)Source (uis)Description
IDFA, in the clear"a" (tracking enabled) or "ar" (tracking disabled)Apple's advertisingIdentifier, when it's non-zero.  Only available on iOS 6; the source parameter must indicate tracking preference.
IDFA, unsalted MD5 hash"am" (tracking enabled) or "amr" (tracking disabled)Unsalted MD5 hash of Apple's advertisingIdentifier, when it's non-zero.  Only available on iOS 6; the source parameter must indicate tracking preference.
IDFA, unsalted SHA1 hash"as" (tracking enabled) or "asr" (tracking disabled)Unsalted SHA1 hash of Apple's advertisingIdentifier, when it's non-zero.  Only available on iOS 6; the source parameter must indicate tracking preference.
UDID, unsalted MD5 hash"u"Unsalted MD5 hash of uniqueIdentifier.
UDID, unsalted MD5 hash"um"Unsalted MD5 hash of uniqueIdentifier.
UDID, unsalted SHA1 hash"us"Unsalted SHA1 hash of uniqueIdentifier.
UDID, in the clear"uc"Clear-text representation of uniqueIdentifier. Please note that collection of this value may violate Apple's App Store policies; Verve recommends performing an MD5 hash.
 "unk" 
Vendor ID, in the clear"av"Apple's identifierForVendor, when it's non-zero. Only available on iOS 6.
Random ID"v"Client-side, randomly-generated ID. This ID should persist between app sessions (i.e., generated only once on first launch of the app).

Android Applications

Verve's preferred user identifier for Android devices is an unsalted MD5 hash of a valid ANDROID_ID value from the android.provider.Settings.Secure class.  Note that some older devices return hard-coded values (e.g., "9774d56d682e549c" and "dead00beef") for this constant; you should use an alternate identifier in such cases.

Following are acceptable Android identifiers and their source values, in order of preference:

Identifier (ui)Source (uis)Description
Google Play advertising identifier, in the clear"g" (targeted advertising allowed) or "gr" (targeted advertising not allowed)Google Play's advertising identifier, available from the Google Play Services SDK. The source must indicate the user's targeted advertising preference.
Google Play advertising identifier, unsalted MD5 hash"gm" (targeted advertising allowed) or "gmr" (targeted advertising not allowed)Unsalted MD5 hash of Google Play's advertising identifier, available from the Google Play Services SDK. The source must indicate the user's targeted advertising preference.
Android ID, unsalted MD5 hash"dm"Unsalted MD5 hash of a valid ANDROID_ID.
Android ID, unsalted SHA1 hash"ds"Unsalted SHA1 hash of a valid ANDROID_ID.
Android ID, in the clear"dc"A valid ANDROID_ID.
Random ID"v"Client-side, randomly-generated ID. This ID should persist between app sessions (i.e., generated only once on first launch of the app).

Android Advertising ID deprecation set for August 1, 2014

With the Google Play 4.2 coming out, Google is deprecated the Android Advertiser ID. To provide seamless performance, we would like for you to pass the new Google Advertising ID through our existing ui/uis field and the old Android Advertiser ID in a new oui/ouis fields documented in the api spec in the parent page. Pass the same values in the oui/ouis fields as was previously sent in the ui/uis fields for the Android Advertiser ID.

Mobile Web

Cookies are, of course, the simplest solution for maintaining a unique identifier for a mobile web user.  However, the mobile environment presents unique challenges for identifying users across sites given the unreliability of 3rd party cookies.  If you have access to an identifier for mobile web promises coverage beyond cookies (e.g., a device fingerprinting solution such as AdTruth), please let us know.

Following are acceptable mobile web identifiers and their source values, in order of preference:

Identifier (ui)Source (uis)Description
Random ID, stored as a 3rd party cookie"c3"A randomly-generated ID that reliably identifies users across your network.
Random ID, stored as a 1st party cookie"c1"A randomly-generated ID that reliably identifies users for a given site.

 

*Unknown user ids are set as: "unk" (or "ukn")

Valid IDs for Identifying users for Retargeting and FTI