Skip to main content

Processing Data Subject Rights Requests

Abstract

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.

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.

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

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 Measurement Enablement. For information on how we process requests for that workflow, the "Consumer Requests for Measurement Enablement 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 Activation 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 Measurement Enablement 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.

Caution

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 Activation 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 Activation 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 Activation and Data Marketplace, as well as Match Network partners and RampID Expansion partners.

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.

Note

  • For clients using Measurement Enablement, the opt-out methods are different. See the "Consumer Requests for Measurement Enablement 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.

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

    Note

    • For file examples and downloadable templates for each identifier type, see "File Formatting Examples and Templates".

    • After you have sent an initial request file, only include new requests in subsequent files. Do not send a consumer requests file that contains requests that you have sent previously.

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

    Caution

    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" for more information.

  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.

    Note

    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.

If you want to check the status of your uploaded request files, create a support case.

Consumer Requests for Measurement Enablement Workflows

Consumer requests for Measurement Enablement workflows are implemented differently than for other LiveRamp workflows:

  • For deletions: Because Measurement Enablement 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.

    Note

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

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

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

For Measurement Enablement 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.

Note

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

  • The Consent Files Service API cannot be used to send deletion requests. For information on sending these requests, see the "Sending Requests to LiveRamp" section above.

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.

Note

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:

Note

The Consent Files Service API cannot be used to send deletion requests. For information on sending these requests, see the "Sending Requests to LiveRamp" section above.

  1. LiveRamp securely distributes API keys to you.

  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.

Consent_Files_API_Response-dTw.jpg

Parameter

Description

Example

id

The consent file ID

identifierType

The type of identifiers that the file contains

“MUID”, “CUSTOM_ID”, “COOKIE”

muidDeviceType

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

“AAID”, “IDFA”, “MIXED”

muidFormat

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

“RAW”, “HASHED”

requestType

The type of requests that the file contains

“OPT_OUT”, “DELETE”

controllerSpecifier

The type of identifier used in the "controllerID" parameter

“SEATID”, “PARTNER_ID”, “ADVERTISER_NAME”, etc.

controllerID

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

liveRampControlled

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”

fileURL

The URL location where the file can be retrieved

createdAt

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.

Consent_Files_cookie_file_example-HEE.jpg

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 https://connect.liveramp.com/privacy/consent-file 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.