Test A/B côté serveur
Table des matières
En bref
L'API Server-side Delivery s'adresse aux équipes de développement internes qui souhaitent intégrer complètement les tests A/B dans leur propre infrastructure. Les variantes sont attribuées côté serveur avant que la page ne soit rendue et livrée - sans aucun JavaScript côté client. Cela élimine le scintillement, donne à l'équipe de développement un contrôle total sur l'implémentation et rend possible le test dans des architectures où un snippet classique côté client ne fonctionne pas : Headless-Setups, applications rendues côté serveur ou applications mobiles natives.
Voici comment cela fonctionne
Crée une nouvelle expérience dans le tableau de bord Varify et sélectionne Expérience côté serveur de.
Tu trouveras ensuite l'expérience dans le tableau de bord, d'où tu pourras contrôler la répartition du trafic et démarrer l'expérience. Tu y trouveras également les ID de l'expérience et les ID de variation, Les données que tu as besoin d'intégrer.
L'intégration se fait via deux points d'accès API que votre équipe de développement intègre directement dans la logique backend existante.
1. créer des utilisateurs POST /ss/{teamId}/users
Lors de la première demande d'un nouveau visiteur, un utilisateur est créé via ce point d'accès. L'API donne une userId (UUID) que votre système doit conserver - par exemple dans un cookie, une session ou votre base de données. Cet ID identifie l'utilisateur lors de toutes les futures requêtes.
Exemple de réponse :
{
"userId": "a9533ef0-bbc4-47a1-90b8-2f2d3bba43a3"
}
2. appeler la variante GET /ss/{teamId}/experiments/{experimentId}/variations/{userId}
Grâce à la mémoire enregistrée userId Avec l'UUID enregistré, vous demandez la variante attribuée pour une expérience concrète. Si aucune variante n'a encore été attribuée, elle sera automatiquement attribuée lors du premier appel. L'attribution est déterministe - le même utilisateur reçoit toujours la même variante pour la même expérience, peu importe le nombre de fois que le point d'accès est appelé.
Exemple de réponse (l'utilisateur s'est vu attribuer une variante) :
{
"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 les ID de la variation attribuée (par exemple. 48838) - tu trouveras ces identifiants dans le tableau de bord de Varify - ou zéro, si l'utilisateur utilise la Variante originale doit voir. Le site tracking-avec le contexte de l'expérience est renvoyé dans les deux cas.
Votre backend décide alors, en fonction de l'ID de variation renvoyé, quelle version de la page ou du contenu doit être rendue et livrée. Dans la logique de votre backend, chaque ID de variation est mappé sur la variante de rendu correspondante. zéro signifie toujours : montrer la version originale.
La configuration de l'expérience elle-même - groupes cibles, répartition du trafic, démarrage et arrêt - continue à être gérée confortablement dans le tableau de bord de Varify.
Documentation pour développeurs
La référence complète de l'API (OpenAPI 3.1) avec tous les points de terminaison, les paramètres et les codes d'erreur pour votre équipe de développement : https://app.varify.io/ss/docs