Identity and Identifier Terms and Concepts

An identifier is data used to identify something, such as a person, mobile device, computer browser, or household.

LiveRamp uses identifiers (such as name and postal address, email address, IdentityLinks, cookie IDs, or mobile device IDs) to match your records to other identifiers in our Identity Graph.

Some identifiers (such as client customer IDs) can also be used as an audience key in your files, which allows us to consolidate duplicate rows throughout a particular audience.

The two main categories of identifiers are:

  • Known identifiers (identifiers which have been derived from, and/or can be associated with, PII). Identifiers in this category include name and postal address, email address, phone number, client customer IDs, and (in some cases) custom IDs - see "Known Identifiers" for more information.

  • Anonymous identifiers (identifiers that can't be tied back to an individual on their own, such as known identifiers that have been anonymized and device identifiers). Identifiers in this category include cookie IDs, mobile device IDs, and (in some cases) custom IDs - see "Anonymous Identifiers" for more information.

Identifier data is data LiveRamp uses to match your records to other identifiers in our Identity Graph. Identifier data includes such touchpoints as name and postal address, email address, cookie IDs, and mobile device IDs.

Identifier data also includes identifiers (such as client customer IDs) that are used as an audience key and allow us to consolidate duplicate rows in your file and throughout a particular audience.

Caution

Stay consistent! Files for ingestion in the same LiveRamp audience should always have the same set of identifier fields, and the field names (headers in a column-based file and keys in a key-value file) and audience key should be consistent from file to file.

There are two categories of identifier data that can be included:

  • Known identifiers (sometimes referred to as "offline identifiers") are identifiers which have been derived from, and/or can be associated with, PII. See "Known Identifiers" for more information.

  • Anonymous identifiers (sometimes referred to as "online identifiers") includes device identifiers, and known identifiers that have been anonymized, that can't be tied back to an individual.See "Anonymous Identifiers" for more information.

Warning

Do not combine known identifiers and anonymous identifiers in a single file.

See "Formatting Identifiers" for more information on formatting known and anonymous identifiers.

Known identifiers include PII identifiers and other identifiers which have been derived from, and/or can be associated with, PII and have not been anonymized yet.

In addition to PII-based identifiers (such as name and postal address or email address), known identifiers also include AbiliTec IDs, client customer IDs, and (in some cases) custom IDs and IP addresses.

Note

Known identifiers and PII identifiers are sometimes referred to as "offline identifiers".

Note

Known identifiers are in contrast with anonymous identifiers, which can't be tied back to an individual.

These identifiers include:

  • Name and postal addresses (name and postal, or "NAP"). See "Formatting Name and Postal Addresses" for more information.

  • Email addresses: These can be plaintext or hashed, with SHA-256, MD5, and SHA-1 hashes accepted. See "Formatting Email Addresses" for more information.

  • Phone numbers: These can be plaintext or hashed, with SHA-1 hashes accepted. See "Formatting Phone Numbers" for more information. Phone numbers can be used to match with or without any additional PII, and can be used to match in conjunction with first and last name (similarly to NAP) for greater accuracy. Note: EU data files cannot contain hashed phone numbers.

  • Client Customer IDs: Your internal customer ID. Note: These identifiers function as an audience key, and allow us to de-duplicate rows in the uploaded file, in case a file has multiple rows related to the same person. If you cannot provide a client customer ID, we will use NAP or email addresses as the audience key to deduplicate records.

  • AbiliTec IDs

Anonymous identifiers are identifiers, such as known identifiers that have been anonymized or device identifiers (such as a mobile device ID or cookie ID), that can't be tied back to an individual.

In addition to device-based identifiers, anonymous identifiers include IdentityLinks and (in some cases) custom IDs.

Note

Anonymous identifiers and device-based identifiers are sometimes referred to as "online identifiers".

Note

Anonymous identifiers are in contrast with known identifiers, which have been derived from, and/or can be associated with, PII (and are therefore considered PII).

These identifiers can include:

  • Cookies: Data that is set by a website when a particular user’s browser visits that site. See "Formatting Cookies" for more information.

  • Custom IDs (CIDs): Identifiers that are assigned to users by a specific platform, such as Google or Facebook. See "Formatting Custom IDs" for more information. Note: If a custom ID is tied to PII, it is considered "known" and not "anonymous".

  • Mobile device IDs: Identifiers that identity a particular mobile device, such as Identifier for Advertisers (IDFAs) for iOS (Apple) devices and Android Advertising IDs (AAIDs) for Android devices. These can be plaintext or hashed, with SHA-1 hashes accepted. See "Formatting Mobile Device IDs" for more information.

    Note

    Web browsing (cookie) data from mobile devices is considered web data, and is not included in the mobile category.

  • IdentityLinks: LiveRamp’s identifier that is tied to devices in the LiveRamp Identity Graph. See "Formatting IdentityLinks" for more information.

Caution

We have a 90-day retention window for cookie IDs and a 2-year retention window for mobile device IDs.

Note

Generally speaking, LiveRamp can accept cookies and custom IDs as input from any platform to which it can distribute data (some exceptions do exist; contact your LiveRamp representative with specific questions).

A category of identifiers where the identifiers consist of PII (personally-identifiable information).

PII identifiers are a subset of the category of known identifiers, which are identifiers which have been derived from, and/or can be associated with, PII (and are therefore considered PII) and have not been anonymized yet. See "Known Identifiers" for more information.

Note

PII identifiers are sometimes also referred to as "offline identifiers".

A category of identifiers where the identifiers are based on digital devices (for example, cookie IDs or mobile device IDs).

Device identifiers are a subset of the category of anonymous identifiers, which are any identifiers that can't be tied back to an individual. See "Anonymous Identifiers" for more information.

Note

Device identifiers are sometimes also referred to as "online identifiers".

In the context of LiveRamp, a maintained identifier (such as a maintained IdentityLink (IDL) or a maintained AbiliTec ID) represents a person that LiveRamp can fully recognize.

A maintained identifier is the identifier associated with a given record when there is a maintained record in the AbiliTec Identity Graph (our PII-based offline identity graph) for the input data provided.

Multiple online devices can usually be matched to a maintained IDL, enabling cross-device use cases.

In some cases, there might be more than one maintained identifier for a given record. This situation sometimes arises when a particular PII touchpoint is present in more than one maintained record in the Identity Graph.

Note

What if there isn't a maintained record for the input data? If there is no maintained record in the AbiliTec Identity Graph, LiveRamp generates a derived identifier for each PII touchpoint, such as a derived AbiliTec ID or IDL.

As new information is added to the AbiliTec Identity Graph over time, a maintained identifier might change to reflect that new information.

Tip

How should updates be handled? LiveRamp does not provide mappings of old IDLs to new IDLs, or provide notice that a transition has occurred. This can be handled by simply overwriting the IDL you have in your system tied to a given device/user with the new IDL while maintaining data you had previously associated to that device/user.

In the context of LiveRamp, a derived identifier is the identifier associated with a given PII touchpoint (such as an email address or phone number) when there is a no maintained record in the AbiliTec Identity Graph (our PII-based offline identity graph) for the input data provided. Derived identifiers include derived IdentityLinks (IDLs) and derived AbiliTec IDs.

If there is a maintained record in the AbiliTec Identity Graph, LiveRamp will associate a maintained identifier, such as a maintained AbiliTec ID or maintained IDL, with that record.

Multiple online devices can usually be matched to a derived IDL, enabling cross-device use cases.

As PII touchpoints are added to the AbiliTec Identity Graph over time, a derived identifier might be converted to a maintained identifier once we can confidently resolve those PII touchpoints to an individual.

Tip

How should updates be handled? LiveRamp does not provide mappings of old derived IDLs to new maintained IDLs, or provide notice that a transition has occurred. This can be handled by simply overwriting the IDL you have in your system tied to a given device or PII touchpoint with the new IDL while maintaining data you had previously associated to that device or PII touchpoint.

In the context of LiveRamp, a placeholder cookie IdentityLink (IDL) or placeholder mobile IdentityLink is the identifier provided for a cookie or mobile device ID which LiveRamp has not identified. Providing a placeholder identifier ensures that every device ID has a corresponding IDL, and allows LiveRamp to update to a maintained IDL if the device ID is identified in the future.

PII : Personally identifiable information, including name and postal, email, phone, and hashed email.

  • Example: name@gmail.com

IDL: IdentityLinks - LiveRamp’s universal, encrypted identifiers that LiveRamp customers and partners receive.

  • Example: XY1000r99GR8_vGdKIEZt98TLMY6RKCI3kYrEdaM3SF0twCqN

Cookie: A partner cookie in sync with LiveRamp.

  • Example: 134c3ef6-19af-469f-940f-46f948491f8e Note: Partner cookie IDs can be in many different formats.

IDFA or AAID: Anonymous mobile device identifiers; Apple's ID for Advertising (IDFA) for iOS devices and Google's Android Advertiser ID (AAID) for Android devices.

  • Example: 6219dbf3d457cf1419bd855e21ea247ac4b08949 Note: IDFAs and AAIDs are frequently SHA-1 hashed.

Custom ID: An account-based user ID understood by LiveRamp.

  • Example: 535c3ef6-19af-469f-940f-46f948491f8e Note: Partner custom IDs can be in many different formats.

Unique identifiers given to mobile devices. Types of mobile device IDs include:

This category of IDs is sometimes referred to as Mobile User IDs (MUIDs) or Mobile Advertising IDs (MAIDs).

Identifiers that are assigned to users by a specific platform, such as Google or Facebook.

LiveRamp often uses these types of identifiers as a cross reference between a LiveRamp partner's ID and LiveRamp's IDs.

When a CID is tied to PII in a file, it is considered a known identifier. When it is tied to an IdentityLink (IDL), or other anonymous identifier, it is considered an anonymous identifier.

All AbiliTec IDs are generated and encoded for a specific AbiliTec client.

Note

An AbiliTec ID is considered a "known identifier".

There are three main types of AbiliTec IDs:

  • AbiliTec Person IDs are identifiers that represent an individual, based on PII.

  • AbiliTec Household IDs are identifiers that represent adults living together at the same location who exhibit a persistent relationship, based on PII.

  • AbiliTec Address IDs are identifiers that represent a site or physical location.

If there is a maintained record in the AbiliTec Identity Graph for the input data provided, a maintained AbiliTec ID is returned.

If there is no maintained record in the AbiliTec Identity Graph for the input data provided, a derived AbiliTec ID is generated and returned (depending on which endpoint is used for the API call).

Using AbiliTec IDs

AbiliTec IDs can be used in a client's environment for deduplication, person and household formation and validation, and data unification of identity fragments for known data sets.

Accessing AbiliTec IDs

The best way to access AbilTec IDs from LiveRamp today is by using the AbiliTec API, which is a real-time, transactional API for resolving customer data (PII) to AbiliTec IDs. See our AbiliTec API help content and API reference here for more information and reach out to your LiveRamp rep to get started.