File Output Options for File-Based Recognition Workflows
When you upload a file into our File-Based Recognition (FBR) workflow for measurement use cases, LiveRamp replaces the input identifiers (such as PII, cookies, mobile device IDs, and CIDs) with their associated RampIDs and returns the file to the location you specify. Unlike files that go through our onboarding workflow, LiveRamp does not ingest any identifiers or segment data and does not create segments in an FBR workflow. For this reason, you can think of the FBR workflow as “file in, file out”.
When you upload a file into our File-Based Recognition (FBR) workflow for measurement use cases, LiveRamp replaces the input identifiers (such as PII, cookies, mobile device IDs, and CIDs) with their associated RampIDs and returns the file to the location you specify. Unlike files that go through our onboarding workflow, LiveRamp does not ingest any identifiers or segment data and does not create segments in an FBR workflow. For this reason, you can think of the FBR workflow as “file in, file out”.
Note
FBR output files are often (but not solely) used for measurement and analytics, and are usually delivered back to you or to a measurement partner.
There are two output options available for FBR files:
One RampID per record
All available RampIDs per record
Note
The output option you choose is applied at the LiveRamp audience level, so that all files going through a given audience will have the same type of output (one RampID or all RampIDs).
In many situations, receiving all RampIDs is preferable. However, there are some situations where you might prefer to receive one RampID per record.
RampID Versions You Might Receive in Files
Whether you choose to receive one or all RampIDs per record, there are two versions of RampIDs you might receive: maintained RampIDs and derived RampIDs.
Maintained RampIDs
If we have a maintained record for the input data in our Identity Graph, we'll return a maintained RampID. A maintained RampID represents a person that LiveRamp can fully recognize. Multiple devices can usually be associated with a given maintained RampID. Maintained RampIDs are 49 characters long and start with "XY."
Derived RampIDs
If we do not yet have a maintained record for the input data in our Identity Graph, we'll generate derived RampIDs for each PII touchpoint (name and postal address, email address, phone number) for that input record. In addition, even for records where we have a maintained RampID there might be certain PII touchpoints that we haven’t yet confidently tied to that record, so we’ll generate derived RampIDs for those touchpoints as well.
Why Records Might Have Multiple RampIDs
In an ideal marketing world, LiveRamp would always have all PII touchpoints merged into a single individual. In reality, LiveRamp often manages multiple RampIDs for an individual.
This is because people are dynamic: they move houses, change jobs, switch phones, share computers, and upgrade their tech. In the U.S., in 2018 alone, there were 36 M residential moves, 4 M births, 2.2 M marriages, and almost 800 K divorces. Each of these events might create a new PII touchpoint. When we observe a new piece of PII, we create a RampID for that touchpoint.
Over time, each of these events builds a more complete picture of that person’s identity. But until we are able to confidently recognize and prove that these new PII touchpoints are tied to that one individual, we might associate multiple RampIDs with that individual’s data. Once we have a high degree of confidence that the new touchpoints are tied to that individual, we merge those RampIDs into a single maintained RampID.
Thanks to our massive online and offline footprint, we are able to successfully do this more accurately and faster than any alternative.
Multiple RampID Example
For example, say you’re targeting men in Boulder, CO with an email campaign. Email addresses for Bill Jenkins, Billy Jenkins, and William Jenkins appear separately in your targeting file.
Within our graph, each email address has its own RampID (example: XY123, XY456, Xi789). As we observe some common linkages across the three RampIDs (e.g., name and postal address, phone), over time, LiveRamp will learn that Bill, Billy, and William are the same person.
Receiving One RampID Per Record
In some cases, like attribution, where accuracy and precision are the biggest concerns, it might be preferable to choose to receive one RampID per record.
For this option, LiveRamp auto-selects one consistent RampID per individual from our Identity Graph. When available, the maintained RampID is selected.
When there are multiple maintained RampIDs associated with the record, one is selected at random and used consistently.
If there are no maintained RampIDs associated with the record, the derived RampID is selected. When no maintained RampID is available and there are multiple derived RampIDs associated with the record, we select one of them in a consistent and repeatable way.
Receiving All RampIDs Per Record
Having multiple RampIDs per record creates a more accurate view of the digital world and the consumer. This is because devices can be shared, and many people have multiple email addresses, home addresses, and workplace addresses. Today, clients need to link multiple data sets across the offline and online worlds, and receiving multiple RampIDs increases overlap rates across data sets.
Reach is a critical marketing metric - brands, agencies, publishers, and platforms need to be able to measure and prove reach delivery. Multiple RampIDs help clients meet their reach and frequency measurement requirements without a major degradation in accuracy.
Note
Work with your LiveRamp technical support team to ensure smooth delivery of multiple RampID files.
Discuss pricing implications with your LiveRamp Account Account Director.
Tying Multiple Files Together
In order to tie disparate datasets together, use the RampIDs column.
Note
If you opted for the LiveRamp-provided grouping indicator column, we cannot guarantee that the order of the grouping indicator will be the same across different files even if the input identifier is the same. This is because we randomly shuffle the output row order for privacy reasons. Also, to comply with privacy and data ethics requirements, a different hash will be used for the grouping indicators in each file.
FAQs
Due to the complexity of the ecosystem and the multiplicity of touchpoints for a single person, it is often hard to resolve all person-level and device-level touchpoints to a single RampID with certainty. Therefore, the Identity Graph contains more than one RampID for a person until such time as we can consolidate with a high degree of confidence.
When we observe a new piece of PII, we create a RampID for that touchpoint.
LiveRamp’s foundational system for resolving offline Identities, AbiliTec, performs the role of determining which pieces of personally identifiable information (PII) represent a “person.” Thus there are times when a client's CRM data considers multiple pieces of PII to be the same when AbiliTec does not yet see sufficient evidence to merge them. This will allow us to maintain our verification standards, while delivering higher match rates within a client's CRM data, maximizing reach.
In addition, our Online Identity Graph might contain several derived RampIDs for a given email touchpoint because we typically have a different derived RampID for each of the three email address hash types in our graph.
One offline identifier (i.e., an email address) can be tied to more than one RampID because email addresses can be shared and therefore could be associated with several names and postal addresses (NAP). For instance, a family email address could be associated with the NAP of the parents and the NAP of the son who moved out to go to college.
One online identifier (i.e., a cookie) can be tied to more than one RampID because we have shared devices. For instance, if a computer is shared by multiple people and they use different emails and PII but might still keep sessions open, cookies can be associated with more than one piece of an identifier and therefore more than one RampID.
People are dynamic: They move houses, they change jobs, they switch phones, they share computers, they upgrade their tech, and they are exposed to marketing on the move across multiple channels.
The marketing ecosystem is dynamic: The multiplicity of marketing touchpoints - creatives/ impressions/channels/media - across multiple devices for every single person is complicated to disentangle and connect back to individuals.
It takes time to build a consolidated, complete view of an individual as LiveRamp/AbiliTec starts to recognize and prove the different PII touchpoints are accurately tied to one person. This is not instantaneous.
Merging (reducing the number of RampID s per individual) happens only when there is a high degree of confidence that separate identifiers are tied to one person.
When AbiliTec sees the necessary validation to confidently tie new information to an existing offline profile, this information is updated and merged to the existing individual’s LiveRamp RampID .
Receive all RampIDs associated with a given touchpoint, such as a unique creative, message, email, call center contact, or sales transaction.
Increased overlap rates across data sets
Better visibility across the customer journey
Alignment with activation/onboarding process, which already outputs multiple RampIDs
Greater consistency across LiveRamp use cases
...while maintaining confidence and accuracy within each RampID
If you're seeing a low recognition rate for you file, there are a number of possible reasons:
The input identifiers are poorly formatted. Examples of this include zip codes with 6 digits or email addresses with no "@" sign. For CIDs, this might be sending a 20-character CID value when LiveRamp is expecting a 16-character value.
The input identifiers are invalid because they contain entries such as "null", "n/a", "0", or ",".
There's a low overlap between your source data pool and LiveRamp's identity space (if you have an identity space that we don't have data for).
There was a change in identity space on your side or the LiveRamp side (this is more likely if there was a sudden drop in recognition rates). For example, this change might occur if you change the way you refresh your identity.
Many LiveRamp customers (as well as many AdTech companies in general) have been seeing a decrease in their MAID (mobile device ID) recognition rates. While LiveRamp continuously works to improve the MAID data in our Identity Graph, we think that this decrease is mostly due to a number of industry changes, including:
Apple’s Application Tracking Transparency framework
Greater consumer access to managing the mobile advertising ID on their devices
New regulations and privacy laws
For more information on each of these issues, see the sections below.
These changes, along with the normal consumer behavior of upgrading devices, mean that we are observing the average lifetime of MAIDs decrease. We expect that there will continue to be more consumer choice in consenting to collect these signals.
For LiveRamp’s match data sources (that we use to build our MAID graph), this means that we have to cast a wider net as we need more data to get the same amount of valid linkages that we had before these frameworks were put in place. We also see a decrease in the longevity of MAIDs as once valid MAIDs are become invalidated through these frameworks. We have been updating our sourcing strategy to counteract these changes.
We also continue to recommend ATS (Authenticated Traffic Solution) as a more forward-looking alternative. For more information, see "Authenticated Traffic Solution".
Apple’s Application Tracking Transparency Framework
Much of this change started when Apple implemented Application Tracking Transparency (ATT), in which a consumer must consent to the tracking of personal information for each application. For many application owners, this resulted in a drastic decrease in the ability to collect and tie a MAID to other pieces of personal information of the consumer (such as email).
The impact doesn’t seem to be as significant if the application is well trusted and respected. In those cases, consumers seem to be willing to opt-in to targeted advertising at a higher rate than an application that is not as well known. However, even for trusted applications the ability to collect this data is still well below what we were observing before ATT was released.
Greater Consumer Access to Managing Mobile Advertising IDs
In addition to ATT’s per-application opt-in, consumers now have much more access to their advertising ID on phones than before. In Android 12 and beyond (which does not employ the same framework as Apple on app opt-in), Google allows users to delete their Advertising ID more easily through their privacy settings, whereas, in the past, this was not easy to do.
New Regulations and Privacy Laws
State regulations and privacy laws are also contributing to the decrease. In Virginia for instance, precise geolocation is now classified as “sensitive data”, which requires special obligations to collect and sell for applications. All of this puts pressure on application owners who provide this type of data.
In some cases, like attribution, it makes sense to choose a single ID. For instance, Google (through the Google Store Transaction product) requires a single ID to be returned to them.
Another reason is that some clients use RampIDs as database keys and do not necessarily need identity resolution.
Also migration to multiple RampIDs may be difficult or impossible for some clients to switch to, so we are maintaining both options.
When you run files through FBR and receive one RampID per record, you received a file with the same number of rows as the input rows, and one RampID per row. If you choose the option to have all RampIDs returned, you will receive an output file that still has one RampID per row, but where rows are duplicated if more than one RampID was found. You can optionally add a column to indicate how RampIDs should be grouped together. This grouping is based on which row the RampIDs came from. For privacy reasons, you will however not be able to tell which of the input row each grouping of RampIDs corresponds to, as we shuffle the row order.
In order to tie disparate datasets together, use the RampID column.
If you opted for the LiveRamp-provided grouping indicator column, we cannot guarantee that the order of the grouping indicator will be the same across different files even if the input identifier is the same. This is because we randomly shuffle the output row order for privacy reasons.
Also, to comply with privacy requirements and data ethics considerations, a different hash will be used for every file.
Upon completion of LiveRamp processing, the final step of data aggregation, joining RampID s to individuals, will need to be performed.