Skip to main content

Processing Data Subject Rights Requests

At times, a consumer might make one of the following data subject rights requests:

  • Request to opt out of the sale or sharing of their personal information

  • Request that their personal information be deleted

  • Request access to information about what personal information is being held and how it is being used (subject access requests)

  • Request to correct inaccurate personal information

See the appropriate sections below for information on sending requests to LiveRamp, on retrieving subject access request information from LiveRamp, on retrieving opt-outs and deletions from LiveRamp, and on requests to correct inaccurate personal information.

For questions on implementation, create a case on the LiveRamp Community portal. If you do not have access to the portal, contact your LiveRamp account team.

How LiveRamp Processes Requests

The sections below explain how LiveRamp processes the various types of consumer requests for all workflows except File-Based Recognition (FBR). For information on how we process requests for that workflow, see the “File-Based Recognition Workflows” section of this article.

Opt-Out, Deletion, and Correction Requests

LiveRamp has developed processes to incorporate opt-outs and deletion requests into our data delivery workflow. These processes affect both customers and partners who send us data and customers and partners who receive data from us. Once we’ve ingested the request data, LiveRamp implements the requests in our systems.

  • For deletions: We delete that consumer’s information from that client’s databases in our systems. Deletion requests are completed within 45 days.

  • For opt-outs: We store that information in an opt-out database. We then check all future uploaded Onboarding and Data Marketplace files containing consumer personal information against the client’s and LiveRamp’s opt-out database to ensure opted-out consumers are no longer part of workflows until their preference status has changed. Clients should remove opted-out consumers from File-Based Recognition workflow files before uploading. Opt-out requests are completed within 15 business days.

  • For corrections: To simplify the process of correcting inaccurate personal information, the consumer will be fully deleted following a deletion request (see above), and replaced after you resubmit the consumer information with the corrected attributes. Correction requests are completed within 45 days.


To ensure continued compliance, once you have received a deletion request, refrain from uploading or including any personal information associated with that consumer, unless you intend on replacing that consumer’s information with their corrected attributes to fulfill a correction request.

For both request types, we convert the input identifiers to the identifiers that are used for each active destination and then make those opt-outs and deletions available to your favorite downstream onboarding destinations.

Subject Access Requests

When you send us a subject access request, we run lookups against all the data we are currently holding in your LiveRamp audiences in all of the LiveRamp systems that that consumer’s personal information has been used in (such as the Data Marketplace or in Onboarding workflows). However, we do not run lookups in LiveRamp data or other client data.

We then generate a file with the information on that consumer which you can then download from the LiveRamp SFTP. See the “Retrieving Subject Access Request Information from LiveRamp” section of this document for more information.

Sending Requests to LiveRamp

If you’re a LiveRamp client or partner who sends consumer personal information to LiveRamp, the process to follow to deliver requests is very similar to the usual way you would upload files into LiveRamp. This includes clients who use Onboarding and Data Marketplace, as well as Match Network partners and RampID Expansion partners.


For clients using File-Based Recognition, the opt-out methods are different. See the "File-Based Recognition Workflows" section of this article for more information.


For subject access requests: Create a unique alphanumeric request ID for each row of data in the uploaded file so that we can use that ID to identify the data we’re passing back to you. Use "CCID" for the column header of that column. Subject access requests are not passed downstream.


LiveRamp Resellers: If you are a reseller of LiveRamp services, direct your clients who leverage the service and wish to deliver opt-outs or deletions via LiveRamp to prepare files for delivery according to the directions below. See the “Retrieving Opt-Outs and Deletions from LiveRamp” section below if you will need to process these opt-out or deletion requests on behalf of your clients.

Recommended Consumer Data Types to Send

For the most effective propagation of your consumer requests, we highly recommend that you either send consumer request files containing PII (such as name and postal, phone number, email address) or RampIDs.

Procedure. To send your consumer requests to LiveRamp:
  1. Create a case in the LiveRamp LiveRamp Community portal to confirm the types of identifiers you'll be sending (PII, cookies, mobile device IDs, etc.) and to request that the appropriate folders be created on the LiveRamp SFTP.

  2. Create column-based files of your request data by request type (opt-outs, deletions, subject access requests) and within each request type segregate your data into separate files by identifier type (if necessary):

    • PII (such as name and postal, phone number, email address) (recommended)

    • RampIDs (recommended)

    • Plaintext mobile device IDs (IDFAs and AAIDs)

    • SHA-1-hashed IDFAs

    • SHA-1-hashed AAIDs

    • Cookies

  3. For subject access request files, add a column with a unique request ID for each consumer.


    For opt-outs and deletion requests: Only include identifier fields in your request files. Do not include any other fields.

  4. Format your files the same way you would format other column-based files to upload to LiveRamp. See "Formatting File Data" and "File Formatting Examples and Templates" for more information, examples, and downloadable templates for each identifier type.

  5. Once the LiveRamp Technical Support team has provided the folder and subfolder locations, upload your request files to the appropriate folders or subfolders on the LiveRamp SFTP. See "Upload a File via LiveRamp's SFTP" for instructions.


    You can use your existing LiveRamp SFTP credentials. If you don't currently upload files to the LiveRamp SFTP, the Technical Support team will give you SFTP credentials.

In general, LiveRamp takes up to 30 days to process consumer requests from the time we receive them.

File-Based Recognition Workflows

Consumer requests for File-Based Recognition workflows (FBR) are implemented differently than for other LiveRamp workflows:

  • For deletions: Because FBR is a "file in, file out" workflow where we only store input data for 15 days (in the event that there’s an issue with file processing), deletions effectively happen automatically after the 15-day period ends.


    Ingested data is retained in other LiveRamp systems for 30 days.

  • For opt-outs: Because FBR is a "file in, file out" workflow, clients are expected to apply their own opt-outs to their FBR workflow files before uploading to LiveRamp.

  • For subject access requests: Because FBR does not involve long-term data storage, we do not process subject access requests on consumer data uploaded for these workflows.

For FBR workflows where you’re sending personal information to a measurement partner, you and your partner determine whether it is necessary to forward opt-outs or deletions. Follow these steps If you choose to forward these requests:

  1. You and the partner agree upon an expected format for the requests.

  2. You create a case in the LiveRamp LiveRamp Community portal to set up a non-billable measurement audience that will be used to deliver opt-outs and deletion requests.

  3. You use the provided SFTP location to deliver opt-outs or deletions to your partner.

Retrieving Subject Access Request Information from LiveRamp

Within 30 days of receiving a subject access request from you, we do our lookup and generate a JSON file containing the relevant information. To retrieve the JSON files, download the file from the “/SAR_Output” subfolder on your account on the LiveRamp SFTP.

Retrieving Opt-Outs and Deletions from LiveRamp

When a consumer makes an opt-out or deletion request to LiveRamp directly, or to one of our clients or their partners, we make those requests available to LiveRamp partners or clients who might receive that consumer’s information. We expect partners and clients to retrieve and respect these opt-outs or deletion requests.

For these purposes, LiveRamp partners and clients who receive data include:

  • Destination platforms

  • Clients or partners who receive RampID Mapping Files

See below for instructions on how to retrieve opt-outs or deletion requests.

For partners and clients who receive RampID Mapping Files, see the “Additional Information for Customers Who Receive RampID Mapping Files” section of this article.

Retrieve Consumer Request Files

LiveRamp creates batch files of consumer requests ("consent files") that contain lists of identifiers that should either be opted out or deleted. These files can be retrieved via our Consent Files Service API.


Retrieving files via API is the preferred method, as it can be automated. However, if you’re unable to retrieve via API, you can retrieve these files via the Connect UI. See the "Retrieve Files Via Connect" section of this article for more information.

We also provide related metadata for each file, including:

  • The type of identifiers in the file.

  • Whether the file represents opt-outs or deletions.

  • Whether the request came directly to LiveRamp or to a LiveRamp client.

  • If the request came to a LiveRamp client currently delivering data to you (i.e., if a consumer made a request to one of our clients and the client forwarded it to LiveRamp), information that specifies where the opt-out or deletion request came from.


We will specify the LiveRamp client using the same partner-specific IDs used to distinguish between clients in existing LiveRamp deliveries to your platform, such as company name, seat ID, and partner ID.

Retrieve Files Via API

This method consists of the following overall steps:

  1. LiveRamp securely distributes API keys to you via LastPass (accessed via an email link we send to you). For information about setting up LastPass, see "View Credentials Shared Via LastPass".

  2. Using the API keys, you query our Consent Files Service API to get a list of all new opt-out and deletion files delivered by LiveRamp since January 1, 2020, along with metadata for each file. See “Example API Response” below for an example.

  3. Each object in the API response will include a URL for a text file that contains your opt-outs and deletions. You can make an HTTP GET request against each URL using something like cURL or a programming language HTTP client to download your files. See “Example File” below for an example of what the consent file might look like.

  4. You apply the opt-outs as required to the appropriate client or system accounts.

  5. You continue to call the API on a regular basis to get a list of all new files created since your previous API call.

For complete instructions, see our Consent Files Service API documentation.

Example API Response

Below is an example of what the API responses will look like. See the table below for a list of response parameters and their descriptions.






The consent file ID


The type of identifiers that the file contains



When the identifierType is “MUID”, the type of mobile device ID. “MIXED” indicates that the file contains both AAID and IDFA mobile device IDs



When the identifierType is “MUID”, the format of the identifier values



The type of requests that the file contains



The type of identifier used in the "controllerID" parameter



The ID for the ID type specified in the “controllerSpecifier” parameter


Whether the request came to LiveRamp directly. “True” for requests that came to LiveRamp directly and “false” for requests that came to someone other than LiveRamp.

“true”, “false”


The URL location where the file can be retrieved


The date and time that the file was created

Example Consent File

The data in each file consists of a newline-delimited collection of identifiers for your destination. The example below shows 20-digit cookies.


Retrieve Files Via Connect

If you are unable to retrieve files via API, you can retrieve files manually via Connect:

  1. Contact your LiveRamp account team and provide an email address for a designated privacy representative.

  2. LiveRamp checks for new requests on a daily basis and generates consent files when requests are received. If a new file is generated, we send an email to the designated representative.

  3. The representative logs into their LiveRamp Connect Account at and downloads any new files via the UI. See “Example File” above for an example. Note: The metadata for each file will be displayed in the UI.

  4. You apply the opt-outs as required to the appropriate client or system accounts.

Additional Information for Clients Who Receive RampID Mobile Mapping Files

If you receive RampID Mapping Files containing mobile device IDs (IDFAs or AAIDs), accommodating consumer requests will often be accomplished simply by replacing your existing mapping tables with a full refresh file on a regular cadence. This ensures that your mapping tables are in sync with our online graph and that any linkages we have expired on our end are removed.

However, if your use case requires you to retain linkages longer than this approach allows (for example, longer than 30 days), you can use the consumer request files we provide to remove the necessary linkages on your side directly. Follow the process above to retrieve files using your preferred method.

How Opt-Outs and Deletions Work in your Mapping Files Today

LiveRamp collects two types of opt-outs: device-based opt-outs and permanent individual-level opt-outs/deletions. As you’re likely aware, you’re already receiving device-based opt-outs in your mapping files today which "zero out" devices or entire clusters as we receive opt-out signals. Any deletions or permanently opted-out users are removed from our graph in accordance with upcoming regulations and are taken care of via the full refresh files you receive (those linkages are no longer included in the refreshed files).

Procedure. How to Process Consumer Requests Going Forward
  1. Ensure you are replacing your existing mapping tables with a full refresh file on a regular cadence. This ensures that your mapping tables are in sync with our online graph and that any linkages we have expired on our end are removed. In this case, the additional files serve as a historical record/tracking mechanism.

  2. If your use case requires you to retain linkages longer than this approach allows, use the file we'll provide to remove the necessary linkages on your side.