Aller au contenu principal

Tests A/B côté serveur

Dernière mise à jour le 09 sept. 20263 min de lecture
Table des matières

En bref​

L'API de delivery côté serveur s'adresse aux équipes de développement internes qui souhaitent intégrer entièrement les tests A/B dans leur propre infrastructure. Les variantes sont assignées côté serveur avant le rendu et la livraison de la page - sans aucun JavaScript côté client. Cela élimine le flickering, donne à l'équipe de développement un contrôle total sur l'implémentation et rend les tests possibles dans des architectures où un snippet client classique ne fonctionne pas : configurations headless, applications rendues côté serveur ou applications mobiles natives.

Comment ça fonctionne​

Tests A/B côté serveur

Crée une nouvelle expérimentation dans le dashboard Varify et sélectionne Server Side Experiment.

Tu retrouveras ensuite l'expérimentation dans le dashboard, à partir duquel tu peux contrôler la répartition du trafic et démarrer l'expérimentation. Tu y trouveras également l'Experiment ID et les Variation IDs, nécessaires à l'intégration.

L'intégration se fait via deux endpoints API, que ton équipe de développement intègre directement dans la logique backend existante.

1. Créer un utilisateur POST /ss/{teamId}/users​

Lors de la première requête d'un nouveau visiteur, un utilisateur est créé via cet endpoint. L'API fournit un userId (UUID), que ton système doit persister - par exemple dans un cookie, une session ou ta base de données. Cet ID identifie l'utilisateur pour toutes les requêtes futures.

Exemple de réponse :

{
  "userId": "a9533ef0-bbc4-47a1-90b8-2f2d3bba43a3"
}

Appeler la 2e variante GET /ss/{teamId}/experiments/{experimentId}/variations/{userId}​

Avec le userId enregistré, utilise l'UUID sauvegardé pour interroger la variante assignée pour une expérimentation spécifique. Si aucune variante n'a encore été assignée, elle sera assignée automatiquement lors du premier appel. L'assignation est déterministe - le même utilisateur reçoit toujours la même variante pour la même expérimentation, quel que soit le nombre d'appels de l'endpoint.

Exemple de réponse (une variante a été assignée à l'utilisateur) :

{
  "variation": 48838,
  "tracking": {
    "experiment": {
      "id": 32596,
      "name": "Homepage CTA Test"
    },
    "variation": {
      "id": 48838,
      "name": "variation-1"
    }
  }
}

Exemple de réponse (l'utilisateur reçoit les originaux) :​

{
  "variation": null,
  "tracking": {
    "experiment": {
      "id": 32596,
      "name": "Homepage CTA Test"
    },
    "variation": {
      "id": null,
      "name": null
    }
  }
}

Le champ variation contient soit l'ID de la variation assignée (par ex. 48838) - tu trouveras ces IDs dans le dashboard Varify - soit null, si l'utilisateur doit voir la variante Originale. L'objet tracking avec le contexte de l'expérimentation est retourné dans les deux cas.

Ton backend utilise ensuite l'ID de variation retourné pour décider quelle version de la page ou du contenu est rendue et livrée. Pour cela, associe chaque ID de variation à la variante de rendu correspondante dans ta logique backend - null signifie toujours : afficher la version originale.

La configuration de l'expérimentation elle-même - groupes cibles, répartition du trafic, démarrage et arrêt - peut toujours être gérée facilement dans le dashboard Varify.

3. Configurer le tracking​

Pour garantir que l'expérimentation serveur puisse être analysée dans le dashboard, le bloc tracking de la réponse de GET /ss/{teamId}/experiments/{experimentId}/variations/{userId} doit être intégré côté client :

  • Écris le contenu de l'objet tracking inchangé en JSON dans une balise type="application/json" data-varify-tracking> dans le HTML rendu.
  • Varify déclenche ensuite automatiquement les fonctions de tracking - en tenant compte du statut de consentement de l'utilisateur. Cela s'applique également lorsque varify.js n'est autrement pas du tout impliqué côté client dans le test ; un window.varify.setTracking(true) manuel n'est pas nécessaire dans ce cas.
  • Si cette étape est omise, seule la configuration de l'expérimentation sera visible dans le dashboard - aucune donnée d'évaluation, car l'API Delivery elle-même ne dispose pas d'un endpoint pour le reporting d'événements.

Exemple de balisage :

Avec le userId enregistré, utilise l'UUID sauvegardé pour interroger la variante assignée pour une expérimentation spécifique. Si aucune variante n'a encore été assignée, elle sera assignée automatiquement lors du premier appel. L'assignation est déterministe - le même utilisateur reçoit toujours la même variante pour la même expérimentation, quel que soit le nombre d'appels de l'endpoint.

Exemple de réponse (une variante a été assignée à l'utilisateur) :

<script type="application/json" data-varify-tracking>
{
  "experiment": {
    "id": 32596,
    "name": "Homepage CTA Test"
  },
  "variation": {
    "id": 48838,
    "name": "variation-1"
  }
}
</script>

Si variation.id et variation.name sont null (version originale), le bloc est tout de même rendu - Varify le traite alors comme une lecture de l'original.

Documentation développeur​

La référence API complète (OpenAPI 3.1) avec tous les endpoints, paramètres et codes d'erreur pour ton équipe de développement : https://app.varify.io/ss/docs

Sur cette page