Identity and Identifier Terms and Concepts
See the sections below for information on the identity and identifier terms and concepts used at LiveRamp.
Note
For EU and UK customers, "personally-identifiable information" (or PII) is called “directly identifiable personal data”.
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, RampIDs, 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.
Pseudonymous identifiers (identifiers that can't be directly tied back to an individual on their own, such as known identifiers that have been pseudonymized and device identifiers). Identifiers in this category include cookie IDs, mobile device IDs, and (in some cases) custom IDs - see "Pseudonymous Identifiers" for more information.
Identifier data are 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 that have been derived from, and/or can be associated with, PII. See "Known Identifiers" for more information.
Pseudonymous identifiers (sometimes referred to as "online identifiers") include device identifiers, and known identifiers that have been pseudonymized, that can't be directly tied back to an individual. See "Pseudonymous Identifiers" for more information.
Warning
Do not combine known identifiers and pseudonymous identifiers in a single file.
See "Formatting Identifiers" for more information on formatting known and pseudonymous 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 pseudonymized yet.
Note
For EU and UK customers, "personally-identifiable information" (or PII) is called “directly identifiable personal data”.
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 pseudonymous identifiers, which can't be directly 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.
Note
When using name and postal as an identifier, all required name and postal elements must be included in each record: first name, last name, street address, city, state, and ZIP.
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: The type of identifier tied to a record in our AbiliTec offline identity graph
Pseudonymous identifiers are identifiers, such as known identifiers that have been pseudonymized or device identifiers (such as a mobile device ID or cookie ID), that can't be directly tied back to an individual.
In addition to device-based identifiers, pseudonymous identifiers include RampIDs and (in some cases) custom IDs.
Note
Pseudonymous identifiers and device-based identifiers are sometimes referred to as "online identifiers."
Note
Pseudonymous 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 "pseudonymous."
Mobile device IDs: Identifiers that identify 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.
RampIDs: LiveRamp’s identifier that is tied to devices in the LiveRamp Identity Graph. See "Formatting RampIDs" 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).
Note
For EU and UK customers, "personally-identifiable information" (or PII) is called “directly identifiable personal data”.
PII identifiers are a subset of the category of known identifiers, which are identifiers that have been derived from, and/or can be associated with, PII (and are therefore considered PII) and have not been pseudonymized 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 pseudonymous identifiers, which are any identifiers that can't be directly tied back to an individual. See "Pseudonymous 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 RampID 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 RampID, 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 RampID.
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 RampIDs to new RampIDs, or provide notice that a transition has occurred. This can be handled by simply overwriting the RampID you have in your system tied to a given device/user with the new RampID while maintaining data you had previously associated to that device/user.
In the LiveRamp context, a derived identifier is associated with known PII (such as an email address or phone number) when there is no maintained record in the AbiliTec Identity Graph (our PII-based offline identity graph) for the provided input data. Derived identifiers include derived RampIDs 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 a maintained RampID, with that record.
Multiple online devices can usually be matched to a derived RampID, enabling cross-device use cases.
As PII is added to the AbiliTec Identity Graph, 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 RampIDs to new maintained RampIDs, or provide notice that a transition has occurred. This can be handled by simply overwriting the RampID you have in your system tied to a given device or PII with the new RampID while maintaining data you had previously associated to that device or PII.
In the context of LiveRamp, a placeholder cookie RampID or placeholder mobile RampID 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 RampID, and allows LiveRamp to update to a maintained RampID if the device ID is identified in the future.
PII : Personally identifiable information, including name and postal, email, phone, and hashed email.
Note
For EU and UK customers, this type of identifier data is called “directly identifiable personal data”.
Example: name@gmail.com
RampID: 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: Pseudonymous 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.
In the context of identifiers, a RampID is LiveRamp's universal identifier that is tied to devices in the LiveRamp Identity Graph. It is a pseudonymized version of an AbiliTec ID, which is based on PII.
Note
A RampID is considered an pseudonymous identifier.
RampID Types
There are several types of RampIDs:
An Individual RampID represents an individual. It is a pseudonymized version of an AbiliTec Person ID which is based on PII. The length of these RampIDs, and the characters they start with, depends on whether they are maintained or derived versions (see below).
A Household RampID represents adults living together at the same location who exhibit a persistent relationship. It is a pseudonymized version of an AbiliTec Household ID which is based on PII. These RampIDs are 49 characters long and start with "hY".
A Placeholder Cookie RampID is an identifier provided for a cookie ID that LiveRamp has not yet identified. These RampIDs are 49 characters long and start with "Xc".
A Placeholder Mobile RampID is an identifier provided for a mobile device ID which LiveRamp has not yet identified. These RampIDs are 49 characters long and start with "Xm".
RampID Versions
Individual RampIDs come in maintained versions and derived versions, depending on whether there is a maintained record in the AbiliTec Identity Graph for the input data provided:
A maintained RampID represents a person that LiveRamp can fully recognize. Maintained RampIDs are 49 characters long and start with "XY." For example, "XY1005wXyWPB1SgpMUKIpzA0I3UaLEz-2lg0wFAr1PWK7FMhs."
A derived RampID is generated from the input PII provided when there is no maintained record for the input data. Derived RampIDs are 70 characters long, and start with "Xi." For example, "Xi1005p_iYcKP7ZlvFwwK9EwR8GKl_VJqIWUhEaAFmHLAjNOQ9b6OQzSkA43XiVFcTYQ9X."
RampIDs are LiveRamp’s people-based, cross-device identifiers that you’ll use to communicate with LiveRamp. A RampID is a privacy-safe, online representation of an individual, built by deterministically merging offline PII (personally identifiable information, such as email address, name, postal address, and phone number) and matching to cookies, mobile device IDs, and proprietary platform IDs.
See the articles below for more information about RampIDs:
"RampID Methodology" for information on how RampIDs are created, and how LiveRamp’s identity graph functions on the whole.
"Interpreting RampID, LiveRamp's People-Based Identifier for information on how to interpret the identifiers returned from the Real-Time Identity Service.
"RampID’s deterministic standards vs. probabilistic, cross-device matching"
Unique identifiers given to mobile devices. Types of mobile device IDs include:
Identifier for Advertisers (IDFA) for Apple/iOS devices
Android Advertising ID (AAID) for Android devices
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 a RampID or another pseudonymous identifier, it is considered an pseudonymous identifier.
An AbiliTec ID is considered a "known identifier" that is tied to a record in our AbiliTec offline identity graph. AbiliTec IDs are generated and encoded for specific AbiliTec clients.
There are three main types of AbiliTec IDs:
AbiliTec Person IDs: Represent an individual, based on PII
AbiliTec Household IDs: Represent adults living together at the same location with a persistent relationship based on PII
AbiliTec Address IDs: 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 AbiliTec 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 and contact your LiveRamp representative to get started.
RampIDs are LiveRamp’s people-based, cross-device identifiers that you’ll use to communicate with LiveRamp. A RampID is a privacy-safe, online representation of an individual, built by deterministically merging offline PII (personally identifiable information, such as email address, name, postal address, and phone number) and matching to cookies, mobile device IDs, and proprietary platform IDs.
See the articles below for more information about RampIDs:
"RampID Methodology" for information on how RampIDs are created, and how LiveRamp’s identity graph functions on the whole.
"Interpreting RampID, LiveRamp's People-Based Identifier for information on how to interpret the identifiers returned from the Real-Time Identity Service.
"RampID’s deterministic standards vs. probabilistic, cross-device matching"
RampID Methodology
The LiveRamp Identity Graph is a core LiveRamp data asset and technology. It is a people-based map connecting de-identified offline touchpoints and online devices. LiveRamp’s goal is to optimize the Identity Graph to provide the best:
Correctness: Based on fully deterministic linking processes and quality linking data
Completeness: One of the largest collections of connected U.S.-based devices (with growing international scope)
Privacy: LiveRamp is a leader in data privacy and prioritizes security and ethical data management in all of our technologies
LiveRamp deterministically matches offline personally identifiable information (PII: name & address, email, phone) and online devices to people-based IDs. There are three aspects to this process:
Offline PII merging: Resolving separate emails, postal addresses, and phone numbers to a single individual
Online device linking: Matching disparate devices to people-based pseudonymous identifiers
Offline to online: Merging these offline and online identity spaces into a unified, privacy-conscious, people-based ID space
Note
LiveRamp prioritizes accuracy and precision over reach. Although we offer the largest fully deterministic identity graph, we have less scale than probabilistic vendors. We are committed to continuing to focus on correctness and supporting accurate, people-based marketing use cases.
Offline PII Merging
A foundation of LiveRamp identity resolution is resolving separate emails, name and postal addresses, and phone numbers to single individuals.
LiveRamp’s offline PII merging is powered by AbiliTec, our patented offline recognition technology. AbiliTec brings together disparate representations of offline PII touchpoints, thereby enabling a single, current, and accurate view of an individual. This individual is represented by an AbiliTec Link.
The AbiliTec customer data management technology uses a superior, extensive, and nuanced set of hardened algorithmic rules acting on a multi-billion record set of historical reference bases to deliver linking technology that improves the accuracy and quality of client data. AbiliTec’s algorithms are optimized and trained against the AbiliTec knowledge base.
About the AbiliTec Identity Graph
The AbiliTec Identity Graph is actually a series of reference bases that are non-discoverable, multi-sourced data repositories. The knowledge bases are sourced from hundreds of contributors and contain multiple name, address, and email representations for individuals, as well as the associative data to resolve the data points to an individual over time.
In order to ensure the highest accuracy and quality, the knowledge bases are continually updated and benchmark tested. Data thresholds must be achieved and strict quality and compliance audits conducted. Before a new data source is added to the repository, LiveRamp carefully vets the source to ensure the compliance, quality, reliability, contribution value, and sustainability of the data.
Additionally, LiveRamp continuously monitors existing sources to ensure their quality. Improvements to the technology are made regularly in an effort to improve accuracy.
The knowledge bases include, but are not limited to the following information: consumer PII data, consumer touchpoint data, internal metadata and associative data, examples include:
consumer name
business name, address
consumer touchpoint data, such as e-mail address and phone number
internal metadata such as frequencies, classifications, and thresholds
The types of sources included in the knowledge bases include:
public record data
publically available data
self-reported information
The data contained within the knowledge bases is “non-discoverable,” meaning the data stored within it is not retrievable by any client, third party, or any LiveRamp associate who is not directly involved in its maintenance. It is only used for analysis to create and maintain AbiliTec Links.
Householding
Separate touchpoints of PII are linked to households via AbiliTec’s householding algorithms. The algorithm puts individuals into households if they are seen consistently living together over time. There is no requirement for individuals to have the same last name or have a specific relationship (e.g. married). For example, long time roommates who keep
moving together are likely to be grouped into the same household. Household groups are used to create LiveRamp's household RampID.
Online Device Linking
Online Device Linking is generated based on deterministically-observed linkages of devices and pseudonymized PII touchpoints passed to us by our network of match partners. Our algorithms use the pseudonymized PII from these partners to match devices to a RampID, LiveRamp's people-based identifier.
Device linkages are routinely validated to ensure a high degree of precision and accuracy. Our approach to maintaining the relevancy and accuracy of the online data focuses on ensuring high-quality data inputs.
Offline-to-Online
AbiliTec merges offline PII, resolving to an individual represented via an AbiliTec Link. LiveRamp uses PII to deterministically link devices and uses RampIDs to represent an online individual.
AbiliTec Links can be directly translated to RampIDs, creating a deterministic offline-to-online view of an individual. Via this translation, any offline or online data can be matched to the same RampID space.
Interpreting RampID, LiveRamp's People-Based Identifier
By focusing on people-based resolution, LiveRamp maintains the largest and most accurate people-based identity graph on the market. We match disparate cookies, proprietary platform IDs, mobile devices, and pseudonymized offline PII touchpoints to our common, people-based ID - RampID. Below you’ll find information to help you:
Interpret LiveRamp's people-based identity graph
Compare our graph to similar products on the market
Understand the levers that influence match rates
LiveRamp creates four types of RampIDs, through which we maintain distinct levels of how complete our personally identifiable information (PII - email, name and postal, phone) is for an individual; a single email is not treated the same way as a complete set of PII, increasing the accuracy and people-based utility of our graph.
The RampID type is denoted via the first two letters in the RampID:
Maintained: XY (e.g., XY1234wXyWPB1SgpMUKIpzA0I3UaLEz-2lg0wFAr1PWK7FMhs) A RampID representing an individual that LiveRamp fully recognizes. We are able to match multiple PII elements to this individual. Multiple online devices can (and likely will) be matched to a maintained RampID, enabling cross-device use cases. These RampIDs are 49 characters long.
Derived: Xi (e.g., Xi1234p_iYcKP7ZlvFwwK9EwR8GKl_VJqIWUhEaAFmHLAjNOQ9b6OQzSkA43XiVFcTYQ9X) A RampID representing a PII touchpoint that LiveRamp is yet to match to a complete set of PII. After validating full PII touchpoints and confidently resolving to an individual, we will convert to a maintained RampID. Multiple online devices can be matched to a derived RampID, enabling cross-device use cases. These RampIDs are 70 characters long.
Placeholder: Xc (cookies) / Xm (mobile) (e.g., Xc1234p_iYcKP7ZlvFwwK9EwR8GKl_VJqIWUhEaAFmHLAjNOQ9b6OQzSkA43XiVFcTYQ9X) Many LiveRamp clients do not receive placeholder RampIDs. Placeholder RampIDs have no PII touchpoints but do have associated online devices. Until we have PII tied to this device, we will consistently return the same placeholder RampID for this device, enabling consistent recognition online. These RampIDs are 49 characters long.
Household: hY (e.g., hY1234wXyWPB1SgpMUKIpzA0I3UaLEz-2lg0wFAr1PWK7FMhs) A RampID representing a household, tied to 1 or several maintained RampIDs (derived and placeholder RampIDs don’t have household RampIDs). These RampIDs are 49 characters long. More information about LiveRamp's householding technology can be found in "RampID Methodology".
LiveRamp’s people-based identity graph uses fundamentally different methodologies than probabilistic cross-device graphs.
In general, our people-based identity provides accuracy, people-based ID consistency, and limits false positives. Although probabilistic cross-device graphs may produce higher reach, they also offer lower precision and significantly more false positives. Check out our write-up on the differences here to help determine which is right for your goals and strategy.
A cookie, mobile device, or proprietary user ID may be matched to a placeholder RampID, meaning LiveRamp has no PII tied to that online device/user. When we do get PII for that device/user, the placeholder RampID will be changed into a derived or maintained RampID. The next mapping file or Real-Time Identity Service call for this cookie will have the updated RampID.
Sometimes the underlying graph changes as we add additional PII to existing maintained RampIDs or create new ones; in those cases the RampID for a device might change as well.
LiveRamp does not provide mappings of old RampIDs to new RampIDs or provide indication when a transition occurs. This can be handled by simply overwriting the RampID you have in your system tied to a given device/user with the new RampID while maintaining data you had previously associated to that device/user.
Fairly regularly, LiveRamp will maintain multiple RampIDs for a single, real-world individual. This occurs when LiveRamp has not yet resolved different pieces of PII to a single individual; each piece of PII is therefore assigned its own RampIDs. We follow this approach to prioritize accuracy over optics; ideally LiveRamp will always have all PII touchpoints merged for an individual, but our algorithms will only merge this data when we are extremely confident they are tied to the same individual.
For example, say LiveRamp has RampID XY123 tied to the email bob@bob.com and postal address Bob Lincoln 123 Street Cincinnati, OH. If Bob gets a new email, LiveRamp will need to see that email associated with Bob’s postal address a certain number of times before associating the new email to Bob’s existing RampID. In the meantime, the new email would be assigned a new RampID, Xi456.
After LiveRamp has seen the necessary touchpoints to accurately tie this new address to the existing profile, the new address will be updated to match to the existing XY123 RampID for Bob. LiveRamp’s massive online and offline footprint allows us to do this both quickly and accurately.
This system allows LiveRamp to prioritize accuracy and greatly limit the number of false positives in our graph, rather than merge consumer data prematurely and inaccurately. LiveRamp is continuously updating the RampID graph with the most up-to-date offline data to enable quick and precise profile merging.
LiveRamp’s people-based identity graph can be delivered via two methods.
LiveRamps provides a pixel (e.g. id.rlcdn.com/455509.gif) that can be placed on any web page or advertisement. When the content loads, if LiveRamp can cookie the browser, we match and return a RampID to your server. This enables real-time people-based insights.
By cookieing the same browser on which you’ve placed the Real-Time Identity Service pixel, you can capture cookie-to-RampID relationships and build a mapping over time.
LiveRamp can send files that map cookies, user IDs, and mobile devices to RampIDs on a regular cadence. Here’s an example of a cookie-to-RampID mapping file:
We deliver separate files for cookies, user IDs, IDFAs, and AAIDs. Delivering user ID-to-RampID mappings requires additional privacy consideration to ensure RampIDs cannot be directly tied back to PII.
Mapping file delivery options:
Daily incremental updates: Receive daily updates to your RampID file. Note that the incremental file will not contain the full file with updates, but only the updates.
Daily backlog delivery: Receive 1/Nth of all 90 days of users LiveRamp has in sync with your platform, where N is the number of days in the given month. Some of our partners expire device IDs they haven’t seen in the past X number of days, so our aim is to keep those users refreshed. The backlog will consist of previously synced RampIDs.
Full refresh: Receive a full RampID mapping file, including incremental updates. Set cadence: Day, Week, Month.
Files can be delivered to your SFTP or S3.
LiveRamp has the largest deterministic identity graph available on the market, with PII maintained on 245 million individuals in the U.S.. Here are some factors to consider when measuring the output of LiveRamp’s people-based Identity graph.
Recognition rate is the percentage of input identifiers (offline PII or online devices) LiveRamp can match to a maintained or derived RampID. If one individual has 4 cookies and LiveRamp matches one to a maintained or derived RampID, we have a 25% recognition rate on that pool of devices.
Activation match rate is the percentage of input identifiers (offline PII or online devices) that LiveRamp can match to at least one device synced with a specific partner or end destination. If one individual has four cookies and LiveRamp receives this individual’s email for onboarding, as long as we match that email to a single cookie at the specified destination, we will have a 100% onboarding match rate.
Due to these definitions, in most instances match rates for offline PII to cookies will appear to be higher than recognition rates for online devices to RampIDs. Here’s an example:
Joe has 4 devices he uses regularly. One of Joe's devices LiveRamp has tied to Joe’s PII via our match network. If we onboard PII for Joe, we can match it to that one device and have a 100% match rate for Joe. If we are looking at Joe’s web traffic, we only recognize 1/4 Joe's devices, so our recognition rate for Joe is 25%.
In-App Mobile Web Views
Cookies collected from in-app mobile web views are likely to have significantly lower recognition rates than cookies placed on standard mobile browsers. In-app mobile browsers operate in a different cookie space than standard mobile browsing, even on the same device, and are less represented in LiveRamp’s match network.
Cross-Device Linkages
Most clients will see the highest number of cross-device linkages cookie-to-cookie, with fewer cookie-to-mobile and mobile-to-mobile linkages. LiveRamp is an industry leader in scale of deterministic cross-device linkages, but we do not offer as many linkages as probabilistic cross-device graphs (read about this here). LiveRamp is focused on increasing the scale of our cross-device linkages while maintaining our high accuracy standards.
Bot Traffic
Since no PII is available, we are usually not able to match devices captured via bot traffic to maintained or derived RampIDs. Some estimates show bots account for more than 50% of programmatic web traffic. Higher bot traffic across your footprint will lead to fewer of your devices matching to a maintained or derived RampID.
A) Volume Sync Quality
The more often you sync IDs with LiveRamp, the more of your IDs we’ll be able to match to a maintained or derived RampID and potentially tie to a mobile device. Syncing with LiveRamp across a larger footprint, or moving us up in your syncing priority, can lead to higher cookie and mobile match volume.
B) Length of Time
Syncing with LiveRamp more over time will increase the total number of devices we have data for. LiveRamp maintains devices for 90 days, so any sync that’s been active for less than 6 months can benefit from more time.
International Traffic
LiveRamp maintains more PII on residents of the USA than other countries. Non-U.S. traffic can lead to fewer matches to maintained and derived RampIDs, and a higher ratio of derived RampIDs between the two.
Device opt-out: If a user opts out their device, they will be opted out at the device ID level. An incremental mapping file will include a RampID of '0' for that device ID.
Email opt-out: If a user opts out their email, they will be opted out at the RampID level. An incremental mapping file will include a RampID of '0' for all devices associated with that RampID.
How LiveRamp Addresses Fragmented People-Based Links
This article describes how LiveRamp handles fragments of data to deliver value while maintaining accuracy.
Composition of our Match Network
Understanding fragmentation in the graph begins with the data the graph is composed of. The LiveRamp Identity Graph is composed of three linkage networks, the LiveRamp offline and online match networks, and LiveRamp’s partner network of online integrations.
Why Linkage Data are Fragmented
Within the offline and connecting data match networks, LiveRamp is constantly dealing with fragmented ID data as evidence. We deal with one-off device touchpoints tied to only email hashes, others tied to a name and postal combination, and some with both. Our offline recognition data sources are vast and sometimes offer conflicting data points as one set is more updated than the other.
Building Blocks and Personas
LiveRamp believes the best way to deal with these fragmented blocks of ID data is to maintain them as separate entities and deliver them to clients as groupings (a group of people-based blocks forms a persona, which ties to a client record).
We do this by maintaining multiple RampIDs for a single individual because our system does not automatically assume that separate pieces of PII in a record are tied to the same individual. To do so would introduce high levels of inaccurate links between individuals sharing names or addresses.
Every RampID corresponds with one or more pieces of PII. Some are stronger than others. Some RampIDs can serve as the building blocks of a full identity and are then merged to form a stronger RampID.
The multiple RampIDs returned can also mean that the customer record contains PII from more than one individual. An example of this would be a record with the name and email of one individual but the household and phone of another, with shared PII between the two.
Merging of multiple RampIDs into one only occurs when there is a high degree of confidence that separate identifiers are tied to one person. This is not instantaneous, and LiveRamp is committed to keeping these building blocks of identity separate as the system learns where they truly fit with the most confidence.
The degree of confidence grows with the number of times we see the two links together
For example, if we see the RampID for bob@liveramp/Robert Rich 288 Whitmore St. Oakland match to a cookie, and another "rrch@gmail" RampID match to that same cookie, we will not immediately merge these.
After LiveRamp sees the necessary evidence to confidently tie new information to an existing profile, this information is updated and merged to the existing individual’s RampID.
FAQs
Question: Does this mean we'd be unable to provide accurate people-based statistics? We need to provide people-based statistics to our marketing department. How would you recommend we obtain those numbers if we're partnered with IPG/Acxiom, which has +800m unique and "people-based" records in their database? In our conversations about this topic, the Acxiom team claims that each record is indeed designed to correspond 1:1 with a single person, but that's obviously not true.
Answer: Multiple RampIDs will not prevent accurate people-based statistics. The RampIDs that are tied to a client record will allow them to tie impressions to that record based on deterministic, people-based login data that we have observed. They can then use the group of RampIDs tied to that particular record to recognize the record’s journey across multiple platforms for people-based customer journey analytics. Furthermore, the IDs Acxiom is referencing are designed to consolidate down to single persons when the data are complete. Data are always changing and as new pieces of people-based information are considered, IDs are created to deal with them. These additional IDs do not nullify the recognition and resolution capabilities of the AbiliTec product, they are an early stage of evidence that must be accounted for.
Question: How often are two maintained RampIDs combined? How common are two derived RampIDs or one derived and one maintained RampID combined?
Answer: The rate at which this happens depends on the data that Abilitec observes from multiple sources. Historically, the graph has only changed 1-2 percent per quarter, but the source bank is improving in the next year to support 200% more email exposure, and will therefore improve vastly in resolution capability.
Question: What kind of new information would cause RampIDs to be merged? Will the IDs be merged into a third, net new ID or into one of the existing values? Will the merge events be communicated to us? Should we retroactively apply the merged RampIDs to our data?
Answer: RampIDs will consolidate into one when they are proven to belong to the same strong ID, but this is generally an unlikely occurrence. Rather, you will see the linkages associated with the outdated RampID move to the current one, and for the outdated RampID to appear in fewer matches as a result. The emergent data that cause this include new authenticated logins, AbiliTec’s new email recognition, updated movement or name change data, and new PII from verified AbiliTec sources. Graph clients will receive a refreshed graph with updated linkages periodically.
Question: How does LiveRamp treat instances where a single RampID is matched to multiple input lrecords? What happens when a single device has more than one RampID? How does LiveRamp treat shared PII, such as a home phone number?
Answer: A single RampID matched to multiple PII records is a common occurrence that may happen because the customer data can have mixed PII fields (eg: a college student in a dorm signs up for a long term service with their family home address). When dealing with a data set where there are shared RampIDs between input records or devices, LiveRamp uses selection logic to provide the best matches for the client’s use case. For more information on how this works and to ensure consistency between the use cases a client is activating, we can help the client harmonize the logic used in these edge cases and make an educated decision.
Question: I am an onboarding and measurement customer. I sent DBM cookies through LiveRamp based on my CRM, but why do the matched cookies from my impression file not align with any RampIDs from my CRM data?
Answer: This occurs because the cookies that match to your RampIDs are a greater pool than that which aligns with our DBM cookie sync, meaning the alignment will not be exact. There will be RampIDs in your CRM that do not match to your DBM cookie pool, and there will be extra RampIDs matching to your DBM cookies that do not match with your CRM. This occurs because of the reasons explained above. For a measurement use case, you would only use that which exists in both pools.
Platform Guide to Connected TV Targeting and Measurement
With RampID, platforms with Connected TV (CTV) viewer data can perform advanced activation and measurement. This includes gaining insights for first-party data as well as appending third-party data to their CTV audiences for improved media monetization.
LiveRamp matches a platform's CTV IDs to RampIDs (LiveRamp’s people-based IDs) and makes that data available in the desired LiveRamp UI. Platforms can then buy third-party data from the LiveRamp Data Marketplace and connect that data to those CTV IDs for use in TV targeting.
In addition to Connect, LiveRamp offers the Advanced TV UI for building custom audiences and sizing against the platform's owned and operated footprint.
There are two integration options to choose from:
Client CTV graph build: Enables onboarding, activation, and measurement via Connect, Safe Haven, Advanced TV, and Measurement Enablement. This integration option takes advantage of the full client CTV footprint tied to RampID and requires a 2-3 week lead time to set up.
LiveRamp CTV graph: Enables onboarding and measurement via Connect and Measurement Enablement. This integration uses LiveRamp's CTV contributor graph and requires minimal lead time to set up.
Caution
CTV data only! IP addresses can only be used to match CTV device IDs to RampIDs. Data must be stored/used via the CTV device ID to ensure consent tracking. IP addresses are discarded after matching. IP addresses cannot be included as identifiers for other matching types.
Contact your LiveRamp representative for more details on next steps, depending on which integration type you want to implement (client graph or LiveRamp graph).
Client Graph Recommendations
The more data you provide, the better. For client graph builds, LiveRamp uses a rolling 90 day lookback window. To start syncing with LiveRamp, we recommend sending at least 30 days of the most recent data in order to produce accurate matches at scale. Once the initial delivery occurs, we recommend a daily or weekly file delivery with new data that you have recorded.
If you have a “truth set” of viewer data (SHA-1, MD5, and SHA-256 hashed email addresses tied to CTV device ID), LiveRamp can use it to improve the accuracy and reach of matching. Contact your LiveRamp account team to coordinate delivery.
LiveRamp highly recommends sending only IPv4 IP addresses. You can send IPv6 IP addresses but in most cases we will not be able to match to those.
Sending CTV Ad Request Data for a Client Graph
You can get your CTV event data to LiveRamp either via pixel calls or by sending us data files via any of our allowed methods (see "Getting Your Data Into LiveRamp" for more information).
Note
Once your ad request data has been uploaded, it typically takes 2-3 weeks before your private CTV graph is ready to use in your desired LiveRamp UI. After this initial setup phase, your private graph acts as the identity spine for ingesting your first-party segment or exposure data, and typical ingestion timelines apply..
To send CTV ad request data via pixel calls, follow the instructions in “Enable CTV Targeting by Sending CTV Events via Pixel”.
To send CTV ad request data via files, follow the instructions in “Enable CTV Targeting by Sending CTV Event Files”.