Zero-Party Data: Collect and Activate It Without Compliance Risk

Declared data, the kind a customer hands you voluntarily by answering a question, is the one signal that no cookie block and no algorithm change can take away from you. On paper, everyone agrees. In audits, the finding is almost always the same: a brand adds a quiz or a "date of birth" field to a pop-up, the data lands somewhere in the CRM, and it never ends up powering a single segment or a single conditional block.

The problem is not collection. It is the whole chain: naming, storage, identifier, consent, activation. This article breaks down that chain for a DTC brand on Klaviyo, with the real technical limits documented by the vendors and the CNIL framework that applies to companies operating in France.

A note on terms: the phrase "zero-party data" has no normative definition published by the vendors cited here. In this article it simply means data a contact declares about themselves, as opposed to behavioral data you observe. We already covered the observed side, collection and activation, in ecommerce first-party data.

What you are really collecting, and what it costs to ask for it

Before opening the form builder, set one rule: every question you ask must already have a written activation use case. Not "it might be useful someday." A segment, a dynamic block, a flow split, an exclusion. If nobody on the team can say what the answer will trigger, the question just drags down your completion rate for nothing.

The declared-data families that actually get activated at a DTC brand:

• Product or category preference: dry skin vs. combination skin, running vs. trail, drip coffee vs. espresso. Feeds dynamic blocks and editorial recommendations.
• Purchase intent: for myself, as a gift, trying it out. Radically changes welcome flow content.
• Time-based context: birthday, an event date (back-to-school, wedding, birth). Feeds a date-based flow.
• Frequency and channel preference: how many emails, email or SMS. Mechanically reduces the pressure a contact feels.
• Expertise or maturity level: beginner, advanced. Drives tone and content depth.

On the channel trade-off once you know the preference, we cover the logic in SMS or email: which message deserves which channel.

What no open documentation lets us state: the measured impact of field count on completion rate, or the revenue uplift attributable to declared data. Vendors do not publish a benchmark on this. Decide by testing on your own list, not on a conference slide figure.

How Klaviyo stores declared data

This is the point most teams discover too late. In Klaviyo, the native mechanism is simple: any extra field added to a sign-up form or subscribe page is stored as a profile custom property. Klaviyo's documentation on profile properties states it plainly: "Any additional fields you add to a subscribe page or sign-up form will be collected as custom properties."

There is no separate object, no response table. Your quiz produces a collection of custom properties, exactly like a CSV import or an API push.

A few structural constraints worth knowing before you design your data model:

No cap on the number of properties is both good news and a trap. Good news: you can model finely. Trap: without governance, an account accumulates dozens of half-filled properties over eighteen months, and nobody remembers which one is the source of truth. The agency rule: a property does not get created without an owner and a written use case.

Naming conventions are not a cosmetic detail

Klaviyo is explicit on this: if a custom property shares a name with a native property on your account, you will not be able to segment on it. The documentation on special properties puts it this way: "If a profile property has the same name as a Klaviyo property on your account, you will not be able to segment on that custom property."

In other words, a bad name makes the data invisible at activation time. You collect it, you store it, and you can do nothing with it. It is the most common and most costly failure mode, because it is silent: nothing breaks, the data piles up, and the segment returns zero.

A naming convention that holds up over time:

• A source or domain prefix: pref_, quiz_, decl_.
• An explicit name in snake_case or a stable label: pref_skin_type, quiz_main_goal.
• Never a name close to a native property (email, phone_number, location, first_name).
• Normalized, closed-choice values: dry, combination, oily. No free text when a picklist will do.

For the full list of available native fields and how they behave in segmentation, see Klaviyo segmentation fields and our guide to Klaviyo custom properties.

The five form configuration traps

Klaviyo's documentation on multi-step forms and input fields describes several behaviors that, on their own, explain most of the declared data that never shows up.

1. Without an identifier, nothing is saved. Klaviyo is clear: forms cannot track an anonymous visitor. If someone fills out a step but never provides an email or phone number, their answers will not be available in your account (multi-step forms documentation). This has a direct consequence on step order: capture the identifier first, ask declared-data questions after. A quiz that asks for email on the last step loses every response from people who abandon before then.

2. The Profile Information step's button must be set to Submit form. Per the same page: a Profile Information step's button action must be set to "Submit form," otherwise properties are not saved to the profile. It is a checkbox to verify on every multi-step form, every time it is edited.

3. Every field must be mapped to a property. The documentation on form fields states it as a requirement: every input field must be connected to a profile property that stores the submitted data. And a form can only contain a single email field.

4. Hidden fields overwrite existing values. Still on the same page: if you add hidden fields for properties already present on the profile, they will be overwritten by the new value on submission. Useful for tracking collection source (collection_source = diagnostic_quiz), dangerous if you put a generic value there that wipes out a richer value already on file.

5. A second submission replaces the first. If a contact fills out the same form twice, only the most recent answer is kept (Klaviyo documentation). This behavior makes sense for a preference that changes over time. It becomes a problem if you were counting on the response history to analyze a change: in that case, use a custom event, not a property. The principle of sending events from your own stack is detailed in Klaviyo Events API.

On the form design itself, placement and incentive mechanics, our article email pop-up and signup form strategy covers the topic in depth.

The CNIL framework: what declared collection requires

Declared data is often presented as the privacy-friendly path. It is, in principle, but it does not exempt you from any obligation. This applies to companies operating in France.

One purpose, one consent. The CNIL states that consent must correspond to a single processing activity, for a specific purpose. In operational terms for a preference center: consenting to the newsletter and consenting to SMS are two separate acts. A preference center that bundles everything behind one checkbox does not produce valid consent.

No pre-checked boxes, no bundled consent. Also per the CNIL, consent must be given through a clear statement or another clear affirmative act. Pre-checked boxes are therefore off the table, even when they neatly simplify the flow.

Proof must exist. The data controller must be able to demonstrate at any time that the person actually consented. In practice, this means logging the source and date of collection on the profile. Two additional properties, systematically filled via hidden fields: collection_source and the collection context. The sign-up timestamp is already native in Klaviyo, but the source of consent is not something you can guess.

If you share data with partners, the list must be accessible. For B2C prospecting involving data transfer to partners, the CNIL requires that people be clearly informed of the partners' identities, and that a complete, up-to-date list be made available to them. The model wording the CNIL proposes fits in a single checkbox, unchecked by default, worded as: "I agree that my email address be shared with the [link] partners of company X for commercial email prospecting purposes."

Two areas the CNIL pages we opened do not settle, and on which we give no numeric answer: the retention period applicable to prospecting data collected under this framework, and the precise line between consent and legitimate interest for personalization built from declared data. On both points, the call is made with your DPO, working directly from CNIL publications. For the general baseline, our GDPR email marketing checklist covers the obligations that apply to sends.

Activating it: three uses that justify the collection

Declared data that is never activated is a liability, not an asset. Here are the three uses that pay back the collection fastest.

The welcome flow split

This is the most direct application. A preference collected at sign-up immediately changes the sequence content: featured product, chosen social proof, entry offer. The first email sent after a question is asked must prove the answer was read, otherwise the contact concludes that filling out a form is pointless and won't do it again. The base structure of the sequence is detailed in Klaviyo welcome flow.

Conditional blocks in campaigns

Rather than multiplying campaign variants, a single email with conditional blocks tied to the declared property does the job. The condition is set on the property's normalized value, which assumes closed values decided upfront. How blocks and variables work is covered in Klaviyo dynamic content.

Pressure and frequency

Declared frequency preference is the most underused piece of data. It should build campaign exclusions, not just display a choice in a preference center. A contact who asked for "once a month" and gets three emails a week unsubscribes, and the account loses an engaged contact. Our article on reducing email unsubscribe rate details the related levers.

What changes by platform

Storage mechanics are not identical everywhere, and that shapes the data model you can build.

At Braze, the documentation on data types sets precise limits: a text-value custom attribute is capped at 255 characters, an array-type attribute is limited to 100 KB and keeps 500 items by default, with the oldest dropped in favor of the newest. An event properties object containing arrays or objects can reach 102,400 bytes (100 KiB). The 255-character text limit is a structuring constraint: a long open-ended answer does not fit in a text attribute. We compare the two platforms in Braze vs. Klaviyo.

At Customer.io, the documentation on attributes states that a person's identifier is limited to 150 characters by default. The maximum number of attributes per person is not quantified on this page. The comparison of the two use cases is covered in Klaviyo vs. Customer.io.

On Shopify, metafields let you extend the native data model, including on the customer object, with custom data. It is the natural storage point when declared data needs to live on the store side rather than the ESP side. The numeric limits for these metafields are not stated on the Help Center page consulted, so verify them directly in Shopify's documentation before sizing a project.

For Brevo, the help page on contact attributes was not accessible at the time of our check. We therefore publish no limit figures for that platform: verify in your own account or with support. The rest of the setup is covered in our Brevo setup checklist.

Setup checklist

Run through this order before publishing any form.

1. List the questions and write down, for each one, the segment or block it will feed. Delete any without a use case.
2. Lock down the possible values for each property. Closed choices, stable labels, no free text where a list will do.
3. Check that no property name collides with a native property on the account.
4. Place identifier capture (email or phone) before declared-data questions.
5. On every Profile Information step, set the button action to Submit form.
6. Add tracking hidden fields (collection source), checking that none overwrite existing data.
7. Separate consents by purpose, unchecked by default.
8. Test under real conditions with a fresh address, then check the created profile property by property.
9. Build activation segments before launching collection, not after.
10. Schedule a quarterly review of properties: fill rate, actual usage, removal of orphans.

Point 9 is the one most often skipped. A form launched without its activation segment collects data for months that nobody uses, and the team concludes that declared data is worthless.

The most common failure mode

In audits, the pattern repeats: the brand has a quiz, it runs, it captures data. Then you open the segment builder and look for the property. It is there, but spelled three different ways depending on the collection wave, half the profiles have it empty, and nobody knows whether the value shown is the first or the last answer given. Collection worked. Governance did not.

Declared data has to be treated like a database, not a campaign. A schema decided before the first submission, fixed names, normalized values, a trace of source. If you want a full audit of this setup on your account, our Klaviyo agency handles this project alongside flow and segmentation rebuilds, because the two cannot be separated.

FAQ

What is the difference between zero-party data and first-party data?

Declared data is what a contact volunteers by answering a question. First-party data more broadly covers what you observe across your own channels: browsing, purchases, opens. No vendor cited here publishes a normative definition of "zero-party data"; it is market vocabulary. We cover the observed side in ecommerce first-party data.

How many questions should a sign-up form ask?

No open documentation quantifies the impact of field count on completion rate, so the answer has to be tested on your own list. The documented technical constraint from Klaviyo is clear, though: a form accepts a maximum of 4 pages, plus an optional success message. The decision criterion remains usage: a question with no associated segment or block gets removed.

Where does declared data get stored in Klaviyo?

In profile custom properties: it is the native mechanism, every field added to a form lands there. Klaviyo does not limit the number of properties per profile, but caps each property at 100 KB. If you need to keep a history of successive answers rather than just the latest value, use a custom event instead.

Do I need separate consent for every preference collected?

For every processing purpose, yes. The CNIL states that consent must correspond to a single processing activity, for a specific purpose, and must result from a clear affirmative act, which rules out pre-checked boxes. A preference center must therefore allow separate consent for each channel or use.

What happens if a contact fills out the same form twice?

Klaviyo keeps only the most recent answer. That is consistent for a preference that changes over time, but it means you lose the history. If the evolution of answers has analytical value for you, send the answer as an event in addition to the profile property.

Need a full audit of your declared-data setup? Talk to the Deliver team.