Skip to main content

File-Based Recognition Workflow

When you send LiveRamp a file to process via our File-Based Recognition (FBR) workflow, we transform the input identifiers (such as PII, cookies, mobile device IDs, and CIDs) into their associated RampIDs and return the file to the location you specify. Unlike files that go through our Onboarding workflow, LiveRamp does not ingest any identifiers (other than for the purpose of transformation into RampIDs) 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".

Depending on your workflow, you can choose to configure the files to include one or all RampIDs and to either include or remove any rows that do not match to a RampID. See the sections below for more information.

You can view the recognition rate (the percentage of rows from your file we matched to) in the Connect UI (see the "View FBR File Info" section below). The recognition rate for a file is calculated by dividing the number of matched rows by the total number of rows.

Once your file contains RampIDs, you can then tie the original dataset to any other source you have linked to RampID. General use cases for this workflow include measurement, targeting, exposure, conversion, and more.

Tip

Customers considering using an FBR workflow for measurement might be interested in the Measurement courses in the LiveRamp University section of LiveRamp Community.

To start utilizing an FBR workflow, contact your LiveRamp representative.

Note

When you first use an FBR workflow, the LiveRamp Implementation team will work with you to set everything up. If you need to add an additional data feed for a new set of files after your initial implementation, follow the instructions in "Set Up a New File-Based Recognition Data Feed."

FBR Workflow Example

Let’s say you send us a file that contains email addresses and segment data for an FBR workflow.

FBR Workflow example input-3h0.jpg

We perform automated privacy checks, match each line to a corresponding RampID, remove the email address field and randomize the row order.

FBR Workflow example step two new-V7I.jpg

RampID Options for FBR Output Files

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 available RampIDs is preferable. However, there are some situations (like attribution use cases, where accuracy and precision are the biggest concerns) where you might prefer to receive one RampID per record.

For customers who choose to receive one RampID per record, when there are multiple maintained RampIDs associated with the record, one is selected at random and used consistently.

If your use case emphasizes reach and frequency, you might prefer to receive all available RampIDs for each record. With this option, LiveRamp generates a grouping indicator for each input row and adds that to each row in the output file that contains an associated RampID (see “Receiving All RampIDs Per Record” for more information).

In most workflows, it's best to receive all RampIDs per record, to make sure your data can overlap with other data sets at the highest rate possible.

For more information on the types of RampIDs you might receive, see the sections below.

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 to 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 Executive/Account Director.

Choosing a Grouping Indicator for Multiple RampID Files

Once we match your records to all the RampIDs we associate with each particular record in your file, we create one row per associated RampID and randomize the row order. To enable you or your measurement partner to tie together all the RampIDs associated with each input record, you need a way to group those associated rows.

Our preferred method to accomplish this is through a LiveRamp grouping indicator that we generate and add to the file. The LiveRamp grouping indicator is a hashed number that corresponds to an input row. For privacy reasons, it cannot be tied back to the actual input row number, but it allows you or your measurement partner to be able to group the RampIDs by input row. Here’s an example of what the output file would look like when using a LiveRamp grouping indicator.

Multiple IDLs Grouping Indicator Example-tdM.jpg

Note

It is not recommended, but if you prefer, you can also provide your own unique input column (for instance a client ID or transaction ID) in the input file, which we will use as a grouping indicator and then hash before returning. Talk to your LiveRamp representative if you want to provide your own grouping indicator.

Send your FBR Data to LiveRamp

Create Files

Make sure to properly format your files so that we can process them quickly. It’s especially important to keep the following key guidelines in mind:

  • Ensure your file contains identifiers that LiveRamp can recognize. A list of these identifiers can be found in our content on known identifiers and anonymous identifiers.

  • Once you decide on a format for your initial files, the column headers for the identifier columns that we use for matching must stay exactly consistent in subsequent files.

  • If you’ll be sending files with different identifier types (for example, if you’ll be sending both files with PII and files with mobile device IDs), let your LiveRamp Implementation Manager know. Otherwise, we will assume that all files contain the same type of identifiers.

  • LiveRamp's file limits.

  • For files containing PII, do not include unique values (a value that appears in only one row) in a segment data column. If a unique segment value is found in a row in a PII file, LiveRamp will not be able to provide the unique value next to RampIDs to maintain the anonymity of the RampIDs. In certain cases where unique values must be included in the output file, work with your LiveRamp representative to obtain a privacy approval from our team.

Note

New Customers: Let your Implementation Manager know how many distinct file formats you’ll be sending (formats with different column headers and different identifier data fields).

Send Files to LiveRamp

Once you’ve decided on your distinct file format, you can send your data to us in a number of ways. In general, we recommend that you either upload your data via SFTP or have us retrieve it from an AWS S3 bucket.

Note

New Customers: Let your Implementation Manager know which file delivery method you’d like to use.

After you've uploaded your file or files, you'll need to wait 1-3 days for us to process the data before the output file will be available for pickup.

Note

If you don't see the file after 3 days, use the Troubleshoot File Delivery / Output for Existing File-Based Recognition Workflow quick case to create a support case.

Excluding Unmatched Rows

By default, the FBR output file will include all input rows, including those rows that did not match to a RampID. If desired, you can specify that unmatched rows be excluded from your output files.

You might want to exclude unmatched rows for one of the following reasons:

  • You don't get use out of unmatched records

  • You want to reduce delivery volume

  • You want to deliver data to an API and remove unnecessary traffic

Note

Excluding unmatched records from the output file will not have an impact on File-Based Recognition billing as that is based on the number of input rows.

When you set up a new FBR feed, you can specify that you want unmatched rows excluded. To exclude unmatched rows from an existing workflow, create a support case.

FBR File Delivery Options

After 1-3 business days, the output file will be available for pickup. Typically, LiveRamp drops the output files into an SFTP we set up for you. We do have other options available for delivery, including AWS S3, your operated SFTP, GCS, and Microsoft Azure Blobs. See “Setting Up LiveRamp File Deliveries” for more information. Work with your LiveRamp representative to set up your preferred delivery location.

Now that your file contains RampIDs, you can now tie the original dataset to any other source you have linked to RampID. General use cases for this workflow include measurement, targeting, exposure, conversion, and more.

View FBR File Info

For each FBR file we process, you can view the following info on the Files page in Connect:

C-_Check__Status__of__Uploaded__File-_FBR_audience_columns.png
  • The date the file was received

  • The status of the file

  • The number of rows in the input file

  • The recognition rate (the percentage of valid rows in the file that were matched to a maintained RampID)

To navigate to the Files page, click Files in the Connect navigation menu and then select your FBR audience from the Audience dropdown.

You can also open a details panel that displays additional information. See "Check the Status of an Uploaded File" for more information.

Note

Since LiveRamp does not store any segment data for this workflow, there is no data manipulation within the Connect UI.

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 every file.

Set Up a New File-Based Recognition Data Feed

A "data feed" is a set of files you send through a File-Based Recognition (FBR) workflow. If you want to set up an additional data feed through an FBR workflow after your initial implementation, follow the steps below to create a case in the LiveRamp Community portal with the required information.

Using the info you provide, the Technical Operations Manager working on your ticket will determine if the new data feed requires a new audience.

Use the Set Up a New File-Based Recognition Workflow quick case to create a support case that includes the following information:

  • Identifiers: Specify the type of identifiers your data uses (select one type per feed):

    • Offline Identifiers: Email, Name and Postal, Phone

    • Online Identifiers: Cookies, Mobile IDs, Custom Platform IDs from <insert platform>"

    • RampIDs

  • Output option: Specify the type of output you would like for your File-Based Recognition file: Multiple RampID or Single RampID (see "RampID Options for FBR Output Files" for more information).

  • Grouping indicator: For workflows that use the Multiple RampID option, specify whether you want us to include a grouping indicator or whether you want to provide your own unique input column to use as a grouping indicator.

  • Unmatched rows option: Specify whether you want us to include rows that did not match to a RampID (the default) or exclude those unmatched rows.

  • Provider: Specify the entity that will be providing the files to LiveRamp for this workflow (Your company, your partner, etc.).

  • Upload method: Specify which method the provider will use to send us files for the new feed (see "Getting Your Data Into LiveRamp" for a full list of LiveRamp's upload options).

  • Upload path: Specify the full path on the server that the files are going to be uploaded to (i.e., "s3://liveramp/imports/File Based Recognition files" or "/uploads/new_file_based_recognition_data_feed/").

  • File name: Specify the expected file name(s) for the first file.

  • Recipient: Specify the entity that LiveRamp should send the File-Based Recognition output files to.

  • Delivery method: Specify which delivery method LiveRamp should use for sending the output files to the recipient (see "Setting Up LiveRamp File Deliveries" for a list of LiveRamp's delivery options).

  • Delivery path: Specify the full path on the server that the files will be delivered to (i.e., "s3://liveramp/imports/FBRfiles" or "/uploads/FBRfiles/").

  • Notification email addresses: Specify the email address(es) you would like us to use for the email notifications that File-Based Recognition files have been delivered.

  • CC list: Specify the email addresses for any additional people you would like to have CC’d on this support ticket.

  • Additional info: Include any additional info that will help us understand the context of your request.

See the description below for an example of what a populated description might look like:

1. Identifiers: Offline - Email Addresses
2. Output option: Multiple RampID
3. Grouping indicator: Use LiveRamp grouping indicator
4. Unmatched rows option: Exclude unmatched rows
5. Provider: Company A
6. Upload method: LiveRamp SFTP
7. Upload path: /uploads/FBRfiles/
8. File name: /uploads/FBRfiles/firstFBRfile.csv
9. Recipient: Company B
10. Delivery method: S3 Bucket
11. Delivery path: s3://liveramp/imports/FBRFiles
12. Notification email addresses: Example@example.com, FBR@example.com, Lead@example.com
13. CC list: No thanks!
14. Additional info: We are trying to have this setup by Monday (5 days away) Please let me know if you need any additional info to get this new audience started. Thank you for your help!

Once we've aligned with you on the required information, your new data feed will be set up in 3-5 days. After set up, new files for this feed will be processed in 1-3 days.

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.

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 RampIDs 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, 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

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 RampIDs to individuals, will need to be performed