Introduction

This document outlines the process for requesting the removal and redaction of consumer data within Reactor, emphasizing the shared responsibilities between Reactor Data and its customers in complying with the CCPA and other relevant regulations. This process ensures that consumer data is appropriately handled within Reactor's storage systems and in the data exported to your destination.

Before You Get Started: Source Controls, Landing Tables, and Model Configuration Updates

 

Configure PII Settings in the Data Standard

ℹ️ This feature is in development and should be released by the end of June 2025.

To effectively manage Personally Identifiable Information (PII) and enable Reactor's data deletion and redaction capabilities, you must configure PII settings within the Data Standard for each connected data source. Reactor Data users can define PII fields for each connected data source.

For each PII field, you will be able to define:

• PII Classification: Categorize fields as PII, None, or Other.
• PII Level: Categorize fields as No PII, Direct PII, or Indirect PII.
• PII Handling: 
  • PII Handling Action on Storage: This option specifies whether and how to anonymize the field before the data is stored. The original PII value will not be stored, visible in the Reactor interface, or transmitted to any downstream destinations if a handling action on storage is defined.
  • PII Handling Action on Anonymization: This option specifies whether and how to anonymize the field when Reactor processes a data deletion request.
  • PII Handling options: When designating whether a PII field should be handled on storage or on anonymization, you will need to specify how you'd like your PII fields anonymized. For each PII field, you can choose one of the following actions:
    • Hash: Anonymize the data using the 128-bit MurmurHash3 algorithm.
    • Mask: Obscure certain characters with a masking character of your choice.
    • Replace: Substitute the PII with null or a default value.

See our Help article Standardize Your Source Data for additional details on configuring PII settings in the Data Standard.

Add Columns to Landing Tables for Deletion and Redaction Indicators

In your landing tables, add two Boolean columns that can be used to indicate 1. whether a record should be deleted; and 2. whether a record contains redacted PII: 

1. Field Name: reactor_is_deleted
   1. This column indicates whether a record has been purged from Reactor and should be deleted from downstream destinations. For any record with true in the this field, this version and all prior versions of the record should be purged from downstream destinations.
   2. See Creating Landing Tables in the Data Warehouse | Is Deleted for more information on this field, including suggested mapping logic
2. Field Name: reactor_is_redacted
   1. This column indicates whether personally identifiable data in a record has been redacted by Reactor. For any record with true in this field, all PII field values in the record have been redacted, masked, or nulled, and those fields should not be used in downstream customer activations.
   2. See Creating Landing Tables in the Data Warehouse | Is Redacted for more information on this field, including suggested mapping logic

Update Models in the Mapping Canvas to Include Deletion and Redaction Indicators

Add and map fields to any models that output to tables with reactor_is_deleted and reactor_is_redacted columns. See our article Creating Landing Tables in the Data Warehouse for recommended mapping expressions for both fields.

Data Removal Responsibilities

To ensure compliance with data removal requests:

• Customer Responsibilities: Your organization is responsible for promptly notifying Reactor Data when a consumer requests the deletion of their information. Due to time constraints for addressing these requests, Reactor Data urges customers to provide notification as soon as possible.
• Reactor Data Responsibilities: Reactor Data is responsible for deleting and redacting the specified Personally Identifiable Information (PII) from its internal storage systems (Kafka logs and Atomic Store) and confirming the deletion to your organization. Reactor Data aims to complete the data deletion and redaction process within ten (10) business days of receiving the deletion request notification.

Data Removal Process

ℹ️ If your organization stores data in a legacy SoundCommerce-hosted data warehouse instance (Google BigQuery or Snowflake), read about the removal process for such instances in the section below: Removal Process for Legacy SoundCommerce-Hosted Data Warehouse Customers.

The data removal process involves the following steps:

Step 1: Initial Request

A member of your organization must email privacy@reactordata.com, specifying the users whose information should be deleted. This request can be submitted as a list of customer identifiers within the email or as an attached spreadsheet containing the necessary information. At a minimum, Reactor Data requires a list of email addresses and names for the users to be deleted.

Step 2: Processing the Request

Upon receiving a deletion request, Reactor will mask and anonymize all records associated with the individuals identified in the request within 10 business days per the PII Handling settings configured for each connected data source. Upon masking and anonymizing the records, Reactor will emit two versions of every message ingested by Reactor that is associated with that individual (based on the identifying factors included in the request).

• Version 1: This version contains the unredacted message, with the Reactor metafield should_delete set to true. This field indicates that this specific version and all prior versions of the record should be purged from downstream destinations. If the should_delete key exists in a message's list of Reactor metafields, it will be set to true.

• Version 2: This version contains the redacted version of the message (redacted at the field level as defined in the source's Data Standard), with the Reactor metafield has_redactions set to true. This indicates that all PII field values in the record have been redacted, masked, or nulled, and those fields should not be used in downstream customer activations. Any future versions of this record will also have their PII fields anonymized.

Additionally, Reactor Data will re-emit the deleted and redacted versions of the message again within 30 days of the original request, just to be safe.

Step 3: Downstream Redaction & Deletion Indicators

Reactor is updating mapping configurations to include two new fields in your data outputs, providing clear signals for downstream systems:

• is_redacted (Boolean): If this field is true, it indicates that PII fields within that record have been anonymized. This corresponds to the has_redactions Reactor metafield.

• is_deleted (Boolean): If this field is true, this specific version and all prior versions of the record should be purged from downstream destinations. This corresponds to the should_delete Reactor metafield.

Step 4: Customer Actions for Data Deletion in their Data Warehouse or File-Store Solution

For clients who are using Reactor to export data to their own data warehouse (BigQuery, Snowflake, Databricks) or file-store solution (GCS, S3/Redshift), it is crucial to utilize Reactor's deletion policy with minimal maintenance by following the best practices outlined in the documentation regarding deduplication and pruning.

If the client is using the data deduplication and pruning process defined in the help documentation and maps their models in Reactor with the suggested mappings, the is_deleted and is_redacted fields will be exported as follows:

• Unredacted message versions marked for deletion (Version 1): is_deleted = true.

• Redacted message versions to replace the deleted message (Version 2): is_redacted = true.

The provided deduplication and pruning queries are designed to ensure that messages marked for deletion (is_deleted = true) and all other previously-ingested versions are removed from your data warehouse. You can find example deduplication queries tailored for Google BigQuery and Snowflake in the "Keeping Your Data Warehouse Lean and Insightful" document. These queries will exclude "stale" records, as well as records that have been marked for deletion by Reactor.

ℹ️ Databricks users who ingest files from S3 will need to prune the files directly in S3 if you do not retain these files after ingesting their contents to Databricks. It is also recommended to consider moving these old JSON files to a lower-cost storage tier or archiving them if they are no longer actively needed for analysis or compliance purposes.

Step 5: Validation and Notification

Reactor Data will validate that the personal information of the users who requested anonymization has been successfully purged from Reactor Data's systems. Upon successful validation and confirmation, Reactor Data will notify your organization via email that the data removal and redaction request has been completed.

Data Removal Process for Legacy SoundCommerce-Hosted Data Warehouse Customers

For customers whose data is exported from Reactor to a SoundCommerce-hosted data warehouse instance that includes SoundCommerce's Retail Data Model, the data removal process involves the following steps:

Step 1: Initial Request:

• • A member of your organization must email privacy@reactordata.com, specifying the users whose information should be deleted.  
  • This request can be submitted as a list of customer identifiers within the email or as an attached spreadsheet containing the necessary information.  
  • At a minimum, Reactor Data requires a list of email addresses and names for the users to be deleted.  

Step 2: Processing the Request:

• • • Reactor Data will add the provided email addresses and names to a "Do Not Track" master list associated with the customer's account.  
    • The CUID (Customer Unique Identifier) generation process will utilize this "Do Not Track" list to identify and delete records that match the provided email addresses (after normalization and conversion to lowercase).  
    • The CUID process will assign a new, anonymous CUID value to the affected customer record and set the "do_not_track" field to "TRUE."  
    • This "do_not_track" flag will effectively nullify PII fields in all downstream views and tables within Reactor's database, thereby scrubbing the PII.  

Step 3: Validation and Notification:

• • Reactor Data will validate that the personal information of the users added to the "Do Not Track" list has been successfully purged from Reactor Data's systems.  
  • Upon successful validation and confirmation, Reactor Data will notify the customer via email that the data removal request has been completed.