Passer au contenu principal
Les données personnalisées sont l’une des fonctionnalités les plus puissantes de Kameleoon. Les données personnalisées permettent d’associer n’importe quel type de données à chaque visiteur et sont utilisées à deux fins :
  1. Générer des segments de ciblage basés sur les données des visiteurs, y compris la création de segments avancés pour les expériences et les personnalisations. Des exemples de données personnalisées comprennent l’âge, les achats précédents, le montant actuel du panier et la catégorie favorite. Généralement, les données personnalisées sont étroitement liées aux spécificités d’une activité. Par exemple, si vous exploitez un site marketplace, vous pouvez créer une donnée personnalisée qui indique si un visiteur est principalement un “acheteur” ou un “vendeur”.
  2. Fournir des rapports d’analyse avancés en décomposant les résultats selon les données personnalisées, ainsi qu’en filtrant les rapports d’expérience et de personnalisation à l’aide de toute valeur de données stockée.
Les données personnalisées peuvent être des types suivants : unique, liste ou liste comptée, avec un format chaîne de caractères, booléen ou nombre, et une portée page, visite ou visiteur. Cet article sert de guide général pour en apprendre davantage sur les données personnalisées et sur la façon de les utiliser efficacement. Si vous souhaitez créer des données personnalisées dans la plateforme Kameleoon, vous pouvez consulter le guide utilisateur suivant.

​
Aperçu technique

Une fois qu’une valeur de donnée personnalisée est définie, elle est stockée localement sur le serveur ou sur l’appareil de l’utilisateur, selon qu’un SDK côté serveur ou un SDK côté client est utilisé, y compris le fichier d’application (engine.js), plutôt que d’être récupérée à partir d’un serveur Kameleoon distant. Ce stockage signifie que les données peuvent être récupérées lors des pages vues suivantes de la même visite ou lors de visites futures. Lorsque Kameleoon est chargé, toute donnée personnalisée qui a été écrite sera automatiquement disponible pour une utilisation ultérieure, soit via l’Activation API, soit via les SDK.
Si Kameleoon Web Experimentation est utilisé, l’implémentation LocalStorage est unifiée, ce qui signifie que les parcours utilisateurs s’étendant sur plusieurs sous-domaines sont automatiquement gérés par Kameleoon, à condition que les directives d’implémentation pour l’unification des données de session entre sous-domaines soient respectées. Kameleoon enregistre et charge également les données personnalisées et gère les problèmes complexes, tels que l’accès simultané depuis plusieurs onglets sur le même site web.
Toute valeur définie pour une donnée personnalisée peut également être envoyée aux serveurs de collecte de données Kameleoon dans le cadre du processus de suivi standard, ce qui sert à trois fins :
  1. Les données sont disponibles à des fins de reporting et peuvent être utilisées pour filtrer ou décomposer les données de visite ou de visiteur par attributs spécifiques (par exemple, nombre de visites ou de visiteurs par type de profil), ou pour analyser des données (par exemple, conversions par type de paiement). Lier une donnée personnalisée à un objectif en tant que métadonnée est nécessaire pour filtrer ou décomposer les données de conversion en fonction de la valeur de la métadonnée.
Lorsqu’une donnée personnalisée est définie comme métadonnée d’objectif, Kameleoon utilise automatiquement la valeur la plus récemment suivie de la donnée personnalisée dans le reporting pour chaque conversion d’objectif. Vous pouvez définir manuellement la valeur de la donnée personnalisée en utilisant le paramètre metadata de la méthode processConversion de l’Activation API, ou la méthode trackConversion du SDK.
  1. Les données peuvent être utilisées en entrée pour les algorithmes d’apprentissage automatique du ciblage prédictif par IA et des expériences Contextual Bandit.
  2. Les données sont stockées sur les serveurs backend et peuvent être récupérées à l’aide de la Data API.
La dernière version (2.3) des restrictions Intelligent Tracking Prevention (ITP) sur les navigateurs Safari efface le LocalStorage après sept jours, ce qui signifie que si un visiteur récurrent revient après sept jours, des appels de synchronisation supplémentaires au serveur pour récupérer le contenu des données personnalisées ne peuvent pas être évités dans Safari. Cependant, Kameleoon optimise ces appels et ne les effectue que si nécessaire (par exemple, si la période de sept jours s’est écoulée). Pour plus d’informations sur la solution, consultez l’article gestion de l’ITP.

​
Concepts techniques de base : Portée des données personnalisées

La portée des données personnalisées est cruciale car elle détermine comment la valeur se comporte pour le ciblage et comment elle est stockée et affichée dans le reporting. La configuration des données personnalisées dépend de votre type d’implémentation : Web Experimentation ou Feature Experimentation (SDKs), ainsi que de la manière et du moment où vous comptez utiliser les données personnalisées.

​
Portée pour le ciblage

La façon dont les données personnalisées se comportent pour le ciblage diffère considérablement entre Web Experimentation et Feature Experimentation.

​
Web Experimentation (engine.js)

Pour Web Experimentation, le ciblage est généralement évalué une seule fois sur la page en fonction de la valeur de la donnée personnalisée. Il ne sera pas réévalué si la valeur de la donnée personnalisée change sur la même page. La portée de la donnée personnalisée dicte sa durée de vie pour le ciblage :
  • Page : La valeur de la donnée personnalisée est réinitialisée après chaque page vue.
    • Cas d’utilisation : Cibler les utilisateurs qui naviguent (ou se trouvent) sur un type de page spécifique (pages produit, par exemple).
  • Visite : La valeur de la donnée personnalisée est réinitialisée après chaque visite. La donnée personnalisée conservera sa dernière valeur lorsqu’un utilisateur navigue de page en page au cours de la même visite.
    • Cas d’utilisation : Cibler un visiteur qui s’est inscrit à une newsletter pendant sa visite actuelle.
  • Visiteur : La valeur de la donnée personnalisée ne sera pas réinitialisée. Elle conservera sa dernière valeur sur plusieurs visites du même visiteur.
    • Cas d’utilisation : Cibler un visiteur qui a effectué des achats sur le site trois fois historiquement.
S’il existe un risque qu’une valeur de donnée personnalisée puisse être obtenue après l’initialisation de Kameleoon et la première exécution de ciblage associée, définissez la portée sur PAGE. Si la portée n’est pas définie sur PAGE, la valeur actuelle de la donnée personnalisée peut être “en retard” et causer des problèmes de ciblage, notamment lors de l’exécution d’une expérience ciblant des visiteurs qui se déplacent vers une page produit après avoir parcouru une page catégorie, obtenant une nouvelle valeur après seulement quelques secondes. Avec une portée PAGE, ce problème ne se produira pas.

​
Feature Experimentation (SDKs)

Avec les SDKs pour Feature Experimentation, il n’y a aucun concept de “page” en termes de portée. Les valeurs des données personnalisées sont transmises explicitement au moment de l’évaluation. Ici, la portée définit principalement la façon dont la donnée personnalisée est stockée sur les serveurs de Kameleoon et quelle valeur est automatiquement récupérée (par exemple, en utilisant getRemoteVisitorData()). Par défaut, l’API ne récupère que les valeurs ayant la portée VISITOR. Ces valeurs sont attachées au visiteur et utilisées lors de l’évaluation.

​
Reporting et affichage des données personnalisées

La façon dont les données personnalisées apparaissent dans vos rapports dépend également de votre type d’expérimentation, du type et de la portée de la donnée personnalisée, et de l’utilisation ou non du paramètre optionnel overwrite avec setCustomData().

​
Logique par défaut (lorsque le paramètre overwrite est false ou omis)

Pour Web Experimentation (page de résultats)
Sur la page de résultats pour Web Experimentation, tous les types de données personnalisées peuvent avoir plusieurs valeurs sur la même page et au cours de la même visite. Les règles suivantes s’appliquent pour l’affichage de ces valeurs :
  • Type unique et portée page : Toutes les valeurs définies pendant une visite seront affichées sur la page de résultats pour décomposer les visites. Si une valeur est définie une fois ou plusieurs fois, cela donne le même affichage (par exemple, la visite est étiquetée avec cette valeur).
    • Cas d’utilisation : Décomposer les visites selon les catégories de pages consultées.
  • Type unique et portée visite : La page de résultats n’affichera que la dernière valeur définie pendant la visite pour décomposer les visites.
    • Cas d’utilisation : Décomposer les visites par type d’adhésion utilisateur.
  • Type unique et portée visiteur : Si vous utilisez la vue Visiteur sur la page de résultats et décomposez par donnée personnalisée, Kameleoon affiche toutes les valeurs reçues pour cette donnée personnalisée pour le visiteur, ce qui couvre toutes les visites précédentes exposées à ou influencées par l’expérience, dans la période sélectionnée.
    • Cas d’utilisation : Décomposer les visiteurs selon le nombre d’achats qu’ils ont effectués sur le site sur l’ensemble de leurs visites.
  • Toutes les combinaisons pour les types/portées (list, countList/page, visite, visiteur) : Toutes les valeurs attribuées pendant la visite seront affichées sur la page de résultats pour une décomposition détaillée des visites. Si une valeur est attribuée à une visite, qu’elle soit attribuée une fois ou à plusieurs reprises, elle sera affichée de manière cohérente, étiquetant la visite avec cette valeur.
    • Cas d’utilisation : Décomposer les visites selon toutes les newsletters auxquelles un utilisateur s’est inscrit, les liens du menu de navigation cliqués ou les filtres sélectionnés sur une page catégorie.
Pour Feature Experimentation (SDKs)
Pour Feature Experimentation, le reporting des données personnalisées fonctionne différemment en raison de la nature des environnements SDK, qui n’ont généralement pas de concept de “page” comme les navigateurs web.
  • La portée Page ne s’applique pas à des fins de reporting dans Feature Experimentation, car les SDK s’exécutent souvent dans des environnements côté serveur ou mobile où un événement distinct de “chargement de page”, qui déclencherait une réinitialisation des données, n’existe pas intrinsèquement.
  • Pour toute donnée personnalisée donnée, Kameleoon ne conservera et ne rapportera que la dernière valeur reçue pendant une visite. Cette approche est efficace et pertinente pour les environnements où l’état le plus récent des attributs d’un utilisateur au sein d’une session continue est généralement ce qui importe pour les décisions liées aux fonctionnalités.
  • Les portées Visite et Visiteur se comportent comme prévu pour le reporting, permettant des décompositions par la dernière valeur dans une visite ou sur plusieurs visites pour un visiteur, respectivement.

​
Remplacer le comportement par défaut avec le paramètre overwrite

Le paramètre overwrite (optionnel boolean) de la méthode setCustomData() vous permet de contrôler explicitement la façon dont les valeurs des données personnalisées sont stockées et, par conséquent, comment elles apparaissent dans les rapports.
  • Lorsque overwrite est true : La nouvelle valeur fournie à setCustomData() remplacera toujours toutes les valeurs existantes pour cette clé de donnée personnalisée dans la session/visite actuelle, indépendamment de son type (Single, List, Count List) ou de sa portée (Page, Visit, Visitor), ce qui signifie que seule la valeur la plus récemment définie sera disponible pour le ciblage et le reporting.
  • Lorsque overwrite est false ou omis : La logique par défaut telle que décrite dans les sections ci-dessus s’appliquera.
Vous pouvez utiliser des données personnalisées en tant que métadonnées lors de la configuration d’un objectif, ce qui permet d’attacher la valeur de la donnée personnalisée à chaque conversion à des fins de reporting et d’analyse. Pour plus d’informations sur la création d’un objectif, consultez l’article Créer un nouvel objectif.Par défaut, les données personnalisées sont des attributs liés aux utilisateurs ; cependant, si vous souhaitez utiliser des données personnalisées comme propriétés d’une conversion, vous pouvez utiliser des métadonnées.

​
Méthodes de récupération

Kameleoon propose diverses intégrations prêtes à l’emploi, détaillées ci-dessous.

​
Couches de données

Ces méthodes récupèrent la valeur de la donnée personnalisée à partir d’une variable donnée dans la couche de données (data layer) pour Google Tag Manager, Tealium ou Commander’s Act. Spécifiez le nom de la variable dans la couche de données, et Kameleoon complète automatiquement l’intégration dès que la couche de données se charge sur la page.
Kameleoon prend en charge plusieurs niveaux de hiérarchie et variables tableau dans la couche de données. Par exemple, vous pouvez récupérer une valeur depuis product.category.name, cart["amount"] ou purchases[3].
Kameleoon ne peut définir la valeur de la donnée personnalisée qu’après que la couche de données est disponible sur votre page, ce qui peut prendre plusieurs secondes (selon le moment où vous chargez votre tag manager). Si vous utilisez la donnée personnalisée comme condition de ciblage dans un A/B test, un effet de scintillement notable peut se produire.

​
Activation API

Utilisez l’Activation API pour définir les valeurs des données personnalisées sur le navigateur (environnement côté client). Localisez un élément DOM particulier sur la page et utilisez son contenu comme valeur de la donnée personnalisée. Par exemple, obtenez la valeur actuelle du montant du panier s’il est affiché sur la page web et remplissez la donnée personnalisée correspondante en conséquence.
La méthode setCustomData() de l’Activation API inclut un paramètre nommé overwriteIfCollection. Pour plus de détails sur cette méthode, consultez la documentation de l’Activation API.
La méthode Kameleoon.API.Data.setCustomData() écrase toujours les valeurs existantes précédentes pour la donnée personnalisée, sauf si le type est List ou Counted List, et que le troisième argument est false, auquel cas elle ajoute à la liste existante.

​
Code JavaScript personnalisé

Cette option vous permet d’écrire du code JavaScript personnalisé ad hoc. La règle principale à suivre lors de la définition d’une donnée personnalisée est que votre code doit retourner un objet avec deux clés : value avec la valeur que vous souhaitez fournir pour cette donnée personnalisée et (optionnellement) override avec une valeur booléenne (false par défaut). Si aucune valeur n’est encore disponible mais sera obtenue plus tard sur la page, ne retournez aucune valeur (retourner null ou undefined est également acceptable). Le système exécute à nouveau le code (toutes les 100 ms pendant les trois premières secondes après le premier appel, puis toutes les trois secondes). Par convention, retourner {"value": null} ne définira pas la donnée personnalisée mais arrêtera l’exécution régulière. La première exécution a lieu avant que le système de ciblage Kameleoon ne soit déclenché, ce qui permet de configurer les données personnalisées avant l’exécution du ciblage.
Évitez d’utiliser cette méthode de récupération si possible. Écrivez le code JavaScript à un autre endroit, comme dans un Tag Manager, un fichier de script externe ou du code script en ligne dans le code HTML, puis utilisez la méthode de récupération via l’Activation API pour définir la donnée personnalisée.

​
Méthode SDK

Pour Feature Experimentation (SDKs), les valeurs des données personnalisées sont acquises et envoyées à Kameleoon uniquement via les méthodes du SDK, ce qui signifie qu’elles sont explicitement transmises via l’intégration du SDK (par exemple, en utilisant des méthodes comme addData() ou setCustomData() selon le SDK spécifique). Pour plus de détails sur l’utilisation des données personnalisées dans les SDK, consultez l’article utilisation de l’historique des visites.

​
Data API / Intégration serveur à serveur

Si vous cherchez à mettre en place une intégration serveur à serveur, la Data API est l’approche recommandée. L’utilisation de la Data API implique la mise en œuvre d’un appel REST aux serveurs Kameleoon, en spécifiant le nom et la valeur de la donnée personnalisée ainsi que le visitorCode.

​
Options avancées

​
Utiliser ces données uniquement localement à des fins de ciblage

L’activation de cette option permet à la valeur de la donnée personnalisée d’être stockée localement sur l’appareil de l’utilisateur ou sur le serveur si vous utilisez l’un des SDK côté serveur. Comme ces données ne seront pas stockées sur les serveurs Kameleoon, elles ne peuvent pas être utilisées pour l’analytique dans le reporting. Cette fonctionnalité peut être bénéfique pour des raisons de confidentialité ou légales. Certains clients peuvent exiger que les données sensibles ne soient pas stockées en dehors de leurs systèmes, tout en souhaitant personnaliser l’expérience du visiteur en fonction de ces données.

​
Utiliser cette donnée personnalisée comme entrée pour le ciblage prédictif par IA

L’activation de cette option permet aux algorithmes d’apprentissage automatique d’utiliser cette donnée personnalisée comme entrée. Cette fonctionnalité n’est disponible qu’avec un abonnement au module complémentaire ciblage prédictif par IA.

​
Utiliser cette donnée personnalisée comme identifiant unique pour la réconciliation de l’historique multi-appareils

Lorsqu’elle est activée, Kameleoon traite cette donnée personnalisée comme un identifiant unique pour vos visiteurs, qui sera utilisé pour associer plusieurs visites Kameleoon à un utilisateur unique pour l’expérimentation multi-appareils. Pour en savoir plus sur cette fonctionnalité, consultez l’article Expérimentation multi-appareils.

​
Utilisation des données personnalisées

​
Condition de ciblage pour les segments

Le générateur de segments Kameleoon ajoutera automatiquement des conditions de ciblage pour toute donnée personnalisée que vous définissez. Le processus est automatique, et si la valeur de la donnée personnalisée correspond à votre condition, ce visiteur particulier sera inclus dans le segment.

​
Via l’Activation API

Vous pouvez obtenir la valeur actuelle d’une donnée personnalisée via Kameleoon.API.CurrentVisit.customData (portées PAGE ou VISIT) ou Kameleoon.API.Visitor.customData (portée VISITOR).

​
Via les SDK

La méthode getRemoteVisitorData() récupère toutes les données personnalisées collectées lors de la visite précédente du visiteur actuel. Pour plus de détails, consultez l’article utilisation de l’historique des visites.

​
Fins d’analyse

Toute donnée personnalisée (à l’exception de celles marquées comme locales uniquement) peut être utilisée comme filtre ou comme option de décomposition dans les pages de résultats d’expérience ou de personnalisation. Cette information est également disponible dans les rapports produits par l’outil d’exportation de données brutes, et des requêtes complexes incluant des données personnalisées peuvent être effectuées (avec un cluster de données Kameleoon dédié). Pour une décomposition utilisant une donnée personnalisée de type String, les résultats incluront jusqu’à 50 des valeurs les plus fréquemment utilisées pour cette donnée. Pour une décomposition avec une donnée personnalisée de type Number, les résultats seront également décomposés avec un maximum de 50 valeurs possibles. Dans le cas de données personnalisées numériques, cette limite n’a pas toujours de sens. Lorsqu’une donnée personnalisée est liée à un objectif en tant que métadonnée, les valeurs sont actuellement accessibles uniquement via une exportation brute. Une mise à jour de la page de reporting, attendue plus tard au deuxième trimestre, permettra d’utiliser les métadonnées comme filtres directement dans les résultats.

​
Paramètres avancés

​
Implémenter un composant de liste déroulante personnalisée pour la condition de ciblage associée à cette donnée personnalisée

Cette fonctionnalité simplifie la sélection des valeurs des données personnalisées dans les conditions de ciblage en les présentant dans une liste déroulante au lieu d’un champ de texte brut, ce qui facilite beaucoup la sélection de la valeur appropriée pour le ciblage par les utilisateurs finaux. Deux points importants sont à considérer :
  • Les valeurs brutes peuvent être associées à des libellés descriptifs.
  • Les libellés et valeurs sont obtenus dynamiquement lorsque l’interface de condition de ciblage est affichée.
Cette fonctionnalité est particulièrement utile pour l’intégration avec des fournisseurs de données tiers, comme les DMP ou CRM. Par exemple, si la donnée personnalisée représente un segment externe issu d’une DMP, l’utilisateur peut sélectionner “Clients fidèles” au lieu de l’ID interne, qui est généralement une chaîne de caractères complexe comme “8ney4225y65a”. La liste des segments définis dans la DMP est toujours à jour sur l’interface de Kameleoon, donc cette fonctionnalité gère la synchronisation automatiquement.
Les libellés associés aux données personnalisées ne sont visibles que par les utilisateurs ayant accès à la plateforme Kameleoon. Ils ne sont pas inclus dans le fichier d’application JavaScript, de sorte que les visiteurs du site ne peuvent pas les voir. Le processus est masqué à l’utilisateur.
Pour implémenter cette fonctionnalité pour une donnée personnalisée spécifique, vous devez fournir du code JavaScript qui retournera de façon synchrone un tableau d’objets représentant les valeurs possibles avec leurs libellés. Le tableau doit répondre aux exigences suivantes :
  • Tous les éléments du tableau doivent être des objets JavaScript.
  • Ces objets doivent avoir deux clés : une clé value (contenant la valeur possible réelle pour la donnée personnalisée) et une clé label (représentant la description textuelle de cette valeur particulière).
  • Le type de contenu pour la clé value doit correspondre au type réel de la donnée personnalisée. Pour la clé label, vous devez fournir une chaîne de caractères comme contenu.
Voir l’exemple de code ci-dessous pour un exemple d’utilisation pratique de cette fonctionnalité. Dans cet exemple, un appel distant est effectué vers un serveur tiers (généralement une DMP ou une plateforme similaire) qui fournit la liste des segments disponibles définis sur la plateforme. Il est important de noter que ce code n’est utilisé que pour construire l’interface de sélection pour l’utilisateur final de Kameleoon. 
var xhr = new XMLHttpRequest();
xhr.open("GET", "https://third-party.dmp.com/get-segments?login=XXXX@XXXX.com&password=XXXX", false);

var segments = [];
xhr.onreadystatechange = function() {

    if (this.readyState === XMLHttpRequest.DONE && this.status === 200) {
        var data = JSON.parse(xhr.response);
        data.map(function (segment) {
          if (segment.segment_uuid && segment.name !== "undefined") {
            segments.push({"label": segment.name, "value": segment.segment_uuid});
          }
        });
    }
}

xhr.send();
return segments;
Assurez-vous que le code s’exécute de manière synchrone et retourne sa valeur avec un comportement bloquant. Évitez tout appel distant asynchrone, car cela peut entraîner un dysfonctionnement de la fonctionnalité.