![](\"/images/privacy-settings.png\")
Both the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) define that consumers/data subjects have the right to view, update, extract and delete data that controllers & businesses have saved on them. When a consumer/data subject exercises their rights, they create a data subject request (DSR). This page will guide you through mParticle’s support for handling DSRs for both GDPR and CCPA.
\nThis page does not provide legal advice, only a description of how to use mParticle’s compliance-related features. The information provided here is solely for understanding and using mParticle features and is not intended to be legally compliant or specific enough for compliance.
\nThis document uses GDPR language and terminology for simplicity.
\nmParticle provides data privacy controls to help you comply with consent and data sale opt-out requirements.
\nThe GDPR defines three entities involved in data collection, with different rights and responsibilities:
\nSimilarly, the CCPA defines:
\nThe GDPR defines some rights of Data Subjects, including:
\nThe CCPA defines that consumers have rights of:
\nmParticle is a collaborator on the OpenDSR framework, which provides a simple format for Data Controllers and Data Processors to collaborate towards compliance with requests from their Data Subjects to honor the above rights. This framework was formerly known as OpenGDPR; it was renamed in early 2020 to include CCPA support.
\nTo find out more about OpenDSR, read the full spec on the Github page.
\nmParticle’s OpenDSR implementation handles three types of DSRs: “Erasure”, “Access” and “Portability”.
\n\nEach DSR follows the same basic workflow:
\nThe 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 its role as a data processor. The request provides:
\n410 Gone HTTP response.This workflow can be managed in mParticle UI or programmatically via the OpenDSR API.
\nmParticle stores data against user profiles, each identified by an mParticle ID (MPID). To respond to DSRs, mParticle first matches identities in the DSR against observed user profiles. This is handled the same way as mParticle’s regular IDSync process: provided identities are resolved to MPIDs to identify affected user data.
\nData subject requests submitted without a login ID will not be fulfilled for known profiles that have an associated login ID. For example, if you submit a data subject request that only includes the device ID for a user, mParticle will not be able to find the correct profile to fulfill the request.
\nWhen finding the correct profile for a DSR, mParticle follows the same identity resolution process used for general identification requests made to IDSync (the mParticle identity management system).
\nThe exact profiles returned for a data subject request depend on the specific user identifiers supplied with the DSR and the identity strategy configured for your account.
\nAll DSR requests are scoped to a single workspace by API authentication. If you need to apply a DSR to multiple workspaces, please submit it within each workspace.
\nTo get started, enable GDPR and/or CCPA compliance features on your workspace from Workspace Settings > Workspace > Regulation. This will allow you to see the DSR UI. mParticle will honor all requests received via API even with these features disabled.
\nYou have the option to include a copy of the live user profile in access/portability requests. Navigate to Privacy > Privacy Settings to include a copy of the users profile with GDPR and/or CCPA DSRs. This is for clients whose privacy teams determine that this is required for compliance. The profiles will include: devices, identities, audience memberships, user attributes and calculated attributes. By default, profiles are not included.
\n\n
The following video explains how to use consent to control data forwarding with mParticle:
\n\nAs 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.
\nYou 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.
\nBe sure to consult your internal privacy and compliance experts when determining your strategy for accepting and forwarding Data Subject Requests.
\nAfter mParticle receives an erasure request, a 7 day waiting period starts. This waiting period gives you the opportunity to cancel a pending erasure request before it is initiated.
\nAfter the 7 day waiting period, any pending erasures are initiated. Once begun, it may take up to 14 days before the erasure is complete. For each completed erasure request, mParticle sends a callback to any specified URLs indicating that the request has been fulfilled.
\nBy default, erasure requests are completed between 7 and 21 days after being received by mParticle. The initial 7 day waiting period provides an opportunity to cancel a pending erasure request before it is carried out.
\nTo skip the initial 7 day waiting period when submitting a data subject erasure request to mParticle, check the option labeled Skip waiting period in the New Data Subject Request modal.
\nSkipping the waiting period shortens the request cancellation window. This reduces the total time required to complete an erasure request to between 1 and 14 days after it is received by mParticle.
\nIf you wish to remove users from audiences or from event forwarding during the waiting period, set a user attribute and apply audience criteria and/or forwarding rules to exclude them.
\n\nIn response to a data subject erasure request, mParticle deletes the data it stored, such as historical event batches, audience data, and profiles.
\nA 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 your service/app.
\nAccess and Portability requests are treated exactly the same way, as follows:
\nIf you submit an access and portability request for more than one profile using multiple MPIDs, the data for every profile returned will be included in a single file. Since the resolution process for DSRs is the same as the process for IDSync, an access and portability request that includes only a device ID will not return any profiles that are protected by a login ID.
\nFor example, imagine that a user opens your app and is tracked with an anonymous profile, but they do not create an account with a login ID. Later, a different user on the same device opens your app and logs in with a login ID. If you submit an access and portability request but only supply the device ID, then only the data for the anonymous user will be returned.
\n\nThe data gathered in response to an access or portability request will be delivered in a .zip folder containing many .jsonl files (JSON Lines format). The zip may contain:
profile.jsonl: A file that contains the live profile at the time of the request. This includes: device identities, user identities, current audience memberships and user attributes (including calculated attributes)..jsonl files: These results are split into many files to avoid a single, large file to make them easier to transmit and process. Controllers are encouraged to re-process the files as they see fit. These files contain the event batches sent to mParticle. Each line of the data files represents a complete mParticle event batch. See our JSON Reference for a guide to the event batch format.empty.txt: A file which indicates that mParticle found one or more MPIDs associated with the identities in the request, but that there is no data available for them.Note that if no records can be found matching the identities in the request, the request for the zip file returns a 404 error.
A sample portability response can be downloaded here.
\nIn addition to the OpenDSR API, users with the Compliance or Admin and Compliance role can create, delete and monitor DSRs directly in the mParticle Dashboard.
\n\n![\"image](\"/images/dsr/dsr-ui.png\")
To view details about a request, click the Request ID number.
\nYou can configure mParticle to forward Data Subject Requests (DSRs) for erasure with one or more integrations.
\n![\"image](\"/images/dsr/dsr-details.png\")
This detail UI for a data subject request for erasure shows the forwarding status for a request that is being forwarded to three different outputs.
\nThe forwarding status field contains different values, depending on the situation:
\nPending means that a request has been queued for forwarding, but hasn’t been forwarded yet.Skipped means that a request for forwarding has been skipped because mParticle could not find suitable identities to forward, either from the original request or the user profile.Sent means that a request was forwarded and an acknowledgement of the request to delete the user from the integration was received by mParticle.Failed means that an attempt to forward the request was made, but an error occurred.Not Sent means that the request was not forwarded, because the request was made using an older version of the DSR API. You must upgrade to the DSR API v3 in order to forward DSR erasure requests.In addition to the forwarding status, the identities that were forwarded are also shown. mParticle determines which identities to forward based on the identities supplied in the original request, the identity resolution strategy, and what identities each output supports:
\nWhen multiple generic identities of different types (such as email address and device ID) are submitted in the erasure request and:
\nWhen a single MPID is submitted in the erasure request and:
\nIn the case where the data in a user profile does not match what was provided in the original erasure request, mParticle will use the information from the original erasure request as the source of truth to process and forward the request.
\nOnce a request is forwarded, mParticle can’t guarantee that data is ultimately deleted by the integration partner, so confirm that each vendor fulfills the request.
\nIf an integration supports forwarding erasure requests, the integration documentation contains a section “Data Subject Request Forwarding for Erasure” and that section contains specific instructions and information about which identities are forwarded.
\nTo find all the integrations that support forwarding erasure requests, visit Integrations.
\nmParticle retains Data Subject Request records for up to 1 year.
","frontmatter":{"title":"Data Subject Requests","order":1,"seoTitle":null,"seoDescription":null},"parent":{"__typename":"File","modifiedTime":"October 12, 2026"}}},"pageContext":{"slug":"/guides/oversight/privacy/data-subject-requests/"}},"staticQueryHashes":["2950460867"]}