Klaviyo custom properties : enrichir ses profils pour une segmentation avancée

Klaviyo stocke par défaut des informations basiques sur chaque contact : email, prénom, nom, numéro de téléphone, ville. C'est suffisant pour envoyer un email. Ce n'est pas suffisant pour personnaliser.

Les custom properties (propriétés personnalisées) sont ce qui permet de passer d'une liste plate à une base de données client exploitable. Programme de fidélité, préférences produit, type de peau, date d'anniversaire, statut d'abonnement : tout ce qui caractérise un client et ne rentre pas dans les champs natifs peut y trouver sa place.

Ce guide explique comment les utiliser concrètement, de la collecte à la segmentation.

TL;DR

• Les custom properties Klaviyo supportent les types string, number, boolean, datetime et list (tableaux) ainsi que des objets JSON imbriqués
• La limite technique est de 100 Ko par profil (payload total), sans cap sur le nombre de propriétés distinctes
• On les peuple via 4 canaux : API REST, klaviyo.js (côté front), intégrations natives Shopify, et formulaires Klaviyo
• En segmentation, les opérateurs disponibles varient selon le type : equals, contains, starts with, greater than, less than, is set, is not set, entre autres
• Les custom properties sont utilisables dans les segments statiques, les flow filters et les conditional splits
• La distinction clé avec les event properties : les custom properties persistent sur le profil, les event properties sont attachées à un moment précis
• Bien structurées, elles permettent de multiplier la pertinence des flows sans multiplier le nombre de listes

Introduction

Un profil Klaviyo sans custom properties ressemble à une fiche client avec seulement un nom et une adresse. Vous savez que la personne existe. Vous ne savez pas pourquoi elle achète, ce qu'elle préfère, ni à quel stade de sa relation avec votre marque elle se trouve.

Les custom properties changent cette équation. Elles permettent d'écrire sur le profil tout ce que votre site sait d'un visiteur ou d'un acheteur : ses préférences déclarées (via un quiz ou un formulaire), ses comportements accumulés (nombre de commandes, catégories achetées, montant total dépensé), ou ses caractéristiques métier (taille de vêtement, type de peau, fréquence d'achat attendue).

Une fois ces données sur le profil, Klaviyo peut les lire partout : dans les segments, dans les conditions de flows, dans les conditional splits, et dans les templates via les balises de personnalisation.

Les types de custom properties

Klaviyo supporte plusieurs types de données. Le système détecte automatiquement le type selon la valeur envoyée, mais il est important de rester cohérent sur la façon de formater ses données pour éviter les conflits.

Limite technique officielle : le payload total d'un profil (identifiants, champs natifs et custom properties combinés) ne peut pas dépasser 100 Ko. Il n'existe pas de limite documentée sur le nombre de propriétés distinctes. En pratique, un profil bien structuré reste largement sous ce plafond.

Note importante sur les arrays et les objets : les listes (list) sont utilisables en segmentation avec des opérateurs spécifiques (contains). Les objets imbriqués sont stockés mais leur utilisation en segmentation est limitée : Klaviyo peut accéder aux propriétés de premier niveau, mais la navigation dans des objets profondément imbriqués peut ne pas fonctionner dans tous les contextes. Préférez des propriétés à plat quand la segmentation est l'objectif principal.

Comment peupler ses custom properties : 4 méthodes

1. L'API REST Klaviyo (côté serveur)

C'est la méthode la plus complète et la plus fiable. L'API Profiles de Klaviyo permet de créer ou mettre à jour un profil avec un objet properties contenant n'importe quelle clé-valeur.

POST https://a.klaviyo.com/api/profiles

{
  "data": {
    "type": "profile",
    "attributes": {
      "email": "client@example.com",
      "properties": {
        "programme_fidelite": "Gold",
        "nombre_commandes": 7,
        "categorie_preferee": "sneakers",
        "date_anniversaire": "1990-06-15T00:00:00+00:00",
        "accepte_sms": true
      }
    }
  }
}

Cette approche est idéale pour les synchronisations batch (mise à jour quotidienne depuis votre CRM ou ERP), les intégrations post-commande, et les données calculées côté back-end (LTV, nombre de commandes, score d'engagement).

Si le profil existe déjà, l'API fusionne les propriétés : les clés présentes dans la requête sont mises à jour, les autres restent intactes. Pour effacer une propriété, envoyez null comme valeur.

2. Klaviyo.js côté front (identify)

Pour les données collectées directement dans le navigateur, la méthode klaviyo.identify() permet d'écrire des custom properties dès qu'un visiteur identifié interagit avec le site.

klaviyo.identify({
  'email': 'client@example.com',
  'type_peau': 'mixte',
  'taille_vetement': 'M',
  'quiz_complete': true,
  'derniere_categorie_visitee': 'soin-visage'
});

Cette méthode est particulièrement utile après un quiz produit, une page de préférences, ou un configurateur. L'avantage : la propriété est écrite immédiatement sur le profil, sans passer par un serveur intermédiaire.

Attention : klaviyo.js s'exécute côté client. Ne jamais y inclure de données sensibles ou calculées que l'utilisateur ne devrait pas pouvoir manipuler (niveau de fidélité, LTV, statut VIP).

3. Intégration Shopify native

L'intégration Shopify de Klaviyo synchronise automatiquement plusieurs propriétés sur les profils :

Les tags client Shopify sont particulièrement utiles : si vous taguez vos clients VIP, programme-fidelite-actif ou revendeur directement depuis Shopify ou votre service client, ces tags remontent automatiquement dans Klaviyo et peuvent être utilisés en segmentation.

Pour des propriétés qui ne font pas partie des champs natifs Shopify (pointure, type de morphologie, préférence de livraison), il faut passer par l'API ou Klaviyo.js.

4. Formulaires Klaviyo

Les formulaires natifs Klaviyo (popups, embeds, fly-outs) permettent de collecter des custom properties directement depuis le front, sans développement.

Dans le constructeur de formulaire, chaque champ peut être associé à une custom property de profil. Exemple : un champ "Type de peau" avec les options sèche, grasse, mixte, normale écrira la valeur choisie directement sur la propriété type_peau du profil.

C'est la méthode la plus accessible pour les équipes sans ressources techniques. Idéale pour les préférences déclarées, les centres d'intérêt, et les données de segmentation de base collectées à l'inscription.

Custom properties vs event properties : quand utiliser quoi

C'est l'une des confusions les plus fréquentes chez les équipes qui débutent sur Klaviyo.

Les custom properties sont des attributs du profil. Elles décrivent qui est le contact : son statut, ses préférences, ses caractéristiques. Elles persistent dans le temps et s'écrasent à chaque mise à jour.

Les event properties sont des attributs d'un événement. Elles décrivent ce qui s'est passé à un moment précis : qu'est-ce qui a été acheté, quel produit a été consulté, quel email a été ouvert. Elles sont attachées à l'événement et ne changent pas rétroactivement.

Règle pratique : si la donnée décrit l'état actuel du client, c'est une custom property. Si elle décrit quelque chose qui s'est passé (et dont on veut garder l'historique), c'est une event property.

Pour la segmentation basée sur le comportement (a acheté dans la catégorie X, a visité la page Y), les event properties sont plus pertinentes car elles conservent l'historique complet. Pour la personnalisation statique (taille de vêtement, préférence de genre, statut d'abonné), les custom properties sont plus simples à exploiter.

Segmentation et flows : exploiter ses données

Dans les segments

Klaviyo expose les custom properties dans le constructeur de segments sous la condition "Properties about someone". Les opérateurs disponibles varient selon le type de la propriété :

Exemple : pour cibler tous les membres Gold de votre programme de fidélité actifs depuis plus de 90 jours, combinez programme_fidelite equals Gold ET date_adhesion is more than 90 days ago.

Dans les flow filters

Les flow filters s'appliquent au moment où un contact entre dans un flow. Toutes les custom properties sont disponibles avec les mêmes opérateurs qu'en segmentation. Cela permet de restreindre un flow à un sous-ensemble de contacts sans créer un segment dédié.

Exemple courant : un flow de réactivation qui s'exclut automatiquement si statut_abonnement equals actif. Inutile de relancer un client qui est déjà abonné à votre service.

Dans les conditional splits

Les conditional splits permettent de brancher le flow selon la valeur d'une custom property au moment où le contact atteint ce point. C'est l'outil le plus puissant pour la personnalisation dans les flows.

Exemple : dans un post-purchase flow, un conditional split sur programme_fidelite envoie un email différent aux membres Gold (cross-sell premium) et aux membres Silver (invitation à monter de niveau). Pour approfondir la logique des flows, consultez notre article sur Klaviyo Flows vs Campaigns.

Cas d'usage concrets en e-commerce

Pour aller plus loin sur la logique de segmentation comportementale, notre article sur la segmentation Klaviyo détaille comment combiner custom properties et event conditions.

Pièges à éviter

Incohérence de nommage. Si vous envoyez tantôt programme_fidelite, tantôt ProgrammeFidelite, tantôt programme fidelite (avec espace), Klaviyo crée trois propriétés distinctes. Le résultat : des segments incomplets et des données dispersées. Définissez une convention de nommage dès le départ (snake_case recommandé) et documentez-la.

Écraser des données utiles. Quand vous mettez à jour un profil via l'API, seules les propriétés incluses dans la requête sont modifiées. Mais si vous reconstruisez l'objet propriétés côté serveur sans inclure toutes les valeurs existantes, vous risquez d'écraser des données que vous n'aviez pas l'intention de toucher. Toujours faire des mises à jour partielles (patch) plutôt que des remplacements complets.

Stocker des données volatiles en custom property. Le panier actuel d'un client, le produit vu il y a 5 minutes, ou le coupon en cours d'application : ces données changent trop vite pour être des custom properties. Utilisez les event properties pour capturer ce type d'informations à un instant T.

Dates mal formatées. Les datetime doivent être au format ISO 8601 (2025-06-15T00:00:00+00:00). Une date envoyée en format français (15/06/2025) sera stockée comme une string et les opérateurs de date ne fonctionneront pas en segmentation.

Accumuler des propriétés inutilisées. Chaque custom property créée alourdit la lecture du profil et peut rendre la segmentation confuse pour les équipes. Faites un audit régulier : si une propriété n'est utilisée dans aucun segment ni aucun flow depuis 6 mois, supprimez-la ou archivez-la.

Segmenter sur des objets imbriqués complexes. Les structures JSON imbriquées sur plusieurs niveaux sont stockées correctement, mais les opérateurs de segmentation Klaviyo ne peuvent pas toujours y naviguer finement. Si vous avez besoin de segmenter sur une valeur précise, remontez-la à plat en tant que propriété distincte.

Pour aller plus loin

Les custom properties sont la fondation d'une stratégie email véritablement personnalisée. Elles ne servent à rien si elles restent dans les profils sans être exploitées dans des segments actifs ou des flows bien construits.

Quelques ressources complémentaires pour aller au bout de la démarche :

• Segmentation avancée : notre article sur la segmentation Klaviyo et les conditions avancées montre comment combiner propriétés de profil et comportements
• Utiliser les données dans les flows : voir Klaviyo Flows vs Campaigns pour comprendre où les custom properties s'intègrent le mieux
• Post-purchase flow : l'article sur le post-purchase flow Klaviyo illustre comment les custom properties enrichissent les séquences post-achat

Si vous souhaitez mettre en place une stratégie de données client structurée sur Klaviyo, de la collecte à l'exploitation en segmentation, notre agence Klaviyo peut vous accompagner sur l'audit, l'architecture des données et l'implémentation.