Identity and Identifier Terms and Concepts

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.

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.

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.

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.

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.

Figure 1. Ungrouped RampIDs with some shared edges

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).

Figure 2. RampIDs grouped to different records

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.

Figure 3. Selecting strong RampIDs

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.

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.

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.