Full-Stack : déployer une expérience client cross-canal & multi-device optimale grâce aux SDK

À mesure que l'A/B testing et les pratiques d’expérimentation font leurs preuves, de plus en plus de marques commencent à optimiser non seulement leur UX en front-end, mais également les fonctionnalités back-end de leurs produits digitaux.

Cependant, expérimenter sur un environnement back-end, par exemple pour tester de nouvelles fonctionnalités sur un site web, demande souvent de nombreux développements personnalisés. Ces cycles de développement longs impactent la cadence de vos tests et ralentissent l’analyse de la data et la collecte d’insights. 

Les SDK (Software Development Kit) permettent d’accélérer ce processus de développement. Dans une solution d’A/B testing full-stack comme Kameleoon, les SDK offrent aux équipes tech tous les outils et l'infrastructure nécessaires pour créer et déployer rapidement des tests sur tous types de canaux.

Les SDK offrent ainsi la possibilité de réaliser des expériences directement sur vos applications mobiles, desktop et web. Ils permettent des expérimentations très précises sur vos produits, en intégrant l’ensemble des touch points des différents canaux à votre programme de testing. Grâce aux SDK, il devient possible de mettre en place tout type d'expériences (côté serveur, sur app mobile ou sur une application web par exemple) et quel que soit le canal utilisé par le visiteur.

1 Qu'est-ce qu'un SDK ?

Les Software Development Kits, également connus sous le nom de devkits, sont des packs qui permettent à deux solutions de travailler ensemble simultanément.

Par exemple :

Supposons que votre solution dispose d'une application iPhone et d’une application Android, et que vous vouliez tester une nouvelle fonctionnalité ou expérience utilisateur sur celles-ci.

À présent :

• Votre application Android tourne probablement sur Java ou Kotlin (qui a remplacé Java en tant que langage officiel pour le développement d'applications Android). Votre app pourrait aussi utiliser C++, C#, ou Python.
• De l'autre côté, le langage de programmation de votre application iOS pourrait être Swift ou Objective-C.
• Vos applications pourraient aussi utiliser des frameworks comme React Native or Node.js.
   

Si vous souhaitez utiliser un outil d'A/B testing pour tester vos expérimentations sur vos applications mobiles, vous avez besoin que celui-ci fonctionne correctement avec les technologies sur lesquelles reposent vos applications, à savoir leur frameworks et leurs langages de programmation.

LES SDK SONT UNE COUCHE INTERMÉDIAIRE QUI FACILITE CETTE INTERCONNEXION

Les SDK fonctionnent comme une sorte de couche intermédiaire entre votre solution d’A/B testing et l'environnement de production de votre test – dans ce cas précis, vos applications. Ils font le lien entre votre solution d'expérimentation et le canal de production (serveur applicatif, application mobile ou application web) où auront réellement lieu vos expérimentations.

Les SDK offrent à vos développeurs tous les composants (API, bibliothèques, éditeurs, compilateurs, outils de débogage, exemples de code et documentation) dont ils ont besoin pour déployer rapidement vos expérimentations sur l'ensemble de vos canaux et plateformes.

Les solutions conçues pour les développeurs proposent en général des SDK activement maintenus à jour pour prendre en charge les technologies les plus courantes (langages de programmation, frameworks et plateformes) qu'utilisent leurs clients.
 

2 Comment fonctionnent les SDK (et pourquoi ils vous permettent de mettre en place tout type d’expérience)

Une fois que vous avez installé et lancé le SDK de votre solution d'expérimentation, il est très facile de mettre en place des A/B tests.

Si vous souhaitez créer une expérimentation sur application iOS à l'aide d'une solution telle que Kameleoon, vous trouverez l'ensemble du code et des méthodes/fonctions dont vous avez besoin directement dans notre SDK iOS.

Tout ce qu'il vous reste à faire est de coder les expériences que vous souhaitez tester puis d’effectuer un mapping des instances et propriétés nécessaires entre votre application et Kameleoon. Le code permettant de faire fonctionner les deux systèmes ensemble est déjà intégré dans le SDK.

Voici globalement comment cela fonctionne (après les étapes d'installation et de lancement du SDK) :

1) Le tableau de bord Kameleoon vous permet de créer un nouveau test

2) Le SDK iOS de Kameleoon vous fournit le code pour activer votre expérimentation (disponible via la méthode triggerExperiment())

3) Pour gérer l'affichage des différentes variations et leur code associé, vous devez sélectionner leurs ID via le tableau de bord de Kameleoon et les insérer dans le code de l'application grâce à de simples mécanismes if...else ou switch.

La documentation proposée avec le devkit contient des exemples de code et des recommandations pour vous aider lors de ces étapes.

4) Une fois le code de votre A/B test défini, vous pouvez utiliser la méthode trackConversion() du SDK iOS pour suivre vos conversions

Elles seront consignées dans Kameleoon de manière automatique. Kameleoon offre également des passerelles avec Segment.io, qui peuvent être entièrement automatisées grâce à notre Segment Destination Bridge.

5) Pour finir, vous trouverez un reporting de vos expérimentations directement dans les dashboards de Kameleoon, comme pour vos A/B tests classiques, en front-end

Dans la plupart des cas, le tableau de bord de votre solution d'expérimentation doit vous permettre de lancer, mettre en pause et arrêter facilement vos tests, quels que soient les canaux sur lesquels ils sont réalisés.

Les SDK simplifient le processus d’expérimentation sur différents canaux. Ils font le lien entre votre solution d'A/B testing et les technologies de votre environnement cible afin que vos campagnes de testing soient bien orchestrées.

SDK ou API ? 
L’usage des SDK pour permettre à deux solutions de fonctionner ensemble diffère profondément des API, dont le rôle est uniquement de faciliter les échanges de données entre deux solutions. Les SDK n'ont pas d'impact sur la latence car ils n'utilisent pas d'appels bloquants, contrairement aux API.

3 Tous les SDK ne se valent pas

Bien que tous les SDK offrent plus ou moins les mêmes composants, tous les SDK ne se valent pas. Voici quelques points à prendre en compte :

• Performance : comme tout code source lourd, même les SDK peuvent créer des problèmes de performance. Ils peuvent entraîner des latences si la mémoire et l'utilisation du réseau ne sont pas optimisées. Avant de choisir un logiciel d'expérimentation, vérifiez qu'il a une empreinte faible ; c’est encore mieux s'il a une politique de latence zéro.
• Documentation : la qualité de la documentation d’un SDK est essentielle. Elle vous permettra d’évaluer la facilité de l’intégration et de développement. Étudier l'exemple de code fourni dans la documentation d'un SDK et la gestion des exceptions peut vous faire gagner un temps précieux.
• Maintenance et mises à jour régulières : si les SDK ne sont pas compatibles avec les dernières versions (voire la toute dernière en date) de la plateforme ou des technologies sur lesquelles repose votre solution, ils ne seront d'aucune utilité. Il est important de consulter les changelogs du SDK de votre solution d'expérimentation potentielle pour savoir dans quelle mesure elle est correctement maintenue. Les correctifs de bugs et améliorations sont également des signes permettant d'identifier de bons SDK.

4 Quels SDK choisir pour votre programme d’optimisation de l’expérience client ?

D'une manière générale, il existe trois types de SDK lorsqu'on parle d'expérimentation : les SDK mobiles, les SDK client-side et les SDK server-side. On peut considérer que les SDK mobiles et client-side appartiennent à la même catégorie.

Les SDK client-side sont intégrés et fonctionnent directement dans les applications qu'utilisent vos utilisateurs, y compris vos applications web, mobiles et desktop. C'est pour cette raison que les SDK mobiles sont également considérés comme des SDK client-side. Des exemples classiques de SDK d'expérimentation client-side sont JavaScript, React, and Angular.

Les SDK server-side se trouvent quant à eux dans votre stack technologique (du côté du serveur ou des services que vous utilisez côté serveur). Ils sont intégrés à votre infrastructure technique back-end. Parmi les SDK d'expérimentation server-side on peut citer .NET, Node.js et Java.

Il existe un certain nombre de SDK mobiles, client-side et server-side courants qu'un outil d'expérimentation doit prendre en charge :

• Android (Kotlin/Java)
• iOS (Swift)
• Flutter
• Java
• C#
• PHP
• NodeJS
• Ruby
• Python
• Go
• JavaScript / TypeScript (ReactJS, Angular, Vue)

5 Les SDK nécessitent des mises à jour et une maintenance régulières

Évaluer la qualité des SDK lors du choix d'une solution d'A/B testing ou d'expérimentatio

Les équipes produit et développement travaillent en back-end, à l'inverse des marketers qui utilisent les solutions d'expérimentation front-end pour tester des éléments en surface, tels que la disposition d’une page, un contenu spécifique, etc… Les product owners et développeurs ont, eux, besoin d’évaluer la pertinence d’un algorithme de recherche, d’utiliser une fonction d'implémentation différente ou bien encore lancer une fonctionnalité à laquelle ils viennent juste de penser.

Les équipes tech demandent plus qu’un simple éditeur graphique ou éditeur de code qui leur permettrait d'injecter facilement du HTML/CSS. Pour elles, la valeur ajoutée d'une solution d’A/B testing réside dans sa capacité à s'affranchir des navigateurs, pour mener des expérimentations en profondeur, sur tous les environnements.

SDK = TESTS DÉPLOYÉS PLUS RAPIDEMENT SUR DIFFÉRENTS CANAUX

Les entreprises orientées produit qui réalisent des expérimentations régulièrement recherchent des solutions d'expérimentation conçues pour les développeurs, avec des SDK qui permettent de maintenir une bonne vitesse d'exécution des tests tout en contrôlant leurs coûts.

Les SDK permettent alors à ces équipes de lancer et de déployer sans effort des expérimentations multi-canal et multi-environnement en se déchargeant de tout le travail préparatoire.