Passer au contenu principal
Coordonnez les SDK Kameleoon sur les sites web, les applications mobiles et les serveurs backend afin de conserver une identité visiteur unifiée. Cette coordination garantit une gestion cohérente des expériences et un flux de données fluide sur toutes les plateformes. Utilisez ce guide si un projet implémente plusieurs SDK Kameleoon :
  • Le SDK JavaScript ou engine.js pour les environnements web.
  • Le SDK mobile pour les applications Android ou iOS.
  • Les SDK côté serveur pour les intégrations backend et la logique de décision.

​
Vue d’ensemble de l’architecture

Une configuration multi-environnements typique comprend les composants suivants :
  • Site web : utilise le SDK JavaScript ou engine.js pour exécuter des expériences côté client et des campagnes de personnalisation.
  • Application mobile : utilise un SDK mobile pour afficher les variations et suivre les conversions.
  • Serveur backend : utilise un SDK côté serveur pour prendre des décisions centralisées de variation ou pour synchroniser les données visiteurs.

​
Flux de données et de visitor code

  • Le visitor code identifie les utilisateurs de manière cohérente dans tous les environnements.
  • Le SDK côté serveur coordonne les décisions de variation lorsque cela est nécessaire.
  • Chaque SDK envoie ses données d’analyse et de suivi directement à la plateforme Kameleoon.

​
Visitor code et gestion cross-device

​
Générer et partager les visitor codes

Chaque visiteur unique doit disposer d’un visitor code cohérent sur toutes les plateformes. Ce code permet à Kameleoon d’unifier les décisions d’expérience et le suivi. Suivez ce flux multiplateforme :
  1. Le moteur, le SDK web, le SDK côté serveur ou l’application mobile génère le visitor code.
  2. Le backend récupère le visitor code existant lorsque l’utilisateur se connecte sur une nouvelle plateforme.
  3. Le système transmet le visitor code aux SDK mobile, côté serveur et web. Cela garantit que toutes les plateformes évaluent le même utilisateur de manière cohérente.

​
Synchroniser les visitor codes

  • Stockez le visitor code de manière sécurisée dans le backend ou la base de données utilisateurs et associez-le à l’ID utilisateur.
  • Suivez ces étapes lorsqu’une connexion utilisateur a lieu sur une autre plateforme :
    • Application mobile : demandez le visitor code au backend.
    • SDK côté serveur : utilisez le même visitor code pour tous les appels de variation et de suivi.
    • SDK web : définissez le visitor code à l’aide de l’API JavaScript :
kameleoon.API.Visitor.setVisitorCode(visitorCode);
Le SDK web et le SDK côté serveur communiquent automatiquement via le cookie kameleoonVisitorCode. Vous n’avez pas besoin d’effectuer d’étapes supplémentaires pour les relier.

​
Bonnes pratiques

  • Faites correspondre l’identifiant utilisateur existant (tel que userId) à un unique visitor code Kameleoon sur toutes les plateformes.
  • Maintenez le backend comme source de vérité pour les visitor codes.
  • Empêchez les SDK d’écraser les visitor codes existants pour les utilisateurs connus.
L’identification unifiée garantit que chaque action utilisateur, chaque conversion et chaque décision de variation est associée au même visiteur dans Kameleoon.

​
Gestion des expériences entre environnements

Coordonnez les décisions et l’affichage des variations pour les expériences qui couvrent plusieurs environnements, tels que mobile et backend.

​
Exemple de scénario

Dans ce scénario :
  • L’application mobile affiche la variation.
  • Le serveur backend détermine la variation attribuée.

​
Options d’implémentation

Option 1 : logique de décision côté serveur
  1. L’application mobile envoie le visitor code au backend.
  2. Le SDK côté serveur appelle getVariation() (ou son équivalent) pour récupérer la variation attribuée.
  3. Le backend renvoie l’ID ou le nom de la variation à l’application mobile.
  4. L’application mobile affiche la variation et suit l’exposition.
  5. Les SDK mobile et serveur utilisent le même visitor code pour le suivi des événements.
Avantages :
  • Centralise la logique de variation et garantit des décisions cohérentes.
  • Prend en charge les expériences qui affectent à la fois la logique backend et les éléments d’interface utilisateur.
Option 2 : logique de décision côté client (mobile)
  1. Le SDK mobile récupère l’attribution de variation à l’aide du visitor code.
  2. L’application mobile applique la variation localement et suit l’exposition directement.
  3. (Optionnel) Si le backend participe également au suivi ou à la validation, le SDK côté serveur réutilise le même visitor code pour garantir un reporting cohérent.
Avantages :
  • Fournit une décision synchrone, sans latence.
  • Réduit la latence en évitant un aller-retour serveur.
  • Optimise les expériences centrées sur l’UI qui ne dépendent pas de la logique backend.

​
Choisir la bonne configuration

Cas d’usageCouche de décisionSource du visitor codeNotes
Expérience UI mobileSDK mobileBackendGère la variation localement
Pilotée par le backend ou l’APISDK côté serveurApp ou site webLogique de décision centralisée
Cohérence cross-deviceIndifférentBackendGarantit un suivi unifié

​
Exemples de code : transmettre le visitor code entre les couches

const visitorCode = kameleoon.API.Visitor.code;
fetch("/api/syncVisitor", {
  method: "POST",
  body: JSON.stringify({ visitorCode }),
});
Pour gérer l’implémentation du SDK sur différentes couches :
  • Attribuez un unique visitor code par utilisateur sur toutes les plateformes.
  • Gérez et distribuez les visitor codes depuis le backend.
  • Sélectionnez la couche de logique de variation en fonction du type d’expérience (serveur pour la logique centralisée, côté client pour l’UI pilotée par l’application).
  • Maintenez des données cohérentes et cross-device en suivant toute l’activité utilisateur avec le même visitor code.