Deleting the Undeletable: Managing PII at Shopify - Shopify

Structuring Event Data for Privacy at the Source

Shopify’s data warehouse ingests tens of billions of events per day from its streaming platform (Kafka). Historically, a lack of guaranteed schemas for these events made privacy management—especially deletion of Personally Identifiable Information (PII)—difficult. The Privacy team and the Data Science & Engineering teams collaborated on a schematization platform that captures structural, ownership, and privacy context for every event before it is stored.

The platform requires that schemas be proposed in a human-readable JSON format and reviewed for accuracy and privacy implications. As of now, more than 4,500 active schemas enforce the structure of every event at generation time. Each schema's privacy_setting section defines the data controller (the entity deciding how data is processed) and the data subject (whose data is tracked). Every field includes a data type, documentation, and a privacy block indicating sensitive data and handling instructions.

This system has increased privacy awareness among data science and engineering teams while improving reusability and observability. Schema discussions force developers to identify personal data fields early in the design process, which is a significant cultural shift for a large organization.

Pseudonymisation: Obfuscation and Tokenization

Before events enter the warehouse, two types of pseudonymisation are applied: obfuscation and tokenization. Both convert identifying data into non-identifying forms while preserving analytical value.

Obfuscation: Removing PII While Keeping Insights

Obfuscation masks or removes identifying parts of data so the described individuals remain anonymous. For example, an IP address is masked to half its bytes while retaining country and city-level geolocation—typically the original analytical intent. Likewise, a full user agent string is reduced to shared aggregate data (operating system, device type, major version) because the full string can contain highly identifying details like screen resolution, installed fonts, and clock skew. The table below illustrates common obfuscation mappings:

Tokenization: Reversible Replacement with Consistency

Some use cases require access to raw data. For those, Shopify built a tokenization engine that replaces PII with a consistent random token. Tokens are stored in the warehouse; a separate secured vault service maintains the token-to-PII mapping. When deletion is requested, only the vault mapping needs removal—all token copies become effectively non-detokenizable random strings.

Consider a customer (Hooman) purchasing from two merchants, AllBirds and GymShark. Before tokenization, his email appears in both transaction records:

After tokenization, his email becomes Token123 under the AllBirds controller and Token456 under the GymShark controller:

This demonstrates two critical properties:

1. Consistency: The same PII always maps to the same token under the same controller, so data scientists can track all purchases (e.g., all of Hooman's GymShark orders by searching Token456) without raw data access.
2. Multi-controller isolation: The same PII maps to different tokens under different controllers, ensuring data subjects can exercise deletion rights with one merchant without affecting another.

The vault service stores the mapping with controller and subject context, deciding whether to generate a new token or reuse an existing one:

Deletion Is a Vault Operation, Not a Warehouse Operation

With obfuscation and tokenization in place, deletion requests don't require scanning petabyte-scale datasets. Instead, removing a row from the tokenization vault is sufficient—the corresponding warehouse tokens become non-detokenizable strings.

Given the vault state below, where tokens are spread across multiple warehouse datasets:

If Hooman requests deletion from GymShark (Shopify acting as processor), the vault rows meeting the condition DataSubject == '[email protected]' AND Controller == Gymshark are removed (starred below):

For a complete deletion across all shops, Shopify needs only to find vault rows with Hooman as the data subject:

Consequently, the data warehouse itself remains untouched in every case. These vault operations complete in fractions of a second—at a scale where equivalent warehouse tasks can be highly time and resource intensive.

The Analytical Pipeline After Schematization

Putting it together, an event's journey from trigger to storage now passes through a scrubbing step:

1. A SignUp event enters the Kafka message pipeline.
2. The Scrubber tool intercepts the message and applies pseudonymisation based on the schema fetched from the Schema Repository.
3. If the event contains tokenization operations, the Scrubber sends the raw PII and privacy context to the Tokenization Vault.
4. The vault returns a Token mapping in exchange for the PII and context.
5. The Scrubber replaces the PII with the Token in the event content.
6. The anonymized/tokenized event is placed back onto the message pipeline.
7. The processed event is stored in the data warehouse.

Why Adoption Was the Harder Half

Building the technical machinery to classify and handle PII was only part of the problem. Getting teams across Shopify to actually use it, and then retrofitting years of unstructured historical data, proved equally demanding. The following lessons came out of that experience.

Having a working solution is not the same as having an adopted one. At Shopify's scale, rolling out new tooling meant deliberate collaboration with every stakeholder affected by the changes. Key factors made that engagement productive.

Design for the Default Path

The strongest lever for adoption was making the privacy-aware option the path of least resistance. Collecting unstructured analytical events now requires navigating a tedious approval process with multiple layers of review. Creating structured, privacy-aware events, by contrast, is quick, well-documented, and automated. When the right thing is also the easy thing, teams tend to choose it.

Proof Beats Persuasion

Convincing engineers that a new system will scale requires more than assurances. The team used the same reconciliation mechanisms that the Data Science & Engineering team relies on to prove correctness in their work. The tooling was tested against real datasets and stress-tested under loads several orders of magnitude higher than expected, which built credibility for the approach.

Give Teams Reasons Beyond Compliance

The new schematization platform was designed to deliver value beyond meeting privacy requirements. It now serves as a shared space for privacy education, prompting discussions about what constitutes PII and what can or cannot be done with it — clarity that was previously hard to come by. Additionally, because events are now schema-based, they integrate automatically with existing query engines and tooling, making datasets significantly easier to discover and explore. These benefits gave teams a genuine incentive to migrate.

Find the Shared Stake

Schematization was never solely a privacy project. It improved reusability and observability, cut storage costs, and streamlined routine tasks for data scientists. Because both the privacy and data teams had a real stake in the outcome, collaboration and adoption benefited from overlapping goals across the organization.

Retrofitting the Past

The harder challenge was the decades of legacy events — several petabytes of unstructured, historical data collected before the schematization platform existed. These datasets support analytical jobs with intricate interdependencies, so there was no straightforward migration path. A few practices helped navigate it.

Secure Organizational Commitment

An effort of this magnitude cannot survive on the dedication of a few individuals or teams. It requires sustained organizational alignment. Because leadership consistently communicated the importance of privacy work, team leads understood why it mattered and were willing to balance migration contributions against their regular roadmaps — even as people, teams, and priorities shifted over time.

Staff a Dedicated Task Force

Migration is slow, meticulous work. Rather than relying on a handful of individuals who might leave or change roles, the project was anchored to a dedicated team and formal project status. This ensured continuity regardless of personnel changes.

Remove Friction from the Migration Path

The goal was to minimize the burden on dataset owners and users. To that end, the team documented every required step, automated tedious tasks, and built integrations with the tools data scientists and data librarians already used. Engineering support was also on hand to resolve performance and technical issues as they arose. The upfront investment in tooling, documentation, and support processes paid off many times over during the long migration.

Keep Questioning the Dependencies

Regularly reviewing progress exposed dependencies that were not as rigid as they initially seemed. In cases where task X was blocking task Y, the team often found alternatives: the owners of X could reprioritize to unblock Y sooner; the two teams could coordinate on shared design choices to run X and Y in parallel; or X, Y, or both could be reframed to remove the dependency entirely. Constant monitoring made these reevaluations possible.

Operational Results

The schematization platform has been in production for over two years. It now supports more than 4,500 distinct analytical event schemas, each with its own privacy context. These schemas generate about 20 billion events per day — an average of roughly 230,000 events per second, with peaks exceeding 1 million per second. Every event passes through obfuscation and tokenization according to its schema's privacy context before it is accessible in the data warehouse or elsewhere.

The tokenization vault stores over 500 billion distinct PII-to-token mappings, totaling approximately 200 terabytes. Tens to hundreds of millions of these mappings are deleted daily in response to deletion requests. The key property of this design is that deletion happens instantaneously within the vault, with no corresponding operation needed in the data warehouse itself.

Onboarding historical data involved rebuilding roughly 100 datasets totaling tens of petabytes, which feed hundreds of analytical jobs. Development, rollout, and reprocessing together took about three years and involved the work of 94 different individuals.

The team decided to publish this account because they found very few industry examples when they started. In their experience, schematization — a platform that captures privacy context and data evolution — offers significant advantages for analytical event collection. It creates opportunities for handling sensitive information and for educating developers about data privacy. Their adoption story suggests people are eager to respect privacy when the tooling makes it practical.

Tokenization and obfuscation proved effective for managing, tracking, and deleting personal information. They enabled efficient deletion at very large scale. But the technical solution was only one piece; the organizational challenges of adoption and historical migration were just as significant. Bringing new value, capitalizing on shared goals, streamlining processes, and maintaining a dedicated task force were the tactics that made this cross-team initiative successful.