Trois types de tests, un éditeur visuel

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é, ses tests intégrés dedans, si bien que le runtime sait déjà quoi exécuter au chargement et que rien n’attend un appel vers nous avant que la page ne s’affiche. La page est brièvement retenue pendant l’application des modifications, et c’est ce qui empêche les visiteurs de voir l’original apparaître avant le test ; elle est révélée par quatre chemins de code indépendants, si bien qu’une défaillance montre la page non modifiée plutôt qu’une page blanche. La mesure se charge en dernier, une fois la page visible, si bien qu’elle ne retarde jamais le rendu.

Le texte, le style, la mise en page et la position s’éditent en pointant, et les modifications de structure sont couvertes par cinq emplacements HTML autour de l’élément que vous sélectionnez. Au-delà, il s’arrête honnêtement plutôt que mal : tout ce que le panneau 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 l’existence de la page : un classement, une logique de prix, un modèle de recommandation. Ce sont des tests côté serveur, et ils demandent 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 randomise indépendamment, si bien qu’un visiteur éligible entre dans tous les tests pour lesquels il se qualifie et que chacun mesure sur l’audience éligible entière. La simultanéité ne divise pas votre échantillon ici, et c’est pourquoi la plateforme vérifie si deux tests risquent d’interférer plutôt que de rationner combien peuvent tourner. La cadence fait généralement la différence entre un programme qui se paie lui-même et un programme qui ne se paie 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 existe pour vous pousser : elle liste chaque gagnant encore servi par nous et continue de le signaler jusqu’à ce que vos développeurs aient de la place. 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 outillage à nous.