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

• The Australian Privacy Principles (APP) is a law that covers data protection and privacy in Australia. It governs a broad set of standards, including rights and obligations around the collection, use and disclosure of personal information, the integrity and correction of personal information, and the rights of individuals to access their personal information.

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.

About privacy rights workflows

The following sections describe the three types of privacy rights workflows:

• DSAR

• Delete records

• Delete PII

The sections are repetitive when the workflows have shared behavior and are different when they have unique behavior. For example: the first step for all privacy rights workflows is to find all records with exact matches to the inbound request; however, the Delete PII privacy rights workflow is the only one that requires using the compliance/pii semantic tag.

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 regulations, such as General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA). A DSAR requires a response within a pre-defined time window, typically 30 days.

The following diagram shows the workflow that occurs when a DSAR request is present in the inbound requests table.

The following sections describe the individual steps within the workflow that occurs when a DSAR request is present in the inbound requests table.

Find records A DSAR request runs when type field in the inbound requests table is set to dsar. The strategy for an inbound request is set to exact by default. An exact matching strategy will find all records in all source tables that match the email address, phone number, or address group that is included in the inbound request. About the connected_pii strategy Using the the exact strategy for DSAR requests is recommended. The strategy may be set to connected_pii. A connected PII matching strategy will find all records in source tables that match the email address, phone number, or address group that is included in the inbound request and will find all matching records in Stitch output (core tables, stitched tables, and the Unified Coalesced table). A Stitch cluster often contains variations of email addresses, phone numbers, and address groups that are all associated with a single unique individual, but only one email address, phone number, or address group will match exactly to the values in the inbound request. To avoid potentially exposing additional customer PII in the DSAR report (and possible DSAR response) it is recommended to use the exact strategy as often as possible. Note Source keys or linkage tables can be used to trace records in a custom domain table back to a source table. When either of these are implemented, a direct or connected match on a custom domain table will find all corresponding records in source domain tables.

Refresh reports When the DSAR request workflow is finished the Unified Compliance and Unified Compliance Overview tables are updated. When a record is matched in Unified Coalesced For the current Stitch run, associated records are visible in: Unified Coalesced Other database tables Domain tables For all future Stitch runs, associated records are visible in: Unified Coalesced Other database tables Domain tables

Delete records

An inbound request may require deleting customer records.

The following diagram shows the workflow that occurs when a delete records request is present in the inbound requests table.

The following sections describe the individual steps within the workflow that occurs when a delete records request is present in the inbound requests table.

	Find records A delete records request runs when type field in the inbound requests table is set to delete. The strategy for an inbound request is set to exact by default. An exact matching strategy will find all records in all source tables that match the email address, phone number, or address group that is included in the inbound request. The request match category resulting from a match on PII will be direct and can be viewed from the Unified_Compliance table. The strategy may be set to connected_pii. A connected PII matching strategy will find all records in source tables that match the email address, phone number, or address group that is included in the inbound request and will find all records with the same Amperity ID as those direct matches. The request match category resulting from a match on Amperity ID will be connected and can be viewed from the Unified_Compliance table. Note The request match category resulting from a match due to source keys will be source_key and the request match category resulting from a match due to linkage tables will be linkage_table.
	Suppress records Data in Stitch output (core tables, stitched tables, and the Unified Coalesced table) that matches the inbound request is suppressed. All records that match values in the inbound request are set to NULL.
	Delete records Data in source tables that matches the inbound request is deleted. Note Data that is deleted today is removed from the next refresh of Stitch output (core tables, stitched tables, and the Unified Coalesced table).
	Refresh reports When the delete request workflow is finished the Unified Compliance and Unified Compliance Overview tables are updated. When a record is matched in Unified Coalesced For the current Stitch run, associated records are visible in: Unified Coalesced Other database tables Important Be sure to use the compliance reports tables to identify data that must be deleted from systems that provide data to Amperity. If data is not deleted from these systems in a timely manner, it is possible for customer data that was previously deleted by Amperity to be re-added to Amperity because the data is still present in the data that is provided to Amperity.

Delete PII

An inbound request may require deleting specific PII fields within customer records.

Important

The delete PII workflow requires requires using the compliance/pii semantic tag to specify which fields within records may be deleted.

The following diagram shows the workflow that occurs when a delete PII request is present in the inbound requests table.

The following sections describe the individual steps within the workflow that occurs when a delete PII request is present in the inbound requests table.

	Find records A delete PII request runs runs when type field in the inbound requests table is set to delete_pii. The strategy for an inbound request is set to exact by default. An exact matching strategy will find all records in all source tables that match the email address, phone number, or address group that is included in the inbound request. The strategy may be set to connected_pii. A connected PII matching strategy will find all records in source tables that match the email address, phone number, or address group that is included in the inbound request and will find all matching records in Stitch output (core tables, stitched tables, and the Unified Coalesced table). Note Source keys or linkage tables can be used to trace records in a custom domain table back to a source table. When either of these are implemented, a direct or connected match on a CDT will find all corresponding records in source domain tables.
	Suppress records Data in Stitch output (core tables, stitched tables, and the Unified Coalesced table) that matches the inbound request is suppressed. All values in all columns that match the inbound request are set to NULL.
	Delete PII Column values in source tables that match the inbound request are deleted. Note Data that is deleted today is removed from the next refresh of Stitch output (core tables, stitched tables, and the Unified Coalesced table). Important This step requires applying the compliance/pii semantic tag to all fields in all source tables that contain data that should be deleted when an inbound request asks Amperity to delete data.
	Refresh reports When the delete PII request workflow is finished the Unified Compliance and Unified Compliance Overview tables are updated. When a record is matched in Unified Coalesced For the current Stitch run, associated records are visible in: Unified Coalesced Other database tables Domain tables, with redaction For all future Stitch runs, associated records are visible in: Unified Coalesced, with redaction Other database tables, with redaction Domain tables, with redaction Important Be sure to use the compliance reports tables to identify data that must be deleted from systems that provide data to Amperity. If data is not deleted from these systems in a timely manner, it is possible for customer data that was previously deleted by Amperity to be re-added to Amperity because the data is still present in the data that is provided to Amperity.

Request types

You can configure Amperity to support the following compliance actions:

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

   Note

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

2. Delete rows of records

3. Delete personally identifiable information (PII) from rows of records

Important

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.

Your brand should take steps to ensure that your upstream processes have completed their own delete actions before allowing those sources to provide updated data to Amperity.

Request strategies

You can configure compliance actions to support the following request strategies:

1. Find all rows that exactly match the compliance request.

2. Find all rows that exactly match the compliance request along with any row in a stitched table that shares an Amperity ID with those records.

Important

You may wish to use Amperity to identify which records belong to a customer. If the strategy field is set to connected_pii, records are connected by 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 workflows

A privacy rights workflow requires the following steps:

1. Configure inbound requests table.

2. Apply semantic tags to tables with desired deletes.

3. Configure source keys.

Inbound requests table

An inbound request table contains information about compliance requests. It must contain at least one field that is used to identify matching records: this is most commonly email address, but phone number, address, and custom fields such as a customer key or loyalty ID can also be used.

If multiple identification fields exist, they are treated as though they are separate requests, identifying source domain records that can be matched to ANY of the identification fields.

Note

An address group is a single entity. A compliance action must match all fields within the address group: address, address2, city, state, postal, and country. It is important for addresses in incoming data to be standardized before they can be used for matching in compliance requests.

It also contains information about the request type and request strategy.

Tip

You may use a custom domain table to transform an inbound request table into the needed format. If you intend to use only a single request_type or request_strategy, those can be hard-coded in the custom domain table, rather than be included as part of the inbound request.

Inbound request table name

Give the inbound requests table a name that makes sense for your brand and your workflow. The presence of compliance/request semantic tags identifies this table as a compliance request table within Amperity.

Inbound request table columns

An inbound requests table may have the following columns. compliance/request- semantics are used to identify the fields.

Column	Description
id	Required Semantic tag: compliance/request-id A unique identifier for an inbound request. This identifier is used for validation purposes, allowing compliance actions to be easily linked to specific requests.
type	Required Semantic tag: compliance/request-type The request type for the compliance action. May be one of: dsar Default. Generate a report without deleting data. delete Delete rows that are found by the request strategy. delete_pii Delete only personally identifiable information (PII) from rows that are found by the request strategy. Important The delete_pii request type will only delete columns that are tagged with the compliance/pii semantic tag.
strategy	Required Semantic tag: compliance/request-strategy The request strategy for the compliance action. May be one of: exact Default. Find all rows that exactly match the compliance request. connected_pii Find all rows that exactly match the compliance request along with any row in a stitched table that shares an Amperity ID with those records.
email	Optional Semantic tag: compliance/request-email Find all records that match an email address. This action is case-insensitive. The values in this field will be checked against any source table that has the email semantic tag.
phone	Optional Semantic tag: compliance/request-phone Find all records that match a phone number. The values in this field will be checked against any source table that has the phone semantic tag.
address	Optional Semantic tags: compliance/request-address compliance/request-address2 compliance/request-city compliance/request-state compliance/request-postal compliance/request-country The values in these fields will be checked against any source table that has the address, address2, city, state, postal, and/or country semantic tags. If a source table only has some of these values tagged, the missing values will be treated as NULL. Note An address group contains multiple fields, but is a single entity for a compliance action. In order to match to records in source tables, ALL values must match. Address standardization should be applied upstream of Amperity so that address can be reliably used to identify source records.
custom-key	Optional Semantic tag: compliance/request-custom-key Find all records that match a custom value. This action is case-insensitive. The values in this field will be checked against any source table that has the compliance/custom-key semantic tag.

Apply semantic tags

Semantic tags are used to identify records and fields eligible for compliance actions.

Identify eligible records

Inbound requests must include at least one field that can be used to identify records belonging to a person, such as email. If this field is tagged with the compliance/request-email semantic, it will be checked against any source table that has a field tagged with the email semantic.

In addition to email, phone number and physical address can be used to identify records belonging to a person.

Note

An address group contains multiple fields, but is a single entity for a compliance action. In order to match to records in source tables, ALL values must match. Address standardization should be applied upstream of Amperity so that address can be reliably used to identify source records.

Use custom keys

Custom fields can also be used for case-sensitive matching on records. When the inbound request table is tagged with the compliance/request-custom-key semantic, the values in that field will be checked against any source table that has a field tagged with the compliance/custom-key semantic.

You may the following custom key pairs:

compliance/custom-key and compliance/request-custom-key
compliance/custom-key-2 and compliance/request-custom-key-2
compliance/custom-key-3 and compliance/request-custom-key-3

Identify fields to delete

Note

This section only applies if the delete_pii request type is used.

The delete request type acts on entire rows of source tables, but it is possible to only delete PII from a record, while leaving the rest of the data intact.

Any field that is tagged with the compliance/pii semantic will be replaced with NULL if its record is eligible for compliance actions and an inbound request with the delete_pii request type is ingested.

Configure source keys

Source keys are semantics used to link records in a custom domain table back to their corresponding source table records so that privacy compliance actions can be applied.

In some cases a compliance request cannot directly match to source table rows. This includes an untagged table for the exact strategy, and a non-stitched source table for the connected_pii strategy. In these cases source rows should be linked to upstream custom domain tables which can be matched on.

To configure source keys

For each CDT with PII data on the Sources page do the following:

1. Pick a column to tag with your source key. In most cases you want this value to be unique to a given record in a custom domain table and its upstream source table record. pk columns are often a good option if they are selected from the upstream source table.

2. Pick a source key semantic, these follow the pattern source/<source key name>. For example: when tagging the primary key value from Table_A you might use source/table-a-pk.

3. Tag the corresponding fields on the feed and custom domain table with the source key you chose and click Activate.

Once these keys have been configured, a match on a row in a custom domain table will link to source records with the same source key value.

Note

Source keys and linkage tables identify which source table records were used to create a custom domain table record. They do not trace individual fields, so compliance/pii semantic tags should be applied directly to the source tables, not on the custom domain tables, if the delete_pii compliance type is used.

Create linkage tables

A linkage table is a CDT used to trace records in a custom domain table back to their corresponding source table records so that privacy compliance actions can be applied. It is an alternative to source keys for advanced users who want to express links between their CDTs and source tables using SQL.

In some cases a compliance request cannot directly match to source rows. This includes an untagged table for the exact strategy, and a non-stitched source table for the connected_pii strategy. In these cases source rows should be linked to upstream custom domain tables which can be matched on.

Note

The main reason for using a linkage table rather than source keys is if the custom domain table to which you are linking is aggregating records using multiple keys since Amperity does not allow source keys to be composed of multiple columns.

To add a linkage table

1. Open the Sources page.

2. Under Custom domain tables click Add table.

3. Write SQL to specify which CDT records link to which source records. This will be four columns specifying the source table name, source table pk, cdt table name, and cdt pk.

4. Click Next.

5. Tag the the source table name with compliance/source-ds, source table pk with compliance/source-pk, cdt table name with compliance/cdt-ds, and cdt pk with compliance/cdt-pk.

6. Click Activate.

Note

Source keys and linkage tables identify which source table records were used to create a custom domain table record. They do not trace individual fields, so compliance/pii semantic tags should be applied directly to the source tables, not on the custom domain tables, if the delete_pii compliance type is used.

Reports tables

Amperity generates the following reports tables as part of a Stitch run. Each table contain the results of the most recent privacy rights workflow. These tables may be empty when no requests were made.

Unified Compliance Overview

The Unified Compliance Overview table contains an overview of the results of data subject access requests (DSAR) and customer delete requests, including the number of records found, the time at which the request was completed, and the type of request.

The Unified Compliance Overview table contains the following columns:

Column name	Data type	Description
Request Datasource	String	The location (database and table) from which the request to find matching records originated.
Record Completion Date	Datetime	A timestamp that indicates when the request was completed.
Request ID	String	An identifier for the request.
Request Type	String	The request type for the compliance action. May be one of: delete, delete_pii, or dsar.
Request Strategy	String	The request strategy for the compliance action. May be one of: exact or connected_pii.
Request Email	String	Optional The email address used to match to source table records, if provided.
Request Phone	String	Optional The phone number used to match to source table records, if provided.
Request Address	String	Optional The street address used as part of an address group to match to source table records, if provided.
Request Address2	String	Optional The address2 field used as part of an address group to match to source table records, if provided.
Request City	String	Optional The city used as part of an address group to match to source table records, if provided.
Request State	String	Optional The state used as part of an address group to match to source table records, if provided.
Request Postal	String	Optional The postal code used as part of an address group to match to source table records, if provided.
Request Country	String	Optional The country used as part of an address group to match to source table records, if provided.
Request Custom Key	String	Optional The custom key used to match to source table records, if provided.
Rows Found	String	The number of matching records that were discovered by the request.

Unified Compliance

The Unified Compliance table supports privacy rights workflows and contains the search results for data subject access requests (DSAR) and customer delete requests. A row is added to the the Unified Compliance table for each matching record.

The Unified Compliance table contains the following columns:

Column name	Data type	Description
Request Datasource	String	The location (database and table) from which the request to find matching records originated.
Request ID	Integer	An identifier for the request to find matching records.
Request Type	String	The request type for the compliance action. May be one of: delete, delete_pii, or dsar.
Request Strategy	String	The request strategy for the compliance action. May be one of: exact or connected_pii.
Request Semantic	String	The type of PII used to search for matching records. For example: email, address, or phone.
Request Semantic Value	String	The value that was used to search for matching records. For example: paul.jackson@amperity.com.
Request Match Category	String	The match category will be direct for matches on pii, connected for matches on the amperity-id of a direct match, and source_key or linkage_table for upstream source records.
Amperity ID	String	The unique identifier that is assigned to clusters of customer records that all represent the same individual. The Amperity ID does not replace primary and foreign keys, but exists alongside them within unified profiles.
Datasource	String	The location (database and table) in which the matched record was found.
PK	String	The primary key for the matched record.
PII columms	String	A series of column names. Each added PII column matches the name of a column in which matching records were found.