Privacy Rights

A privacy rights workflow can help your organization stay in compliance with data protection and privacy regulations, such as those required by California Consumer Privacy Act (CCPA) or General Data Protection Regulation (GDPR).

  • The California Consumer Privacy Act (CCPA) is law that covers data protection and privacy in the state of California. It gives control to individuals over their personal data and addresses the transfer of personal data, including providing for the ability to request removal of data.

  • The General Data Protection Regulation (GDPR) is law that covers data protection and privacy in the European Union (EU) and the European Economic Area (EEA). It gives control to individuals over their personal data and addresses the transfer of personal data outside the EU and EEA areas. GDPR simplifies the regulatory environment for international business by unifying regulation within the EU.

This topic describes how to configure Amperity to support a self-service privacy rights workflow that deletes consumer profile data based on inbound delete requests and requested compliance actions.

Note

General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) compliance is the obligation of each customer, including interpreting and determining how to comply with each request made by a user. As such, each customer must define the process by which inbound requests for General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) compliance are made available to Amperity. Each customer is encouraged to seek legal counsel regarding California Consumer Privacy Act (CCPA) compliance and should not rely solely on General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) workflows within Amperity to ensure that compliance.

Important

This topic does not constitute legal advice to third parties regarding General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) compliance, nor does it imply that steps taken by Amperity will satisfy these compliance requirements. Customers are encouraged to seek legal counsel regarding General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) compliance and should not rely solely on Amperity for compliance.

Request types

You can configure Amperity to support the following compliance actions:

  1. Delete

  2. Respond to a data subject access request (DSAR)

    A data subject access request (DSAR) is a written request made by an individual to ask for their data to be handled according to General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA)regulations. A Data Subject Access Request (DSAR) requires a response within a pre-defined time window, typically 30 days.

Note

Amperity deletes data when requested, but does not maintain a list of prior delete actions. Amperity is unaware when previously deleted customer records re-enter the system.

You should take steps to ensure that your downstream (and upstream) processes have completed their own delete actions before allowing those sources to provide updated data to Amperity.

You may wish to use Amperity to identify which records belong to a consumer. If the strategy field is set to connected_pi, records appear that are connected through the Amperity ID using probabilistic Stitch. The detailed report contains those records. Send these results to your downstream workflows to locate data that should be deleted from other systems.

Enable privacy rights workflows

The following steps describe how to enable a privacy rights workflow on your tenant:

  1. Inbound requests

  2. Configure non-stitched tables

  3. Run database

  4. Add compliance reports tables

  5. Ad hoc or automated workflow?

Configure inbound requests

Inbound requests for compliance actions are provided to Amperity as a file that defines a list of unique email addresses. For each email address, a delete action and a compliance strategy are specified.

Supported file formats

You may use the following file formats to provide to Amperity a list of customers against which the privacy rights workflow will be applied:

  • CSV

  • JSON

  • TSV

The following example shows an inbound request in the form of a CSV file:

customer id,type,strategy,email
1,delete,email,justinc@amperity.com
2,delete_pii,connected_pii,pauljackson@amperity.com
3,dsar,email,johnsmith1984@amperity.com

Required fields

Each inbound request file must have a field that defines:

  1. The unique ID for the inbound request.

    Tip

    Ensure that the compliance/request-id semantic tag is applied to the the field that contains the unique ID for the corresponding inbound request.

  2. The type of delete action. Possible values: delete, delete_pii, or dsar. Default value: dsar.

    Note

    Customers can use the delete_pii action when they need to keep certain data on a row. For example, if they need to keep non-identifiable sales data.

    Use the delete action type to delete data from all tables in which customer profile data was discovered.

    Use the delete_pii action type to delete data from all tables in which customer profile data was discovered.

    Important

    If the customer intends to do column-based deletion using the delete_pii action type, then they will need to apply the compliance/pii semantic tag to all fields in all tables that contain PII.

    This semantic tag is required to support the delete_pii action type and is not used by the delete or dsar action types.

    Use the dsar action type to identify inbound requests that are associated with a data subject access request (DSAR). A DSAR typically requires a response to be sent by a downstream workflow. This action generates reports, but does not delete data from Amperity tables.

  3. The strategy for this delete action. Possible values: email or connected_pii.

    Use the email strategy to search against all rows in all tables where the email customer profile semantic tag is applied. The returned rows contain the matching email addresses; however they are case insensitive.

    Important

    The email customer profile (PII) semantic tag is primarily applied to tables that are input to Stitch, so that it can be used as during ID resolution.

    However, email addresses may be found in tables that are not made available to Stitch. If the email customer profile (PII) semantic tag is added to these sources, such as for sources that contain orders or items, this will ensure those tables can be searched for compliance.

    Use the connected_pii strategy to find all rows in all tables in which an email address matches exactly and also to all rows that share an Amperity ID with that email address.

  4. The email address used to identify all of the customer records across all tables.

Semantic tags

There are two groups of semantic tags that may be applied to customer records to enable the privacy rights workflow within Amperity:

  1. Inbound requests

  2. Email addresses across all tables

Inbound requests

The inbound request file must have the following semantic tags:

Semantic tag

Data type

Apply to inbound request field

compliance/request-id

String

Apply this semantic tag to the field that contains the unique ID for the inbound request.

compliance/request-type

String

Apply this semantic tag to the field that defines the type of delete action.

compliance/request-strategy

String

Apply this semantic tag to the field that defines the delete strategy.

compliance/request-email

String

Apply this semantic tag to the field that contains the email address.

Email addresses

The email address that will be used to discover matching customer profiles.

Note

This email address is case insensitive: “bob@example.com” will match “Bob@example.com”, but will not match “bob+1@example.com” or “bob_@example.com”.

Tip

You can search against hashed email addresses as long as the hashing algorithm is not case-sensitive and as long as hashed email addresses are not stored in a case-sensitive manner.

Configure non-stitched tables

Apply the email semantic tag to all columns in all tables in which customer email address values are located, even if a table is not made available to Stitch. This will ensure that all records in all tables are available to privacy rights delete PII or DSAR actions.

Important

A table will not be available to privacy rights delete PII or DSAR actions if one of the following events occurs:

  • The email semantic tag is not applied to the column in which email address values are located.

  • The table is input to Stitch with the connected_pii strategy enabled.

  • A linkage table has rows connected to a table that fits the scenarios listed above.

Run database

After compliance semantic tags have been applied to files associated with inbound requests and any necessary updates to customer profile semantic tags have been made, run your customer 360 database. This will generate a standard table named Unified_Compliance.

Unified_Compliance table

The Unified_Compliance table identifies all records across all tables that are configured for the privacy rights workflow that matched an email address in the inbound request file.

Important

The Unified_Compliance table may contain customer records that are not made available to Stitch.

The Unified_Coalesced table only contains records that are made available to Stitch.

When the privacy rights workflow identifies records to include in the Unified_Compliance table, those records are excluded from the Unified_Coalesced table and will not be available to any downstream process that depends on the Unified_Coalesced table.

The use of the Unified Compliance table to suppress data only works for delete requests. Once this suppression occurs, it will prevent consumers from being involved in any further marketing activity.

Add reports tables

After the delete processes is enabled, add the following tables to your customer 360 database:

  1. Compliance_Overview_Reports

  2. Compliance_Detailed_Reports

Note

You will need to work with Amperity to enable the delete process.

Tip

If your privacy rights workflow has downstream dependencies, such as providing a DSAR response within a 30-day window, you can build queries against the report tables that return data to be sent to these downstream workflows.

Overview reports table

The Compliance_Overview_Reports table contains a row for each inbound request that matched customer records, and then confirms the actions that were performed against those records.

Add this table as a passthrough and use the “Compliance_Overview_Reports” template.

Detailed reports table

The Compliance_Detailed_Reports table contains a row for each record that was matched to an inbound request. Use this table to build queries that send data to downstream workflows, such as those that provide DSAR responses.

Add this table as a passthrough and use the “Compliance_Detailed_Reports” template.

Important

Customer profile data is stored in the Compliance_Detailed_Reports and Compliance_Overview_Reports tables until the next time the delete process is run. If your delete process follows the recommended frequency, the data in these tables is deleted on a weekly basis.

Ad hoc or automated?

The privacy rights workflow can be run against files that are uploaded to Amperity ad hoc or by an automated process. Use the approach that fits best with your upstream workflow and the volume of individual delete actions that your organization expects to manage.

  1. To upload files ad hoc, use the Load new data option for the feed, Truncate the table or multiple tables, and then upload the new file that contains the updated list of compliance actions.

  2. To use an automated workflow, configure a courier and courier group to define the location from which the file can be pulled, and then define the frequency to occur at least one day before the delete action is performed by Amperity.

Apply to custom domain tables

A tenant may require the deletion of a record from a custom domain table. If there is no other configuration, the system can not delete items from the input tables that are used to create the custom domain table. Without any input table deletion, the custom domain table regenerates with the problematic records.

A custom domain table is a domain table that defines its schema using Spark SQL.

Semantic tags

To delete these records, a customer can create a linking custom domain table that tells Amperity to delete both the custom domain table row data and the records associated with that row. Each custom domain table row can have 0 to many data rows.

You can create multiple linking tables, but will need to add the following semantic tags to each table:

Semantic tag

Data type

Apply to field

cdt-pk

String

This is the record primary key which Amperity found.

cdt-ds

String

This is the record datasource which Amperity found.

source-pk

String

This is the record primary key that Amperity couldn’t find, but is expected to be found.

source-ds

String

This is the record datasource that Amperity couldn’t find, but is expected to be found.