Quick definition: Zero-party data is information a person intentionally provides to an organization, often as preferences, stated interests, goals, or communication choices.
What is zero-party data?
Zero-party data is a marketing and product-data term for information someone deliberately shares, rather than information inferred from behavior or obtained from another organization. Examples include a selected product preference, stated budget range, onboarding goal, preferred communication channel, dietary choice, survey answer, or request for a certain type of content. It is often presented as more transparent than inferred profiling because the person actively supplied it.
Intentional disclosure does not make the information complete, permanent, accurate, or suitable for every use. A preference can be ambiguous, stale, selected under pressure, shared on behalf of someone else, or changed by later circumstances. A person who says they like a topic is not necessarily asking to be profiled indefinitely, contacted on every channel, or included in an unrelated audience. Treat zero-party data as a contextual statement with provenance, not as unrestricted permission.
The term is useful for product planning but is not a universal legal category. This article covers measurement, experimentation, and data-design considerations rather than legal advice. Appropriate privacy, security, and legal review is still necessary.
Concept boundaries: stated, observed, and inferred data
Zero-party data is intentionally stated by the person. First-party data is information collected through the organization’s direct relationship and can include zero-party data, observed events, and transactions. Behavioral data records what happened, such as pages viewed or features used. Inferred data predicts an attribute or intent from other records. Third-party data arrives from another organization. These categories can overlap; a preference form submitted on a company site is both zero-party and first-party in origin.
| Data type | Example | Interpretation boundary |
|---|---|---|
| Stated preference | “Send me product tips” | Use within its stated context and keep it current |
| Observed behavior | Opened a product-tips article | Interest is possible, not explicitly stated |
| Inferred attribute | Likely advanced user | Model output is uncertain and should be labeled |
| Third-party segment | Likely category shopper | Provenance and matching may be unknown |
Separate a preference from a consent or permission record. A chosen color, product goal, or content topic can personalize an interface. A communication choice may need separate handling from a general preference. A data system should retain the source interaction, time, wording or version, scope, and expiration or refresh behavior so downstream teams do not reinterpret a short answer as a blanket instruction.
Measurement and data-quality implications
Design preference collection around a clear user benefit. Ask only questions that improve the current experience, explain how the response will be used in plain language, offer meaningful options, and make later updates straightforward. Long onboarding questionnaires often produce low-quality answers because people want to reach the product, not because they have carefully chosen every value. A skipped answer is not an instruction to infer or fill in a sensitive attribute.
Store preference provenance as first-class data: question or interface version, selected value, timestamp, source surface, account or analysis key, and any scope or expiry. Avoid overwriting history without a clear current-value rule. A value selected two years ago may be useful for trend analysis but should not silently drive a current recommendation. Keep direct identifiers separate from routine measurement records and limit destinations to systems that need the preference for its defined purpose.
Measure collection quality. Track question display, answer rate, skip rate, invalid rate, changes over time, profile conflicts, and whether an answer materially improves an experience. Monitor representativeness: people who complete optional preference forms may differ from those who skip them. A dashboard based only on respondents can tell a valid story about respondents while being a poor description of the entire customer population.
Experimentation implications
Zero-party data can define a pre-treatment personalization segment or planned subgroup when it existed before assignment. For example, an app can test whether a user-selected learning goal changes the effectiveness of two onboarding paths. Freeze the value used for eligibility, assign variants within the relevant population, and retain an intent-to-treat analysis for all assigned eligible users. Report response and missingness rates alongside results.
Do not collect a preference after treatment and then use it to choose the analysis population. If a new onboarding flow encourages more people to select “advanced,” comparing only advanced respondents conditions on a treatment-affected outcome. Likewise, a survey response rate can differ by variant. Analyze the pre-specified assigned group first; treat new preference responses as outcomes or diagnostics, not as a filter for proving success.
Preference data can support a better product hypothesis, but it does not guarantee a causal effect. Someone who states a goal may be more motivated than someone who does not. Randomization within a consistently defined segment is what enables a comparison. See hypothesis, experiment unit, and sample-size planning for complementary design concepts.
Scenario: choosing onboarding content
An education app asks new learners, “What would you most like to achieve this month?” with a small set of goal categories and a skip option. The product uses the answer to choose a default lesson plan. It records the question version, selected category, time, and opaque account key in a protected preference service. The analytics stream receives only a controlled goal category where needed for aggregate product analysis; it does not copy free-text explanations or account contact details into event properties.
The team tests generic onboarding against goal-based onboarding. Eligibility is defined before randomization as new accounts with a selected goal, while a separately planned analysis includes all new accounts to understand the product-level effect. Assignment is stored before the first screen; lesson start and week-one completion are recorded with the analysis key. The report includes answer rate, skipped-question rate, treatment exposure, and outcome linkage by variant.
Goal-based onboarding increases early completion among respondents, but the team does not claim that goal collection itself improved all learners. Optional respondents were more engaged at baseline. It considers a follow-up test of a shorter preference prompt, keeps the skip option, and refreshes stale goals rather than assuming one declared objective remains true forever.
Caveats and common mistakes
- Treating a stated preference as permanent truth. Preferences change and need a current-value and refresh policy.
- Conflating a preference with a broad permission. A product choice does not automatically authorize unrelated activation.
- Forcing detailed questionnaires. This can reduce user value and produce rushed, low-quality responses.
- Using free text in broad analytics streams. It can contain unexpected personal or sensitive information.
- Analyzing only post-treatment respondents. Treatment may change who answers and what they select.
- Ignoring nonrespondents. Respondent-only results may not generalize to the full population.
A responsible zero-party-data workflow
- State the user benefit. Connect each question to a current, understandable product purpose.
- Collect minimally. Use bounded options, a skip path, and no fields that do not improve the experience.
- Retain provenance. Store question version, source, time, scope, and refresh or expiry behavior.
- Limit activation. Send the answer only to systems that need it for the documented purpose.
- Measure quality and coverage. Monitor response, skip, staleness, and differences between respondents and nonrespondents.
- Design experiments prospectively. Define segments before assignment and analyze post-treatment answers as outcomes.
FAQ
Is zero-party data the same as first-party data?
No. It is commonly a subset of first-party data: intentionally stated information rather than all data collected in a direct relationship.
Is a survey answer always zero-party data?
It is usually intentionally provided, but its appropriate use still depends on the question, context, scope, and applicable rules.
Can we infer skipped answers from behavior?
That creates inferred data, which should be labeled and governed separately from the person’s stated preference.
Can preference data personalize an A/B test?
Yes, when the preference existed before assignment and the experiment defines eligibility, randomization, and analysis clearly.
Why retain the question version?
Different wording, option order, or interface context can change what an answer means and whether versions can be compared.
Summary
Zero-party data is intentionally provided preference or intent information. It can create more relevant experiences when collected for a clear benefit, stored with provenance, kept current, and limited to the appropriate purpose. It is neither permanent truth nor blanket permission. In experiments, define preference segments before assignment and account for respondent and nonrespondent differences.
Sources
- NIST Privacy Framework
- OECD Privacy Guidelines
- UK Information Commissioner’s Office guidance on data protection by design