GDPR Subject Requests

The General Data Protection Regulation (GDPR) defines a set of rights of Data Subjects within the Europen Union. mParticle offers a set of tools to help you manage your obligations under the GDPR. Our GDPR tools fall under two categories: Consent Management, and Data Subject Requests. This document deals with Data Subject Requests.

GDPR Roles

The GDPR defines three entities invovled in data collection, with different rights and responsibilities:

  • Data Subject - A person whose data is gathered. Generally a user of your app.
  • Data Controller - An entity gathering the data. mParticle provides tools for Data Controllers to fulfill their obligations under the GDPR.
  • Data Processor - An entity that handles or stores data for the Data Controller. Under the GDPR, mParticle acts as a Data Processor.

Rights of Data Subjects

The GDPR defines some rights of Data Subjects, including:

  • The right to have data concerning them erased. Also known as the ‘right to be forgotten’.
  • The right to access data concerning them.
  • The right to portability of data concenrning them, for transfer to another controller.

OpenGDPR Request Framework

mParticle is a collaborator on the OpenGDPR framework, which provides a simple format for Data Controllers to work with Data Processors to comply with requests from their Data Subjects to honor the above rights.

To find out more about OpenGDPR, read the full spec on the Github page.

mParticle’s OpenGDPR implemenation handles three requests: “Erasure”, “Access” and “Portability”.

General Request Workflow

Details specific to each request type are included below. However, each Data Subject request follows the same basic workflow:

  1. The Data Subject submits a request to the Data Controller.
  2. The Data Controller must log, authenticate and verify the request. If they choose to accept the request, the Data Controller forwards a request to mParticle in it’s role as a Data Processer. The request provides:

    • One or more identities for the Data Subject;
    • The type of request: “Erasure”, “Access” or “Portability”;
    • The time the Data Subject submitted the request;
    • An optional list of Status Callback URLs.
  3. On receipt of the request, mParticle sets the status of the request to “Pending” and sends a status callback request to all URLs listed in the original request. This callback includes an expected completion time for the request, which is calculated as: the time it will be scheduled for processing (details below) plus 48 hours (to ensure the job completes in time).
  4. The Data Controller can check the status of the request at any time.
  5. When the request is complete, mParticle sends a status callback request to all URLs listed in the original request. For Erasure requests, this callback will simply confirm that the request has been fulfilled. For Access and Portability requests, a download link will be provided.
  6. For Access and Portability requests, the download link remains valid for 7 days. Attempting to access the download link after that time will result in a 410 Gone HTTP response.

This workflow can be managed programatically via the OpenGDPR API. Manual management in the mParticle Dashboard will be released shortly.

Identifying affected user data

mParticle stores data against user profiles, each identified by an mParticle ID (MPID). To respond to an OpenGDPR request as a Data Processor, mParticle first needs to match identities in the request against user profiles. This is handled differently from mParticle’s regular IDSync process.

The goal of IDSync is always to return a single profile that is the best place to store current data for a user. A single human will often have multiple user profiles over time. When mParticle receives a list of identities as part of an OpenGDPR request, we do not attempt to resolve them to a single MPID, but instead return all MPIDs that match at least one of the identities in the request.

Develop a strategy for accepting Data Subject Requests

As a Data Processor, mParticle will match user profiles for a Data Subject Request based on any identities we are given. As a Data Controller, it is your responsibility to determine how to accept and forward Data Subject Requests in order to best meet your GDPR responsibilities and manage risk. This decision should be managed in conjunction with your Identity Strategy.

You also have the option of using the Identity API to identify for yourself the MPIDs you wish to include in the request and submitting them directly, rather than letting mParticle match IDs for you.

Be sure to consult your internal privacy and compliance experts when determining your strategy for accepting and forwarding Data Subject Requests.

Supported Request Types


Erasure requests are handled as follows:

  1. mParticle identifies the MPIDs that match the request and creates an erasure job containing the MPIDs for erasure.
  2. Each Monday at 12:30UTC, all jobs created in the previous 7 days are added to a batch. After the batch is created, jobs can be removed from the batch, but no additional jobs can be added.
  3. 7 days after a batch is created, all jobs are run, deleting all data in mParticle associated with each MPID in each job.
  4. For each request, mParticle sends a callback to any specified Callback URLs, indicating that the request has been completed.

Note that there will be at least 7 and up to 14 days between mParticle recieving a request and deletion occurring. This delay provides an opportunity to cancel a pending deletion request before it is carried out.

What data is deleted?

In addition to data directly stored by mParticle, such as historical event batches, mParticle will also delete data in your managed Data Warehouse integrations:

  • Amazon Redshift
  • Google BigQuery
  • Snowflake

These methods access data indexed for GDPR starting on May 25, 2018. If you need to affect historical data, please contact your account manager.

We cannot delete data that has already been forwarded to a partner, via an Event integration.

A delete request will also not prevent additional data concerning the subject from being received and processed by mParticle. If the data subject wishes to prevent all future data processing, they will likely need to take additional steps, for example, ceasing to use the service or app.

Access / Portability

Access and Portability requests are handled as follows:

  1. mParticle Identifies the MPIDs that match the request.
  2. Just after midnight each Monday and Thursday, mParticle searches for data related to each MPID, including the user profile and historical event batches. Inferred data, such as audience memberships, is not included.
  3. mParticle compiles the data into a single text file.
  4. mParticle sends a callback to any specified Callback URLs indicating that the request has been completed. The callback will contain a secure download link to the text file containing the Subject’s data.

Portability Response Format

The data gathered in response to a Portability Request will be delivered in the form of a .zip folder containing one or more .jsonl files in the JSON Lines format. We may split the results into many files to avoid a single large file and to make them easier to transmit and process. Controllers are encouraged to recombine the files at their discretion.

Each line of the file represents a complete mParticle event batch. See our JSON Reference for a guide to the event batch format.

Note that if no records can be found matching the identities in the request, the request for the zip file will intentionally return a 404 error.

A sample portability response can be downloaded here.

Managing Data Subject Requests in the mParticle Dashboard

In addition to the OpenGDPR API, users with the Compliance role can create, delete and monitor GDPR Data Subject Requests directly in the mParticle Dashboard.

Was this page helpful?