Cross-device experimentation

Le parcours d’un client est rarement limité à un seul appareil. Des smartphones aux tablettes en passant par les ordinateurs de bureau, les utilisateurs passent régulièrement d’un appareil à l’autre. L’expérimentation cross-device répond à ce défi. Bien que combler le fossé entre les appareils soit un défi nuancé et qu’aucune solution ne soit parfaite, les bons outils — comme des identifiants utilisateur fiables et des pratiques de données réfléchies — permettent d’obtenir des informations sur les expériences des visiteurs à travers tous les points de contact.

​

Ce que l’expérimentation cross-device de Kameleoon peut faire​

• Garantir la cohérence des variations : Les utilisateurs connectés verront toujours la même variation dans une expérience, quel que soit l’appareil utilisé.
• Activer un ciblage unifié : Tenez compte de toutes les visites et actions d’un même utilisateur, quel que soit l’appareil.
• Fournir un reporting précis : Comptez avec précision les utilisateurs uniques sur tous les appareils pour mieux comprendre leur comportement.

​

Points critiques et informations pratiques​

• Le suivi cross-device dépend fortement de l’identification des utilisateurs. Si un utilisateur reste anonyme sur les différents appareils, il est impossible de fusionner ses données. Aucun système ne peut contourner cette limitation.
• Un identifiant utilisateur fiable (comme celui lié à une connexion) est essentiel pour lier les données entre les appareils. Sans identifiant fiable, la fusion des historiques de navigation ou des actions n’est pas réalisable.
• Les actions effectuées en état anonyme (par exemple, naviguer sans se connecter) ne peuvent pas être liées à un utilisateur identifié tant qu’une connexion n’a pas eu lieu. Une fois connecté, l’historique d’un utilisateur fusionne, mais uniquement à partir de ce moment-là.
  • Toutefois, notez que pour Web Experimentation, une fois que la custom data est fournie, Kameleoon peut la récupérer pour toutes les visites suivantes sur le même appareil, même si l’utilisateur ne s’est pas encore connecté. Cette récupération a lieu parce que les données sont stockées dans le local storage, ce qui n’est pas le cas dans Feature Experimentation.
• Bien que l’expérimentation cross-device fonctionne pour de nombreux cas d’usage, elle ne conviendra pas à toutes les expériences. L’expérimentation cross-device dépend de votre stack technique, des parcours clients de vos utilisateurs et de vos objectifs.

​

Comprendre les frontières d’identité​

Dans le contexte de l’expérimentation cross-device, les frontières d’identité font référence à la manière dont Kameleoon reconnaît et gère les utilisateurs à travers différentes sessions, appareils et états d’identification. Ces frontières sont cruciales pour déterminer si Kameleoon peut lier les données utilisateur entre différentes expériences. Kameleoon distingue principalement deux types d’identités d’utilisateurs :

• Utilisateurs anonymes : Il s’agit d’utilisateurs non connectés, identifiés par un identifiant temporaire basé sur l’appareil (visitorCode). Les identifiants anonymes sont uniques à l’appareil et au navigateur et ne persistent pas entre les appareils.
• Utilisateurs identifiés : Il s’agit d’utilisateurs qui se connectent et fournissent des identifiants uniques et cohérents (comme un ID utilisateur). Cet identifiant est lié à l’utilisateur individuel, ce qui permet à Kameleoon de fusionner ses actions et son historique sur tous les appareils et sessions.

​

Activer la réconciliation d’historique cross-device​

Pour utiliser la réconciliation d’historique cross-device, créez une nouvelle custom data Kameleoon et activez l’option Use this custom data as a unique identifier for cross-device matching. Lorsqu’elle est activée, Kameleoon traite cette custom data comme un identifiant unique des visiteurs, ce qui associe plusieurs visites Kameleoon à un utilisateur unique. Vous devez également définir la valeur de la custom data avec un identifiant unique, comme un ID utilisateur, en utilisant l’une des méthodes d’acquisition, comme la méthode SDK addData() ou l’Activation API.

​

Réconciliation d’historique cross-device pour la cohérence de l’allocation des variations​

L’objectif de la réconciliation d’historique cross-device pour l’allocation des variations est de garantir que les visiteurs assignés à une expérience voient systématiquement la même variation, quel que soit l’appareil utilisé pour accéder au site web. Cependant, il est important de reconnaître que maintenir cette cohérence peut être difficile dans certains scénarios. Par exemple, si un utilisateur visite le site web sur son premier appareil, se connecte et déclenche une expérience, Kameleoon peut lui attribuer la variation V1. Si le même utilisateur visite ensuite le site web sur un autre appareil et déclenche la même expérience avant de se connecter, le système peut lui attribuer la variation V2. Cette incohérence se produit parce que le système n’a pas encore reconnu l’utilisateur entre les appareils. Kameleoon ne remplace pas intentionnellement l’allocation de la variation au cours d’une même visite afin d’éviter de perturber l’expérience utilisateur. Pour atténuer ce problème et garantir la cohérence, identifiez les visiteurs rapidement tout au long de leur parcours sur le site web. Identifier les visiteurs tôt lorsqu’ils accèdent au site depuis différents appareils garantit qu’ils se voient systématiquement attribuer la même variation. Cette approche permet à Kameleoon de fournir une expérience de test fluide et cohérente.

​

Kameleoon Web Experimentation​

La solution Kameleoon Web Experimentation utilise principalement des mécanismes de stockage côté client pour gérer l’allocation des variations (bucketing). L’allocation de variation des utilisateurs est d’abord stockée dans le local storage lorsqu’ils participent à une expérience. Ce stockage garantit qu’un utilisateur voit systématiquement la même variation sur le même appareil, même si le client met à jour la répartition du trafic de l’expérience. Si le même utilisateur se connecte sur un autre appareil, Kameleoon récupère les informations de variation préalablement attribuées depuis le backend. Si la même expérience est déclenchée après cette étape, Kameleoon attribue à l’utilisateur la même variation. Cette synchronisation garantit qu’une variation est appliquée de manière cohérente entre les appareils sans réattribuer une nouvelle variation via le bucketing.

​

Expérimentation cross-device pour Feature Experimentation​

Feature Experimentation s’exécute dans des environnements où les données sont stockées en mémoire pendant la durée d’une session (qui est par défaut de 30 minutes, ce qui en fait un stockage peu fiable pour une allocation de variation à durée de vie limitée). Les SDK résolvent les variations dynamiquement au moment de l’exécution, ce qui introduit des complexités uniques pour la cohérence cross-device.

​

Rôle des SDK​

Les SDK sont essentiels pour Feature Experimentation car ils :

• Résolvent dynamiquement les allocations de variations en fonction de l’identité de l’utilisateur (visitorCode, généré aléatoirement par le SDK, ou votre propre ID utilisateur) lorsque le ciblage se produit.
• Utilisent la résolution d’identité pour récupérer les données précédemment collectées sur différents appareils, garantissant une attribution cohérente de la variation lorsque l’utilisateur change d’appareil.

​

Défis et considérations​

• Pas de local storage : Contrairement à Kameleoon Web Experimentation, les variations ne sont pas stockées de manière persistante ; elles sont recalculées au moment de l’exécution en fonction de l’identité de l’utilisateur.
• Sessions anonymes : Garantir la cohérence lorsque les utilisateurs commencent en anonyme puis se connectent peut être complexe.
• Résolution d’identité cross-device : L’attribution précise des variations d’expérience entre les appareils dépend d’une résolution d’identité robuste.

​

Exemples de cas d’usage​

Les cas d’usage suivants représentent les scénarios les plus courants rencontrés lors de la mise en œuvre de l’expérimentation cross-device. Ces exemples mettent en évidence les défis et les solutions typiques pour garantir des expériences utilisateur cohérentes et une attribution précise des variations sur plusieurs appareils.

​

Cas d’usage 1 (même appareil)​

Dans la première session, un utilisateur anonyme est ciblé par une expérience puis se connecte. Dans la deuxième session, le visiteur est connecté et est ciblé par la même expérience.

• Web experimentation : La variation reste cohérente avec la variation attribuée lors de la session initiale, car Kameleoon récupère la variation précédemment attribuée depuis le local storage.
• Feature experimentation : Si vous avez associé l’ID visiteur anonyme à l’ID utilisateur en utilisant une custom data, la même variation sera retournée lorsque getVariation() est appelée avec l’ID anonyme ou l’ID utilisateur. Cependant, une nouvelle variation sera attribuée si getVariation() est appelée lorsque l’ID utilisateur est utilisé dans la méthode, et qu’aucun mappage n’existe entre l’ID utilisateur et l’ID anonyme.

​

Cas d’usage 2 (même appareil)​

Un utilisateur se connecte et est ciblé par une expérience pendant une session. Dans une session ultérieure, l’utilisateur est déconnecté, devient anonyme et est ciblé par la même expérience.

• Web experimentation : La variation reste cohérente avec la variation attribuée lors de la session initiale, car Kameleoon récupère la variation précédemment attribuée depuis le local storage, assurant la continuité entre les sessions.
• Feature experimentation :
  • Si, durant la session 1, l’utilisateur est passé d’un état anonyme (anonymous1) à un état identifié (userId) et que l’ID anonyme a été mappé à l’ID utilisateur, lors de la session 2, Kameleoon réutilisera anonymous1 pour bucketer l’utilisateur avec la même variation.
  • Cependant, si aucun état anonyme n’a été géré lors de la session 1 (en appelant la méthode getVisitorCode()), un nouveau visitorCode (anonymous2) sera généré pour la session 2, entraînant une nouvelle allocation de variation.

​

Cas d’usage 3 (appareils différents)​

Un utilisateur anonyme se connecte sur un appareil et est ciblé par une expérience au cours de la même session. Lors d’une session ultérieure sur un autre appareil, l’utilisateur commence anonymement, est ciblé par la même expérience et se connecte.

• Web experimentation : Dans ce scénario, l’utilisateur peut recevoir deux variations différentes car Kameleoon ne reconnaît pas l’utilisateur sur le deuxième appareil au moment de la décision de ciblage. L’allocation de la variation sur le deuxième appareil se produit avant la connexion de l’utilisateur, ce qui entraîne un manque de synchronisation entre les appareils.
• Feature experimentation : Comme pour Web Experimentation, l’utilisateur peut recevoir deux variations différentes car Kameleoon ne reconnaît pas l’utilisateur sur le deuxième appareil au moment de la décision de ciblage. Dans ce cas, l’allocation de la variation sur le deuxième appareil se produit avant la connexion de l’utilisateur, ce qui signifie qu’il n’y a pas de synchronisation entre les appareils.

​

Cas d’usage 4 (appareils différents)​

Un utilisateur anonyme se connecte sur le premier appareil et est ciblé par une expérience. Plus tard, sur un deuxième appareil, l’utilisateur se connecte avant d’être ciblé par la même expérience.

• Web experimentation : La variation reste cohérente entre les appareils. Comme l’utilisateur se connecte avant que l’expérience ne soit réévaluée, le système aligne la variation sur celle attribuée sur le premier appareil.
• Feature experimentation : Kameleoon détermine l’allocation de la variation en fonction du mappage de l’ID utilisateur avec l’ID anonyme le plus récent généré pour le visiteur.
  • Sur Device 1, un visiteur anonyme (anonymous1) est évalué pour l’expérience et reçoit une variation (var1). Lors de la connexion, Kameleoon crée un mappage entre userId et anonymous1.
  • Sur Device 2, si la session commence directement avec le userId (sans appel à getVisitorCode() générant un ID anonyme), appeler getRemoteVisitorData(userId) permet à Kameleoon de récupérer le mappage du visiteur anonyme le plus récent (anonymous1). Par conséquent, lorsque vous appelez getRemoteVisitorData() et getVariation() pour l’expérience, l’utilisateur recevra la variation (var1) attribuée à anonymous1. Toutefois, si la session commence en état anonyme, une nouvelle variation peut être attribuée puisque le bucketing utilisera la nouvelle clé de bucketing générée.

​

Cas d’usage 5 (appareils différents)​

Un utilisateur anonyme est ciblé par une expérience sur un appareil et se connecte. Sur un deuxième appareil, l’utilisateur se connecte et est ciblé par la même expérience.

• Web experimentation : La variation reste cohérente entre les appareils. Une fois l’utilisateur connecté, le système peut attribuer la même variation à l’utilisateur.
• Feature experimentation : La variation reste cohérente uniquement si vous appelez getRemoteVisitorData(). Sans cet appel, le système peut ne pas associer les deux sessions, ce qui peut entraîner une attribution de variation différente entre les appareils.

​

Réconciliation d’historique cross-device pour le ciblage​

Kameleoon télécharge automatiquement une liste de visites provenant d’autres appareils et stocke ces informations dans le stockage de l’appareil actuel lorsqu’une nouvelle session commence et qu’une custom data est définie avec une valeur. Cependant, si la custom data est vide, la réconciliation ne sera pas effectuée au début de la session. La réconciliation n’est déclenchée que lorsque la custom data est passée, et le ciblage est réévalué pour toutes les expériences et personnalisations actives. Cela se produit généralement lorsqu’un utilisateur se connecte à votre site et fournit son ID utilisateur, son e-mail ou un autre identifiant unique. Il est important de noter qu’une fois la custom data fournie, Kameleoon peut la récupérer pour toutes les visites suivantes sur le même appareil, même si l’utilisateur ne s’est pas encore connecté. La réconciliation a lieu au début de chaque visite suivante, garantissant des capacités de suivi et de ciblage cohérentes.

​

Données affectées par la réconciliation d’historique cross-device​

La fonctionnalité de réconciliation d’historique ajoute la liste de toutes les visites précédentes qui ne sont pas encore connues sur l’appareil actuel. Cela inclut des informations typiques telles que

• Nombre de visites et pages vues
• Durée de la session
• Canaux d’acquisition et référents
• Custom data (note : la custom data fournie dans d’autres sessions avec un scope visiteur fusionnera dans la session actuelle).

Vous pouvez utiliser les segments de ciblage comme d’habitude, et ils fonctionneront comme prévu. Par exemple, une condition de ciblage basée sur le nombre de visites précédentes prendra correctement en compte toutes les visites, tout comme une condition basée sur la durée de la visite précédente

​

Réconciliation d’historique cross-device pour l’analytique​

La réconciliation d’historique n’affecte que la vue visiteur du reporting Kameleoon ; la vue visite n’est pas affectée. Dans le modèle visiteur, au lieu de regrouper plusieurs sessions dans un seul enregistrement visiteur en utilisant la valeur standard Kameleoon visitorCode (ce qui n’est possible que pour les visiteurs récurrents sur le même appareil), le système les fusionne en fonction de la valeur de la custom data. Si la custom data est vide ou non fournie, la valeur visitorCode est utilisée à la place. Cette approche garantit que les métriques de visiteurs uniques restent précises, même si l’utilisateur n’est pas encore identifié dans le système client (bien que cette logique ne s’applique qu’aux visiteurs récurrents sur le même appareil). Par conséquent, la vue visiteur affiche correctement les métriques sur tous les appareils pour les utilisateurs identifiés. Par exemple, un seul client avec trois sessions sur deux appareils différents est compté comme un seul visiteur. Sans réconciliation d’historique, ce même client est compté comme deux visiteurs distincts (un par appareil).

​

Utilisation de la custom data pour la fusion de sessions​

L’utilisation d’une custom data comme identifiant unique pour la fusion de sessions n’est possible que pour les sessions enregistrées après que Kameleoon a identifié quelle custom data utiliser. Par conséquent, Kameleoon recommande vivement de sélectionner la custom data lors de l’installation et de la configuration initiales pour éviter de la changer ultérieurement. Par exemple, si Kameleoon fonctionne pendant un mois sans activer la réconciliation d’historique cross-device, et qu’elle est ensuite activée le deuxième mois, un seul utilisateur ayant visité deux fois (une fois chaque mois) sera compté comme deux visiteurs différents. Cette différence se produit parce que la fusion des sessions du premier mois utilise le visitorCode comme clé, tandis qu’au deuxième mois elle utilise la custom data avec une valeur différente, même si l’utilisateur s’est connecté lors des deux visites en utilisant le même appareil. Toute modification de la configuration de la custom data responsable de la réconciliation d’historique affectera temporairement la précision des métriques basées sur les visiteurs, à mesure que la majorité des visiteurs se connectent, selon la fréquence à laquelle ils reviennent sur le site et s’authentifient.