How TrackLayer handles PII: hashing, storage, deletion

PII is broader than obvious fields such as email address or phone number. In a server-side tracking system, the relevant question is whether a field directly identifies a person, can be used to single them out, or becomes identifying once combined with contextual data such as order activity, ad clicks, device fingerprints, or support records. That is why TrackLayer distinguishes direct identifiers, quasi-identifiers, and pseudonymous identifiers rather than treating everything as the same risk class.

Direct identifiers are transformed as early as possible. Quasi-identifiers are retained only for narrow operational windows. Pseudonymous identifiers are allowed longer retention when they are necessary for attribution, suppression, or DSR matching, but they still remain subject to opt-out and deletion controls.

Hashing is not a marketing claim inside TrackLayer. It is a deterministic pipeline step with a narrow purpose: reduce plaintext exposure while preserving compatibility with destinations that accept hashed identifiers for matching. The practical effect is that raw identifiers have an extremely short lifespan and are not allowed to drift into logs, queues, or warehouse tables by accident.

1. Client sends the raw email to TrackLayer at `/v1/events` as part of the event payload.
2. An edge worker normalizes the value and computes a SHA-256 hash in memory.
3. The raw email is discarded immediately and is never written to durable storage.
4. Only the resulting hash persists to the TrackLayer database and any allowed downstream delivery.

This pattern matters because the biggest PII failures are usually not cryptographic failures. They come from stray plaintext in debug logs, replay queues, support tools, or vendor exports. Moving transformation to the edge sharply limits the number of systems that ever touch the raw value.

Some boundaries should not depend on feature flags or merchant preference. TrackLayer treats the rules below as hard constraints because they are where privacy, security, and platform policy failures tend to start.

When a merchant receives a right-to-delete request, the important issue is speed plus proof. TrackLayer exposes a deletion workflow at POST /v1/data-subject/delete with an identifier payload so the merchant can submit a stable email, phone, external_id, or another supported key. The system resolves the matching records, places a deletion tombstone on the subject, and fans the request across active storage layers and integrated destinations.

Propagation completes within 48 hours across all integrated platforms, including Meta, Google, and other configured destinations. The workflow records when the deletion was accepted, which systems were touched, and whether any downstream retry is still pending. That matters for support teams because a privacy promise without an operational receipt is not enough.

Data subject rights are not limited to deletion. Merchants also need a way to retrieve the subject-scoped records that remain in the retention window. TrackLayer exposes GET /v1/data-subject/export with an identifier plus authentication, returning a JSON bundle of all matching records, hashes, event metadata, destination delivery status, and audit notes relevant to that subject.

The export is designed for portability and support operations rather than for direct end-user display. Merchants can merge it with order data, CRM notes, or ticket history to answer an access request comprehensively. Because the export is generated from the active subject index, it respects deletion tombstones and current suppression state.

Retention is where minimization becomes measurable. TrackLayer keeps short-lived operational context only as long as it serves a defined function such as fraud detection, delivery debugging, subject lookup, or auditability. Longer windows are reserved for audit artifacts and only where a merchant has a documented need.

Sensitive personal information is handled differently because the harm model is different. Health, financial, and biometric data can create regulatory obligations far beyond ordinary marketing measurement, and they can cause disproportionate harm if exposed or misrouted. For that reason TrackLayer does not treat sensitive fields as just another event attribute.

Sensitive-data workflows are available only on the enterprise tier and require explicit review plus a BAA before processing is enabled. The objective is not merely to hash a field. It is to constrain who can send it, where it can route, how it is audited, and whether it should be accepted at all.

Every access to PII-linked records is logged. That includes subject lookup, export generation, deletion initiation, support review, and any privileged administrative access to protected records. The log captures who accessed the record, when it happened, which identifier was used to match the subject, and what action was taken.

Merchants can review these logs directly, and auditors can be granted access to the same evidence set during privacy or security reviews. This is how TrackLayer turns privacy controls into inspectable operations rather than trusting internal process alone.