Cibler les utilisateurs avec des critères de segmentation natifs

​

Gérer les données dans les SDK Kameleoon

​

Terminologie clé

• Condition de ciblage : L’attribut spécifique de l’utilisateur ou de la session utilisé pour le ciblage, tel que la conversion, le navigateur ou les données personnalisées.
• Côté client : Gestion des données pour les SDK standards fonctionnant dans un navigateur web ou une application mobile.
• Côté client (Cross-device) : Gestion des données pour les implémentations côté client qui maintiennent un profil visiteur cohérent sur plusieurs appareils.
• Côté serveur : Gestion des données lorsque le SDK s’exécute sur un serveur backend. Contrairement aux SDK côté client, les SDK côté serveur suppriment généralement les informations du visiteur après la fin d’une session.
• web only : Une condition de ciblage basée sur des données que seul un navigateur génère, comme l’URL de la page ou le titre de la page. Les SDK web collectent ces données automatiquement. Les SDK Android, iOS et Flutter ne prennent pas en charge ces conditions car aucun navigateur ne génère les données. Le SDK React Native offre une prise en charge expérimentale de ces conditions. Les SDK côté serveur prennent en charge ces conditions : ils reçoivent les données via addData() ou les récupèrent depuis une session web précédente avec getRemoteVisitorData().

​

Exigences de collecte de données

​

Utiliser getRemoteVisitorData() pour les données historiques

​

Définitions de gestion des données

​

SDK côté client

• Non (Automatique) : Le SDK collecte ces données automatiquement. Aucune requête distante ni appel explicite à addData() n’est requis.
• Non : Le SDK ne collecte pas ces données automatiquement. Vous devez utiliser addData(), trackConversion() ou des méthodes d’évaluation comme getVariation() pour ajouter ces données. Aucune requête distante n’est requise.
• Oui : Vous devez appeler getRemoteVisitorData(). Cette exigence s’applique aux données générées sur le serveur (comme « Likelihood to convert ») ou lors de l’unification des sessions sur plusieurs appareils pour récupérer les actions d’un appareil précédent.

​

SDK côté serveur

• Non (Automatique) : S’applique uniquement à « SDK Type ». Le SDK collecte cela automatiquement.
• Non : Utilisez addData() ou trackConversion() pour fournir ces données. Aucune requête distante n’est requise.
• Non/Oui : Vous pouvez fournir les données directement sur le serveur ou les obtenir via une requête distante. Ce scénario se produit si un SDK côté client a déjà collecté des informations pendant la visite en cours.
• Oui : Vous devez appeler getRemoteVisitorData(). Comme les SDK côté serveur ont un stockage de données limité, ils nécessitent un appel distant pour identifier les actions historiques, telles que les visites précédentes ou l’exclusivité pour une expérience.

​

Avantages de la récupération distante de données

• Informations à jour : Les décisions utilisent des données en temps réel issues de la Data API.
• Cohérence cross-device : Accède aux données collectées depuis d’autres appareils ou sessions.
• Accès historique : Récupère le comportement passé de l’utilisateur, comme les visites d’URL précédentes, même si l’état local du SDK a été effacé.

​

Contraintes de ciblage en edge

​

D’où proviennent les données visiteur en edge

​

getRemoteVisitorData() en edge

• Latence : un appel à getRemoteVisitorData() prend généralement entre 100 et 200 ms pour récupérer les données historiques du visiteur depuis la Data API. L’évaluation des flags et des variations se termine normalement en quelques millisecondes ; ajouter une récupération de données distante à chaque requête pousse donc la latence bien au-delà de ce que ciblent la plupart des cas d’usage en edge.
• Absence de mémoire partagée durable : une plateforme edge peut détruire et recréer une instance de worker à tout moment, donc la mise en cache d’un résultat de getRemoteVisitorData() entre plusieurs requêtes n’est pas fiable, sauf si votre framework propose une mémoire durable et partagée entre les requêtes pour le stocker.

​

Transmettre les données visiteur à l’edge worker

1. Collectez les attributs du visiteur en amont, par exemple lors d’un chargement de page précédent ou d’un appel SDK côté client.
2. Transmettez les attributs dans la requête edge, généralement sous forme de cookies, car un edge worker peut lire les cookies de la requête entrante sans effectuer d’appel externe.
3. Dans l’edge worker, lisez les attributs et appelez addData() avec eux avant d’évaluer un feature flag ou une expérience.

import { CustomData } from '@kameleoon/nodejs-sdk';

// Inside the edge worker, before evaluating any feature flag
const visitorCode = getCookie(request, 'kameleoonVisitorCode');
const plan = getCookie(request, 'customerPlan');

const customData = new CustomData(1, plan);
client.addData(visitorCode, customData);

const variation = client.getVariation({ visitorCode, featureKey: 'my_feature_key' });

​

Les contraintes varient selon le framework edge et le plan

​

Mode Hybrid Experimentation

• Simplifie le processus d’implémentation.
• Accède aux données côté client collectées par le moteur, comme les variables datalayer et les objectifs front-end, directement au niveau du SDK.

• Implémentez à la fois le SDK et la balise JavaScript Kameleoon.

​

FAQ