Industry Reference | Retail and E-commerce
Part of the industry reference. Restructured from the retail deep dive for quick lookup.
Abbreviations: HMAC = keyed-hash message authentication code; FPE = format-preserving encryption; DDM = dynamic data masking; PAN = Primary Account Number.
For PCI-DSS tokenization details, see the techniques reference. For the e-commerce reference architecture, see architecture patterns.
Core challenge: multi-domain identity
A single customer appears under 5+ identifier types. Identity resolution must happen in Zone 0 before pseudonymization — otherwise the same customer gets different pseudonyms in different data domains, breaking analytics.
| Identifier domain | Examples | Treatment | Notes |
|---|---|---|---|
| Canonical customer ID (post-resolution) | Internal resolved ID | Deterministic encryption (shared key across domain pipelines) | Ensures same pseudonym across transaction, browsing, loyalty data |
| Email, phone | Contact details | Domain-specific HMAC keys | Pseudonymized for reference, not used as join keys |
| Payment card (PAN) | Credit/debit card numbers | Tokenization (PCI-DSS v4.0.1) | Vaulted or vaultless; scope reduction for PCI compliance |
| Cookies | Browser tracking | Consent-gated, purpose-specific | ePrivacy Art. 5(3) requires consent |
| Purchase sequences | Transaction history with timestamps, locations, amounts | Sequence-level aggregation or DP | 4 points → 90% unique; 3 with price data |
PCI-DSS v4.0.1 tokenization decisions
| Approach | PCI scope reduction | GDPR status | When to use |
|---|---|---|---|
| Vaulted tokenization | Significant — random token, no mathematical relationship. Full scope reduction only when token-only systems are properly segmented and cannot access vault or detokenization. | Still personal data (reversible via vault) | Default for payment data; strongest PCI scope reduction |
| Vaultless tokenization (FPE) | Partial — depends on key management assessment | Personal data (reversible) | When format compatibility with legacy systems required |
| Keyed hash (HMAC) | Accepted since PCI-DSS v4.0.1 (unkeyed explicitly insufficient since Mar 2025) | Personal data (pseudonymization) | When irreversible substitution acceptable and no format constraint |
| Truncation (first-6/last-4) | Accepted by PCI | May still be personal under GDPR (re-identification possible via other data) | Limited use; dual compliance requires caution |
See Module 05 § BigQuery DDM and the retail deep dive for the full PCI-DSS treatment.
Consent management
Retail requires consent-aware views in the pseudonymized zone — row-level security filtering by consent flags per purpose.
| Touchpoint | Consent mechanism | Pipeline impact |
|---|---|---|
| Online (web) | Cookie consent banner | Consent flag per cookie category; consent-gated data flow |
| Mobile app | In-app consent dialog | App-level consent store; sync to data platform |
| In-store | Loyalty program T&C | Contractual necessity (Art. 6(1)(b)) for program operation; explicit consent for marketing |
| Email / direct | Opt-in/opt-out | Preference center; unsubscribe propagation |
| Third-party sharing | Explicit consent per partner | Partner-specific consent flag; clean room architecture |
Common client starting position
Multiple identity silos (email in one system, loyalty in another), no unified resolution. Consent fragmented across touchpoints. Typical first engagement: unify identity in Zone 0, implement consent-aware pseudonymized views in Zone 1, then add Zone 2 for analytics.