Interpreting RampID, LiveRamp's People-Based Identifier

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:

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.

Real-Time Identity Service

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.

See "Implementing LiveRamp’s Real-Time Identity Service Tag" for more information.

RampID Mapping Files

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:

Files can be delivered to your SFTP or S3.

See "RampID Mapping Files" for more information.

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.

Why are Recognition Rates for Online Devices Lower than Offline Activation Match Rates?

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 Activation, as long as we match that email to a single cookie at the specified destination, we will have a 100% Activation 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.