Manage your consent and opt-out privacy obligations under the GDPR and CCPA with Data Privacy Controls. This feature is not prescriptive and there is no single way to implement consent or opt-out. Instead, mParticle gives you a simple, standard technique for storing and applying consent and opt-out choices. Consent state powers both GDPR consent and CCPA data sale opt-out.
\nThis guide introduces you to mParticle’s data privacy control functionality and shows you how to collect an individual’s consent and apply it to your data flows.
\nData privacy controls are flexible and customizable, allowing you to build any data flow or consent-based logic you need.
\nUse mParticle’s data privacy controls to help comply with CCPA’s “do not sell my data” requirement by collecting users who opt-out and blocking those users’ data from flowing to any ‘data sale’ output by:
\nGDPR defines consent as one method of lawful data processing. One common setup is to:
\nOnce enabled and configured, data privacy work with the mParticle platform to ingest and pass on consent state:
\nData privacy controls save user consent decisions and applies them to data flows.
\nOnce a purpose has been added it cannot be removed.\n A purpose defines the scope of data collection and processing to which the user may consent. GDPR recognizes several different purposes for data collection including the possibility of a user consenting to some purposes of data collection but not others. mParticle does not limit you to a specific set of purposes, but rather lets you define your own purposes when you set up a workspace.\n\nFor CCPA, once it is enabled in your workspace, the purpose data_sale_opt_out is automatically created. The SDKs and mParticle UIs facilitate using this purpose, so you don’t need to hardcode it anywhere. \n \n
\n\nThe mParticle format for a single record of a user decision on a privacy prompt, .consent, is our consent_state object. This is used for both GDPR-style opt-in consent and for CCPA-style opt-out.
\nFor each user or workspace, consent state can be stored for each possible combination of regulation and purpose. For each purpose, the following fields are supported.
\nAll fields are optional, except consented, timestamp_unixtime_ms, regulation and purpose. The regulation and purpose fields are built into the structure. Be sure to include your privacy and compliance experts when deciding how to implement optional fields.
\nThe `consented` field indicates the user's decision to the data processing defined in the purpose. It does not imply any additional permissions. \n\n\n\nProperty
Type, Required
Example Values
Description
\n \n\n\nregulation \nstring RequiredgdprThe regulation under which a user consent or preference is being saved. Currently gdpr and ccpa are supported. \n \n\npurpose \nstring RequiredgeolocationA data processing purpose that describes the type of processing done on the data subject’s data. For GDPR, purposes must be defined in mParticle before using them in a consent_state object. For CCPA, this is not required as the default CCPA purpose is data_sale_opt_out \n \n\nconsented \nbool Requiredtrue / falseFor GDPR, this records the user’s decision on the prompted consent purpose. If the user agreed (true) or rejected (false). For CCPA, set this to true if the user has opted-out of data sale and false if they have not opted-out of data sale. \n \n\ntimestamp_unixtime_ms \nnumber Required1510949166A timestamp for the creation of the consent state. mParticle’s SDKs send this field automatically. If using the HTTP API, this field must be set manually. Incoming consent is applied only if this value is newer than the timestamp already stored on the profile for that regulation and purpose; older or equal timestamps leave the existing consent in place. Warehouse Sync follows the same rule. See Consent timestamp precedence . \n \n\ndocument \nstring Not required"v23.2b"An identifier for the document, document version or experience that the user may have consented to. \n \n\nlocation \nstring Not required"example.com/", "17 Cherry Tree Lane"A location where the user gave consent. This property exists only to provide additional context. It may be a physical or digital location. \n \n\nhardware_id \nstring Required"IDFA:a5d934n0-232f-4afc-2e9a-3832d95zc702"A hardware ID for the device or browser used to give consent. This property exists only to provide additional context and is not used to identify users. \n \n \n
\n\nConsent state can be logged via the HTTP API simply by including a consent state object in a batch, mirroring the structure of the user profile (above):
\n\"consent_state\" : { \n \"gdpr\" : { \n \"location_collection\" : { \n \"document\" : \"location_collection_agreement.v43\" , \n \"consented\" : true , \n \"timestamp_unixtime_ms\" : 1523039002083 , \n \"location\" : \"dtmgbank.com/signup\" , \n \"hardware_id\" : \"IDFA:a5d934n0-232f-4afc-2e9a-3832d95zc702\" \n } , \n \"parental\" : { \n \"document\" : \"standard_parental_consent.v2\" , \n \"consented\" : true , \n \"timestamp_unixtime_ms\" : 1523039002083 , \n \"location\" : \"dtmgbank.com/signup\" , \n \"hardware_id\" : \"IDFA:a5d934n0-232f-4afc-2e9a-3832d95zc702\" \n } \n } , \n \"ccpa\" : { \n \"data_sale_opt_out\" : { \n \"consented\" : true , \n \"timestamp_unixtime_ms\" : 1579198790480 \n } \n } \n} For detailed definitions of how to report consent state, review the sections of our API and SDK references that cover data privacy controls:
\n\nAdditionally, our integration with OneTrust allows you to ingest customer consent states into mParticle.
\n\n\nConsent state is maintained per person on the User Profile using the structure defined above.
\nFor testing consent, you can use User Activity View to check that a consent was recorded correctly. Here is an example of how CCPA data sale opt-out will appear:
\n
\n\nConsent filters control which user profiles mParticle forwards to audience output configurations based on each profile’s recorded GDPR and CCPA consent state. You can reuse a consent filter across multiple audience output configurations, apply a filter to specific configurations, or set a workspace default.
\nLearn more about Consent Filters .
\n\nConsent state can be used to create forwarding rules that selectively filter data based on a users consent state, in real time and per-person.
\nFor example, you can choose to only forward data from users who have given consent for a particular purpose.\n
\nFor CCPA, you may want a forwarding rule to apply a data sale opt-out. In this example, users’ who have a consent state of true for the CCPA purpose of data_sale_opt_out will NOT have their data forwarded (if the consent state is missing or false for that purpose, data will flow):\n
\nFor GDPR, you may want a forwarding rule to only send data when a single purpose is consented:\n
\n\nIf you set up a Forwarding Rule for an embedded kit integration, the iOS and Android SDKs will check consent status for the user on initialization. If the rule condition fails, the kit will not be initialized. Note that kits are only initialized when a session begins or on user change, so if consent status changes in the course of a session, while mParticle will immediately stop forwarding data to the kit, it is possible that an embedded kit may remain active and independently forwarding data to a partner from the client until the session ends.
\n\nWhen the consent state of a profile changes, that change can be communicated to mParticle event integrations. If the consent_state object on an incoming event batch contains changes from the existing profile, mParticle adds a ‘system notification’ to the batch for each consent state change before the batch is sent to incoming forwarders. This notification contains the full old and new consent state objects:
\n\"system_notifications\" : [ \n { \n \"data\" : { \n \"purpose\" : \"location_collection\" , \n \"current\" : { \n \"regulation\" : \"GDPR\" , \n \"document\" : \"location_collection_agreement_v4\" , \n \"consented\" : false , \n \"timestamp_unixtime_ms\" : 1523045332033 , \n \"location\" : \"17 Cherry Tree Lane\" , \n \"hardware_id\" : \"IDFA:a5d934n0-232f-4afc-2e9a-3832d95zc702\" \n } , \n \"old\" : { \n \"regulation\" : \"GDPR\" , \n \"document\" : \"location_collection_agreement_v4\" , \n \"consented\" : true , \n \"timestamp_unixtime_ms\" : 1523039002083 , \n \"location\" : \"17 Cherry Tree Lane\" , \n \"hardware_id\" : \"IDFA:a5d934n0-232f-4afc-2e9a-3832d95zc702\" \n } \n } , \n \"type\" : \"gdpr_change\" \n } \n] There are currently two ways that consent state changes are forwarded to mParticle event integrations:
\n\n\nSome partners accept raw event batch data from mParticle, mostly for data storage or custom analytics use cases. For these partners, mParticle will forward the ‘system_notifications’ object with each relevant event batch. Forwarding of system notifications can be turned off with a user setting. Integrations that can currently receive the system notifications object include:
\n\n \n\nmParticle is working with other partners to support forwarding consent state changes as a Custom Event. These events contain the new consent state information as custom attributes, a custom event type of "Consent", and an event name of "Consent Given" or "Consent Rejected". These consent events are forwarded to supporting partners as standard custom events.
\n{ \n \"data\" : { \n \"event_name\" : \"Consent Given\" , \n \"custom_event_type\" : \"Consent\" , \n \"custom_attributes\" : { \n \"consented\" : \"true\" , \n \"document\" : \"location_collection_agreement_v4\" , \n \"hardware_id\" : \"IDFA:a5d934n0-232f-4afc-2e9a-3832d95zc702\" , \n \"purpose\" : \"location_collection\" , \n \"location\" : \"17 Cherry Tree Lane\" , \n \"regulation\" : \"GDPR\" , \n \"timestamp_unixtime_ms\" : 1523039002083 \n } , \n \"event_type\" : \"custom_event\" \n } \n} Partners that currently accept these custom consent state events include:
\n\n \n \n “GDPR Consent Change” is listed as a data type in the Integrations directory and we will update this list as more partners add support. Please reach out to your success manager if you would like to distribute consent to an additional partner.
\n\nmParticle helps you respond to data subject requests as mandated by the GDPR and CCPA regulations.
\nYou can search for integrations that support data subject requests in the Integrations page. Search on category Data Subject Request .
\n\nThe California Consumer Protection Act (CCPA) and the upcoming CPRA (California Privacy Rights Act) require that users can signal their privacy choices. In support of that requirement, you can ingest Global Privacy Control (GPC) signals with mParticle.
\nBrowsers append the GPC signal to HTTP requests and make it queryable via the DOM. This signal is designed to convey a person’s request to websites and services to not sell or share their personal information with third parties, per the Global Privacy Control specification . This opt-out is at the browser level, allowing users to turn on the GPC signal for all or specific websites.
\nThe workflow for ingesting and forwarding GPC signals via SDK or Events API:
\n
\n\nThis sample code show two options: mapping to a GDPR purpose and mapping to a user attribute.
\n/*\n First, grab the GPC signal. \"true\" indicates the user has signaled an opt-out\n See here for more details on querying the GPC signal:\n https://globalprivacycontrol.github.io/gpc-spec/\n*/ \nvar gpcSignal = navigator. globalPrivacyControl; \n\n\n/*\n Option 1:\n In this example, the GPC signal is mapped to a \"targeting_collection\" GDPR purpose.\n This is only an example, you determine the GDPR purposes and how GPC maps to them.\n You can do the same mapping to CPPA.\n*/ \nvar targeting_consent = mParticle. Consent. createGDPRConsent ( \n ! gpcSignal, // note that this is inverted \n Date. now ( ) , // Timestamp \n \"browser_gpc_signal\" , // Document \n \"17 Cherry Tree Lane\" , // Location \n \"browser-id:a5d934n0-232f-4afc-2e9a-3832d95zc702\" // Hardware ID \n) ; \n\n\n// Add to your consent state \nvar consentState = mParticle. Consent. createConsentState ( ) ; \nconsentState. addGDPRConsentState ( \"targeting_collection\" , targeting_consent) ; \nvar user = mParticle. Identity. getCurrentUser ( ) ; \nuser. setConsentState ( consentState) ; \n\n\n/*\n Option 2:\n In this example, the GPC signal is mapped to a user attribute\n*/ \nvar user = mParticle. Identity. getCurrentUser ( ) ; \nuser. setUserAttribute ( \"gpc_signal\" , gpcSignal) ; ![\"Workflow](\"/images/guides/data-privacy-controls/data-privacy-workflow.png\")
![\"CCPA](\"/images/guides/data-privacy-controls/enabling-compliance-features.png\")