PII protection
Datahash Signals is built privacy-first. Personal identifiers are hashed before they are delivered to any destination, raw values are never stored, and everything in between is encrypted. This page explains how that works at each stage.
Hashing
Section titled “Hashing”Signals matches conversions at destination platforms using hashed identifiers, never raw ones. Personal identifiers such as email, phone number, and name are normalized and then hashed with SHA-256, the algorithm the advertising platforms’ Conversion APIs require, before any event leaves for a destination. Because SHA-256 is one-way, a hashed identifier cannot be reversed back to its original value at any later stage.
Normalization comes first, because a hash only matches when both sides format the value identically. Signals lowercases and trims text and formats phone numbers to the E.164 standard before hashing, so the resulting hash matches what the destination expects and match quality stays high.
Where hashing happens depends on the type of source:
- Web conversions. The NeoTag pixel normalizes and SHA-256 hashes personal identifiers directly in the browser, before the event is ever sent to Signals. Raw identifiers never reach Datahash for web sources.
- CRM sources (such as Salesforce, Zoho, and HubSpot). The Signals connector reads each record, then normalizes and SHA-256 hashes the identifiers in memory as the very first step, and emits only the hashed event into the pipeline. Raw values are never written down, and nothing downstream of the connector ever sees them.
- File and data warehouse sources. Here you control the export, so Signals requires identifiers to be SHA-256 hashed before the data is handed over and does not accept plaintext identifiers through these connectors. In this model the raw PII never leaves your environment at all. Apply SHA-256 hashing to PII covers how to do that in SQL, Google Sheets and code.
Across all three, identifiers move through the pipeline and on to destinations only in hashed form.
Encryption in transit
Section titled “Encryption in transit”All data moving to and from Signals travels over encrypted connections using TLS (HTTPS). This covers events sent from your site or your connected sources into Signals, and events delivered onward to the destination platforms’ Conversion APIs.
Encryption at rest
Section titled “Encryption at rest”The limited data Signals retains, which is aggregated reporting metrics and platform configuration rather than raw events or PII, is encrypted at rest using industry-standard encryption with managed keys. Because raw events and personal identifiers are never persisted, there is no stored PII to protect at this layer.
Data minimization
Section titled “Data minimization”Signals is designed to carry as little personal data as possible:
- Raw events and raw PII are never stored. They exist only in memory for the few seconds it takes to process a run, and are discarded once the event has been delivered or has finally failed.
- Only the identifiers needed to match a conversion at the destination are processed, and they move through the pipeline in hashed form.
- What Signals keeps is aggregated counts, such as success, failure, and skipped totals, along with data-quality coverage, not the underlying records.
- Where you integrate a consent management platform, Signals is consent-aware and can suppress events that do not carry the required consent.
For a fuller picture of what Signals stores and for how long, see Data handling & storage.