PII hashed, masked, or stripped before vendors ever see it

Why PII handling at the vendor level is the wrong layer

Most teams hash PII inside each vendor integration: a Meta CAPI connector hashes email for Meta, a Google Ads connector hashes email for Google, the warehouse loader maybe doesn't hash at all. This works until it doesn't.

PII rules in one place

Below is an org-wide PII configuration. Every pipeline inherits these rules. Per-vendor overrides handle the cases where a destination needs a slightly different hash format.

# pii-handling.yaml
# Org-wide PII rules applied at the Signal Core BEFORE any
# pipeline transformation or vendor delivery. No raw PII
# leaves the customer cloud at any point.

org_data_layer:
  classifications:
    email:
      action: hash_sha256_normalised
      # Trim, lowercase, then SHA-256.
      # Output format vendors expect for matching.

    phone:
      action: hash_sha256_e164
      # Normalise to E.164, then SHA-256.

    first_name:
      action: hash_sha256_normalised

    last_name:
      action: hash_sha256_normalised

    ip_address:
      action: mask
      # Strip last octet for IPv4, last 80 bits for IPv6.
      # Preserves geo-coarse signal without identity.

    user_id:
      action: hash_sha256
      # Used as match key for CDP and warehouse joins.
      # Hashed once, deterministic across all vendors.

    payment_card:
      action: strip
      # Never delivered to any vendor. Period.

    date_of_birth:
      action: strip

    home_address:
      action: strip

  # Per-vendor overrides where the destination has its own
  # requirements (e.g. Customer Match needs a slightly
  # different hash format).
  vendor_overrides:
    google_customer_match:
      email: hash_sha256_normalised_google
    meta_capi:
      external_id: hash_sha256

  # Audit retention for the masking decisions themselves
  # (which fields were hashed, which stripped) without
  # ever logging the raw values.
  audit_log:
    retain_decisions: true
    retain_raw_values: false

Where PII transforms run, by setup

The layer at which PII is transformed determines whether the policy stays consistent across vendors and whether the audit trail is complete.

Frequently asked questions

What PII does Datafly Signal handle?

The default Org Data Layer recognises email, phone, first_name, last_name, ip_address, user_id, payment_card, date_of_birth, and home_address. Each maps to an action: SHA-256 hashing for matchable fields (email, phone, names), masking for IP addresses (last octet stripped on IPv4, last 80 bits on IPv6), and full strip for fields that should never reach a vendor (payment cards, DOB, home address). You can add custom classifications for industry-specific data.

How is the PII transformed for Meta CAPI vs Google Ads?

Each vendor has known hash format expectations. Meta CAPI requires SHA-256 of trimmed-lowercased email. Google Customer Match requires SHA-256 of trimmed-lowercased email after specific Gmail-address normalisation rules. TikTok wants SHA-256 of the raw lowercase string. The Org Data Layer encodes each vendor's exact format so match rates max out automatically — without each integration team needing to know the per-vendor rules.

Does Datafly Signal as a vendor see raw PII?

No. The platform is deployed as single-tenant Kubernetes inside the customer's own AWS, GCP, or Azure account. All PII transformation happens in the customer's VPC. Datafly the company never receives the raw values, never receives the hashed values, never receives the events. Procurement-friendly by design.

Can I customise classifications for industry-specific data?

Yes. Beyond the defaults, you define custom classifications: e.g. policy_number for insurance, mrn for healthcare, account_id for banking. Each classification has its own action (hash, mask, strip, or custom transform). Per-vendor overrides handle cases where a destination needs a different format than the default for that classification.

Are PII transform decisions auditable per event?

Yes. The audit log records which fields were hashed, masked, or stripped per event, the classification matched, the vendor target, and the rule that produced the decision. The raw values are never logged, only the decisions. Searchable by event ID, user ID, classification, or vendor. Retained per your audit retention policy.

How does this compare to GTM Server-Side?

In GTM Server-Side, PII handling lives inside individual server templates. Each template handles its own hashing, with whatever format the template author implemented. Different templates from different vendors handle the same email field differently. Datafly Signal puts PII rules above the pipeline layer so every vendor honours the same policy, with vendor-specific format rules selected automatically. Audit and consistency win.