Design systems to avoid unnecessary accumulation of personal or identity data while still allowing the functional input required for a defined interaction.
Zero Collection does not mean that a digital system receives no input. It means designing the interaction so the system avoids accumulating personal or identity data that is not necessary for the defined function.
The architectural question is simple: what does the system truly need to know in order to perform the requested task?
Traditional systems often collect information because it may be useful later. Zero Collection reverses that assumption.
| Conventional pattern | Zero Collection orientation |
|---|---|
| Ask for identity first | Ask whether identity is required at all |
| Store broad user profiles | Limit inputs to the defined function |
| Keep fields for possible future use | Avoid unspecified future-use collection |
| Link interactions to persistent accounts | Use scoped or transient identifiers where feasible |
Map every input to a concrete system function. If a field has no necessary role in delivering the function, challenge its presence.
Where context allows, separate authorization, routing, and personalization from durable real-world identity.
Collection also occurs through telemetry, SDKs, logs, cookies, analytics, error reports, and connected services. These channels must be reviewed too.
Some systems must process personal data for legal, safety, contractual, security, or functional reasons. Zero Collection does not remove those obligations.
No. Functional input may still be necessary. The principle is to avoid unnecessary accumulation of personal or identity data.
They can be complementary, but they are not identical. ZDP frames collection as an architectural dependency question rather than a legal compliance guarantee.
No. Some services need identity for legal, safety, contractual, security, or operational reasons. The design goal is to challenge unnecessary identity dependency.
Start with forms, account fields, telemetry, analytics, SDKs, logs, cookies, and third-party integrations that may collect data outside the primary interface.
ZDP treats collection, retention, and exploitation as connected architectural questions. Each pillar should be evaluated in context rather than as an isolated compliance promise.