Les API Experience vous permettent de servir du contenu sur les applications web et mobiles à partir du même site, et également de créer un profil client unifié sur les deux types d’appareils en implémentant des événements d’identification avec des valeurs correspondantes.
Toutes vos données et tous vos actifs, tels que vos stratégies de recommandation, sont stockés de manière centralisée sur un site unique de Dynamic Yield. Vos utilisateurs peuvent être référencés par un seul ID sur l’ensemble de vos plateformes, plutôt que d’avoir à gérer des ID différents sur chaque plateforme. Cela vous permet d’établir un profil d’utilisateur plus complet, améliorant nos stratégies de recommandation et offrant aux utilisateurs une expérience de navigation cohérente sur l’ensemble de vos plateformes.
Par exemple, un utilisateur parcourt une catégorie de produits (des chaussures, par exemple) pour la première fois sur votre application mobile. Lors de sa prochaine visite sur votre site web, l’utilisateur voit des recommandations pour des chaussures, même s’il n’a jamais consulté ces données sur ce site web. Notez que vous devez envoyer un événement d’identification chaque fois qu’un utilisateur se connecte sur un appareil spécifique (son téléphone portable, par exemple) afin que nous puissions toujours reconnaître le même utilisateur sur différents appareils.
Implémentation
Obtention des ID d’utilisateur et de session de Dynamic Yield
Il existe deux façons d’obtenir les ID de l’utilisateur et de la session dans l’application :
- Si l’utilisateur est redirigé depuis le site vers l’application, les ID de l’utilisateur et de la session doivent être transmis avec la redirection et stockés dans l’application.
- Si l’utilisateur ouvre l’application sans avoir stocké de valeurs au préalable, il obtient les ID en appelant une requête /choose vide et en stockant les valeurs renvoyées par Dynamic Yield dans l’application.
Stockage des ID de l’utilisateur et de la session dans l’application
Les deux valeurs doivent être conservées pendant des périodes différentes, c’est pourquoi elles sont stockées différemment :
- Stocker l’ID de l’utilisateur de Dynamic Yield dans l’application, et le conserver tant que l’application reste installée.
- Stocker l’ID de session Dynamic Yield dans le cache de l’application, et le conserver aussi longtemps que l’application est en mémoire (avant-plan ou arrière-plan).
Points d’implémentation spécifiques aux mobiles
Pour spécifiquement cibler les campagnes sur les utilisateurs de l’application, nous vous recommandons de :
- Implémenter un événement personnalisé dans l’application juste après que l’utilisateur a reçu les ID d’utilisateur et de session de Dynamic Yield (par exemple, un événement portant le nom « App User »). Cela permet de placer l’utilisateur dans une audience réservée à l’application mobile.
- Ajouter un attribut de page personnalisé à chaque requête /choose provenant de l’application. Cela permet de cibler l’expérience sur l’application mobile uniquement.
- Gérer les sessions sans perdre l’ID de l’utilisateur. Lorsqu’une session sur l’application se termine et que l’utilisateur ouvre à nouveau l’application, la requête /choose adressée à Dynamic Yield doit toujours inclure l’ID de l’utilisateur stocké, mais la valeur de l’ID de session doit être vide. La réponse de Dynamic Yield contiendra le nouvel ID de session qui doit être stocké dans l’application.
- Ajoutez les données de l’agent utilisateur de l’application native à la propriété userAgent dans les appels API. Par exemple :
- Pour iOS : <application-name/1.6.4.176 CFNetwork/897.15 Darwin/17.5.0 (iPhone/6s iOS/11.3)>
- Pour Android : <application-name/1.6.7.42 Dalvik/2.1.0 (Linux; U; Android 5.1.1; Android SDK built for x86 Build/LMY48X)
Limites
Bien que l’utilisation de la même section pour le web et l’application mobile offre de nombreuses possibilités d’améliorer la personnalisation inter-appareils, il y a quelques points à noter si vous utilisez cette approche :
- L’identification de l’utilisateur à la fois sur le web et sur l’application ne garantit pas l’adhérence de la variation. La même campagne et la même expérience peuvent être diffusées sur un ordinateur et sur l’application, mais il n’est pas garanti que l’utilisateur tombe dans la même variation sur les deux appareils, car les ID d’utilisateur et de session sont différents.
- Le rapport sur l’URL de localisation dans l’application peut être différent de celui sur le web, car il n’y a pas d’URL à récupérer dans l’application.
- Les rapports de campagne peuvent ne pas être transparents si vous utilisez des campagnes côté client sur le web et des campagnes API sur l’application, car chaque environnement dispose de rapports distincts (ce qui n’est pas le cas si le web et l’application utilisent tous deux des campagnes API).
- L’attribution d’utilisateurs à des audiences qui ont été identifiées avec le même ID sur différents appareils se fait du jour au lendemain (fonctionnalité standard).