Trois types de tests, un éditeur à l’IA intégrée

Un script dans le head est toute l’installation, et c’est la seule modification apportée à votre site. Ensuite, une variante se construit en pointant des éléments sur vos pages en ligne, si bien que le premier test n’est limité que par le temps qu’il vous faut pour décider quoi tester, et non par quelque chose à acheter, à développer ou à planifier. Rien ne part en ligne par accident pendant que vous apprenez : un nouveau test reste un brouillon jusqu’à ce que vous le démarriez.

Chaque site reçoit son propre fichier compilé, dans lequel ses tests sont intégrés, si bien que le runtime sait déjà quoi exécuter au chargement et que rien n’attend un appel à nos serveurs avant que la page ne s’affiche. Le chargeur présent dans votre page fait moins de 1 Ko, et les fonctionnalités plus lourdes, comme les données de page et les flux de données, ne se chargent que sur les sites dont les tests les utilisent. La page est brièvement retenue pendant l’application des modifications, ce qui empêche les visiteurs de voir l’original basculer vers le test ; elle est révélée par quatre chemins de code indépendants, de sorte qu’une défaillance montre la page non modifiée plutôt qu’une page blanche. Le suivi se charge en dernier, une fois la page visible, si bien que la mesure ne retarde jamais le rendu.

Le texte, le style, la mise en page et la position s’éditent en pointant, états hover et focus compris, et des sections entières s’ajoutent depuis une bibliothèque de composants qui reprennent les polices et les couleurs de votre site. Une modification peut intégrer les données de la page, comme le prix de chaque produit, ou des valeurs issues d’un flux que vous publiez déjà, et un sélecteur peut l’appliquer à tous les éléments correspondants. Vous pouvez aussi décrire la modification en termes simples et laisser l’éditeur IA la proposer, avec un aperçu sur la page avant tout enregistrement. Au-delà, l’éditeur préfère s’arrêter franchement que mal faire : tout ce que l’inspecteur ne sait pas exprimer, vous l’écrivez en CSS ou en JavaScript personnalisés sur la variante, ce qui fait qu’un test n’est jamais bloqué par l’outil. La vraie limite, c’est une modification qui intervient avant que la page n’existe : un classement, une logique de prix, un modèle de recommandation. Ce sont des tests côté serveur, et ils passent par vos développeurs.

Autant que vous avez d’idées, et c’est la réponse qui vaut la comparaison avec ce que vous utilisez aujourd’hui. Chaque test est randomisé indépendamment, si bien qu’un visiteur éligible entre dans tous les tests auxquels il est éligible et que chacun mesure sur l’audience éligible entière. Ici, la simultanéité ne divise pas votre échantillon, et c’est pourquoi la plateforme vérifie si deux tests risquent d’interférer plutôt que de limiter le nombre de tests en cours. La cadence fait généralement la différence entre un programme qui se rentabilise et un programme qui ne se rentabilise pas.

Les gagnants que vous avez codés en dur se trouvent déjà dans votre propre base de code et ne sont pas affectés, et c’est précisément vers cela que la file d’implémentation est là pour vous pousser : elle liste chaque gagnant encore servi par nous et continue de le signaler jusqu’à ce que vos développeurs aient du temps. Les gagnants encore servis par la plateforme s’arrêtent quand elle s’arrête, comme s’arrête n’importe quelle variante. Les tests, les hypothèses et l’historique écrit restent dans le compte plutôt que dans un outil à nous.