Zero party data : collecter et activer sans casser la conformité

La donnée déclarative, celle que le client vous donne volontairement en répondant à une question, est le seul signal que ni un blocage de cookie ni un changement d'algorithme ne peut vous retirer. Sur le papier, tout le monde est d'accord. En audit, le constat est presque toujours le même : des marques ont posé un quiz ou un champ « date de naissance » dans un pop-up, la donnée arrive quelque part dans le CRM, et elle n'est jamais utilisée dans un seul segment ni dans un seul bloc conditionnel.

Le problème n'est pas la collecte. C'est la chaîne complète : nommage, stockage, identifiant, consentement, activation. Cet article détaille cette chaîne pour une marque DTC sur Klaviyo, avec les limites techniques réelles documentées par l'éditeur et le cadre CNIL applicable en France.

Précision de méthode : le terme « zero party data » n'a pas de définition normative publiée par les éditeurs cités ici. Dans cet article, il désigne simplement la donnée que le contact déclare lui-même, par opposition aux données comportementales que vous observez. Sur la partie observée, nous avons déjà traité la collecte et l'activation dans first-party data e-commerce.

Ce que vous collectez vraiment, et ce que ça coûte de le demander

Avant d'ouvrir l'éditeur de formulaire, posez une règle simple : chaque question posée doit avoir un usage d'activation déjà écrit. Pas « ça pourra servir ». Un segment, un bloc dynamique, un split de flow, une exclusion. Si personne dans l'équipe ne sait dire ce que la réponse déclenchera, la question dégrade le taux de complétion sans contrepartie.

Les familles de données déclaratives qui s'activent réellement chez une marque DTC :

• Préférence produit ou catégorie : peau sèche vs peau mixte, running vs trail, café filtre vs espresso. Elle alimente les blocs dynamiques et la recommandation éditoriale.
• Intention d'achat : pour moi, pour offrir, en test. Elle change radicalement le contenu du welcome flow.
• Contexte temporel : date d'anniversaire, date d'un événement (rentrée, mariage, naissance). Elle alimente un flow date-based.
• Préférence de fréquence et de canal : combien d'emails, email ou SMS. Elle réduit mécaniquement la pression subie.
• Niveau d'expertise ou de maturité : débutant, confirmé. Elle pilote le ton et la profondeur du contenu.

Sur l'arbitrage canal une fois la préférence connue, nous détaillons la logique dans SMS ou email : quel message mérite quel canal.

Ce qu'aucune documentation ouverte ne permet d'affirmer : l'impact chiffré du nombre de champs sur le taux de complétion, ou l'uplift de revenu attribuable à la donnée déclarative. Les éditeurs ne publient pas de benchmark sur ce point. Décidez donc par test sur votre propre base, pas par chiffre de conférence.

Comment Klaviyo stocke la donnée déclarative

C'est le point que la plupart des équipes découvrent trop tard. Dans Klaviyo, la mécanique native est simple : tout champ supplémentaire ajouté à un formulaire d'inscription ou à une subscribe page est stocké comme propriété personnalisée de profil. C'est écrit noir sur blanc dans la documentation Klaviyo sur les propriétés de profil : « Any additional fields you add to a subscribe page or sign-up form will be collected as custom properties. »

Il n'y a pas d'objet séparé, pas de table de réponses. Votre quiz produit une collection de custom properties, exactement comme un import CSV ou un push API.

Quelques contraintes structurelles à connaître avant de dessiner votre modèle de données :

L'absence de plafond sur le nombre de propriétés est une bonne nouvelle et un piège. Bonne nouvelle : vous pouvez modéliser finement. Piège : sans gouvernance, un compte accumule en dix-huit mois des dizaines de propriétés à moitié remplies, dont personne ne sait plus laquelle est la référence. La règle d'agence : une propriété ne se crée pas sans propriétaire ni sans usage écrit.

La convention de nommage n'est pas un détail esthétique

Klaviyo est explicite sur ce point : si une propriété personnalisée porte le même nom qu'une propriété native du compte, vous ne pourrez pas segmenter dessus. La documentation sur les propriétés spéciales le formule ainsi : « 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. »

Autrement dit, un mauvais nom rend la donnée invisible en activation. Vous collectez, vous stockez, et vous ne pouvez rien en faire. C'est le mode d'échec le plus fréquent et le plus coûteux, parce qu'il est silencieux : rien ne casse, la donnée s'accumule, et le segment renvoie zéro.

Une convention qui tient dans le temps :

• Un préfixe de source ou de domaine : pref_, quiz_, decl_.
• Un nom explicite en snake_case ou en libellé stable : pref_type_peau, quiz_objectif_principal.
• Jamais de nom qui frôle une propriété native (email, phone_number, location, first_name).
• Des valeurs normalisées et fermées : sec, mixte, grasse. Pas de saisie libre quand un choix suffit.

Pour le détail des champs natifs disponibles et de leur comportement en segmentation, référez-vous à Klaviyo segmentation fields et à notre guide Klaviyo custom properties.

Les cinq pièges de configuration du formulaire

La documentation Klaviyo sur les formulaires multi-étapes et les champs de saisie décrit plusieurs comportements qui expliquent, à eux seuls, la majorité des collectes qui ne remontent jamais.

1. Sans identifiant, rien n'est enregistré. Klaviyo est clair : les formulaires ne peuvent pas tracker un visiteur anonyme. Si quelqu'un remplit une étape mais ne fournit jamais d'email ou de téléphone, ses réponses ne seront pas disponibles dans votre compte (documentation multi-step forms). Conséquence directe sur l'ordre des étapes : la capture de l'identifiant passe en premier, les questions déclaratives ensuite. Un quiz qui demande l'email à la dernière étape perd toutes les réponses des abandons.

2. Le bouton de l'étape Profile Information doit être en Submit form. Toujours selon la même page : le bouton d'une étape Profile Information doit avoir son action réglée sur « Submit form », sinon les propriétés ne sont pas enregistrées sur le profil. C'est une case à vérifier dans chaque formulaire à étapes multiples, à chaque modification.

3. Chaque champ doit être rattaché à une propriété. La documentation sur les champs de formulaire le pose comme une obligation : tous les champs de saisie doivent être connectés à une propriété de profil, qui stocke la donnée soumise. Et un formulaire ne peut contenir qu'un seul champ email.

4. Les hidden fields écrasent l'existant. Toujours sur la même page : si vous ajoutez des champs cachés pour des propriétés déjà présentes sur le profil, elles seront écrasées par la nouvelle valeur à la soumission. Utile pour tracer la source de collecte (source_collecte = quiz_diagnostic), dangereux si vous y mettez une valeur générique qui va effacer une donnée plus riche déjà connue.

5. Une deuxième soumission remplace la première. Si un contact remplit deux fois le même formulaire, seule la réponse la plus récente est conservée (documentation Klaviyo). Ce comportement est logique pour une préférence qui évolue. Il devient un problème si vous comptiez sur l'historique des réponses pour analyser une évolution : dans ce cas, il faut passer par un événement custom, pas par une propriété. Le principe d'envoi d'événements depuis votre stack est détaillé dans API Klaviyo : envoyer des events.

Sur la conception du formulaire lui-même, le placement et les mécaniques d'incitation, notre article inscription newsletter : pop-up et formulaire efficaces couvre le sujet en détail.

Le cadre CNIL : ce que la collecte déclarative impose

La donnée déclarative est souvent présentée comme la voie propre du point de vue de la vie privée. Elle l'est en principe, mais elle ne dispense d'aucune obligation.

Une finalité, un consentement. La CNIL rappelle qu'un consentement doit correspondre à un seul traitement, pour une finalité déterminée. Traduction opérationnelle pour un centre de préférences : consentir à la newsletter et consentir au SMS sont deux actes distincts. Un centre de préférences qui regroupe tout derrière une case unique ne produit pas un consentement valide.

Pas de case pré-cochée, pas de consentement groupé. Toujours selon la CNIL, le consentement doit être donné par une déclaration ou tout autre acte positif clairs. Les cases pré-cochées sont donc à proscrire, y compris quand elles simplifient joliment le parcours.

La preuve doit exister. Le responsable de traitement doit être en mesure de démontrer à tout moment que la personne a bien consenti. En pratique, cela veut dire tracer la source et la date de collecte sur le profil. Deux propriétés supplémentaires, systématiquement remplies via des hidden fields : source_collecte et le contexte de collecte. Le timestamp d'inscription est déjà présent nativement dans Klaviyo, mais la source du consentement, elle, ne se devine pas.

Si vous partagez avec des partenaires, la liste doit être accessible. Pour la prospection B2C avec transmission à des partenaires, la CNIL exige que les personnes soient clairement informées de l'identité des partenaires, et qu'une liste exhaustive et mise à jour soit mise à leur disposition. Le modèle proposé par la CNIL tient en une case à cocher, décochée par défaut, formulée ainsi : « J'accepte que mon adresse électronique soit transmise aux partenaires [lien] de la société X à des fins de prospection commerciale par courrier électronique. »

Deux zones que les pages CNIL ouvertes ne tranchent pas et sur lesquelles nous ne donnons pas de réponse chiffrée : la durée de conservation applicable aux données de prospection collectées dans ce cadre, et l'articulation précise entre consentement et intérêt légitime pour la personnalisation à partir de données déclaratives. Sur ces deux points, l'arbitrage se fait avec votre DPO, en s'appuyant directement sur les publications de la CNIL. Pour le socle général, notre checklist RGPD email marketing 2026 reprend les obligations applicables aux envois.

Activer : trois usages qui justifient la collecte

Une donnée déclarative non activée est une dette, pas un actif. Voici les trois usages qui rentabilisent la collecte le plus vite.

Le split de welcome flow

C'est l'application la plus directe. Une préférence collectée à l'inscription change immédiatement le contenu de la séquence : produit mis en avant, preuve sociale choisie, offre d'entrée. Le premier email envoyé après une question posée doit démontrer que la réponse a été lue, sinon le contact conclut que remplir un formulaire ne sert à rien et ne le refera plus. La structure de base de la séquence est détaillée dans welcome flow Klaviyo.

Les blocs conditionnels en campagne

Plutôt que de multiplier les variantes d'une campagne, un seul email avec des blocs conditionnels sur la propriété déclarée fait le travail. La condition se pose sur la valeur normalisée de la propriété, ce qui suppose des valeurs fermées décidées en amont. Le fonctionnement des blocs et des variables est couvert dans dynamic content Klaviyo.

La pression et la fréquence

La préférence de fréquence déclarée est la donnée la plus sous-exploitée. Elle sert à construire des exclusions de campagne, pas seulement à afficher un choix dans un centre de préférences. Un contact qui a demandé « une fois par mois » et qui reçoit trois emails par semaine se désabonne, et le compte perd un contact engagé. Notre article sur réduire le taux de désabonnement détaille les leviers associés.

Ce qui change selon la plateforme

La mécanique de stockage n'est pas identique partout, et cela influence le modèle de données que vous pouvez construire.

Chez Braze, la documentation sur les types de données pose des limites précises : une valeur texte de custom attribute est plafonnée à 255 caractères, un attribut de type tableau est limité à 100 Ko et conserve par défaut 500 éléments, les plus anciens étant éliminés au profit des plus récents. Un objet de propriétés d'événement contenant des tableaux ou des objets peut atteindre 102 400 octets (100 KiB). La contrainte des 255 caractères sur le texte est structurante : une réponse ouverte longue ne tient pas dans un attribut texte. Nous comparons les deux plateformes dans Braze vs Klaviyo.

Chez Customer.io, la documentation sur les attributs indique que l'identifiant d'une personne est limité par défaut à 150 caractères. Le nombre maximal d'attributs par personne n'est pas chiffré sur cette page. La comparaison des deux usages est traitée dans Klaviyo vs Customer.io.

Côté Shopify, les metafields permettent d'étendre le modèle de données natif, y compris sur l'objet client, avec des données personnalisées. C'est le point de stockage naturel quand la donnée déclarative doit vivre côté boutique, pas seulement côté ESP. Les limites chiffrées de ces metafields ne figurent pas sur la page du Help Center consultée, donc vérifiez-les directement dans la documentation Shopify avant de dimensionner un projet.

Pour Brevo, la page d'aide relative aux attributs de contact n'était pas accessible lors de notre vérification. Nous ne publions donc aucun chiffre de limite pour cette plateforme : vérifiez dans votre compte ou auprès du support. Le reste du paramétrage est couvert dans notre checklist de mise en place Brevo.

Checklist de mise en place

À dérouler dans cet ordre, avant toute publication de formulaire.

1. Lister les questions et écrire, pour chacune, le segment ou le bloc qu'elle alimentera. Supprimer celles sans usage.
2. Figer les valeurs possibles de chaque propriété. Choix fermés, libellés stables, pas de saisie libre quand une liste suffit.
3. Vérifier qu'aucun nom de propriété ne collide avec une propriété native du compte.
4. Placer la capture de l'identifiant (email ou téléphone) avant les questions déclaratives.
5. Sur chaque étape Profile Information, régler l'action du bouton sur Submit form.
6. Ajouter des hidden fields de traçabilité (source de collecte), en vérifiant qu'aucun n'écrase une donnée déjà présente.
7. Séparer les consentements par finalité, décochés par défaut.
8. Tester en conditions réelles avec une adresse neuve, puis vérifier le profil créé propriété par propriété.
9. Construire les segments d'activation avant de lancer la collecte, pas après.
10. Programmer une revue trimestrielle des propriétés : taux de remplissage, usage réel, suppression des orphelines.

Le point 9 est celui qu'on saute le plus souvent. Un formulaire lancé sans son segment d'activation collecte pendant des mois une donnée que personne n'utilise, et l'équipe conclut que la donnée déclarative ne sert à rien.

Le mode d'échec le plus fréquent

En audit, le schéma se répète : la marque a un quiz, il tourne, il capture. Puis on ouvre le générateur de segments et on cherche la propriété. Elle est là, mais avec trois orthographes différentes selon la vague de collecte, la moitié des profils l'ont vide, et personne ne sait si la valeur affichée est la première ou la dernière réponse donnée. La collecte a fonctionné, la gouvernance non.

La donnée déclarative se travaille comme une base de données, pas comme une campagne. Un schéma décidé avant la première soumission, des noms figés, des valeurs normalisées, une trace de source. Si vous voulez un cadrage complet du dispositif sur votre compte, notre agence Klaviyo traite ce chantier en même temps que la refonte des flows et de la segmentation, parce que les deux ne se séparent pas.

FAQ

Quelle différence entre zero party data et first party data ?

La donnée déclarative est celle que le contact vous transmet volontairement en répondant à une question. La first party data recouvre plus largement ce que vous observez sur vos propres canaux : navigation, achats, ouvertures. Aucun éditeur cité ici ne publie de définition normative du terme « zero party data », il s'agit d'un vocabulaire de marché. Nous détaillons la partie observée dans first-party data e-commerce.

Combien de questions poser dans un formulaire d'inscription ?

Aucune documentation ouverte ne chiffre l'impact du nombre de champs sur le taux de complétion, donc la réponse se teste sur votre base. La contrainte technique documentée par Klaviyo est en revanche claire : un formulaire accepte au maximum 4 pages, plus un message de succès optionnel. Le critère de décision reste l'usage : une question sans segment ou bloc associé se supprime.

Où stocker la donnée déclarative dans Klaviyo ?

Dans les propriétés personnalisées de profil : c'est le mécanisme natif, tout champ ajouté à un formulaire y atterrit. Klaviyo ne limite pas le nombre de propriétés par profil, mais plafonne chaque propriété à 100 Ko. Si vous avez besoin de conserver l'historique des réponses successives plutôt que la dernière valeur, passez par un événement custom.

Faut-il un consentement séparé pour chaque préférence collectée ?

Pour chaque finalité de traitement, oui. La CNIL indique qu'un consentement doit correspondre à un seul traitement, pour une finalité déterminée, et qu'il doit résulter d'un acte positif clair, ce qui exclut les cases pré-cochées. Un centre de préférences doit donc permettre de consentir séparément à chaque canal ou usage.

Que se passe-t-il si un contact remplit deux fois le même formulaire ?

Klaviyo ne conserve que la réponse la plus récente. C'est cohérent pour une préférence qui évolue, mais cela signifie que vous perdez l'historique. Si l'évolution des réponses a une valeur analytique pour vous, envoyez la réponse sous forme d'événement en plus de la propriété de profil.