• Mots clés populaires

    Article d'assistance

    Total Résultats

    No Record Found

    View All Results

    • 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

    Test A/B côté serveur

    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.

    3. Configurer le suivi

    Pour que l'expérience serveur puisse être analysée dans le tableau de bord, il faut que le tracking-Bloc extrait de la réponse de GET /ss/{teamId}/experiments/{experimentId}/variations/{userId} être intégrés côté client :

    • Le contenu du tracking-Objet inchangé au format JSON dans un <script type="application/json" data-varify-tracking>Écrire la balise -Tag dans le code HTML généré.
    • Varify se charge ensuite automatiquement d'activer les fonctions de suivi, en tenant compte du statut de consentement de l'utilisateur. Cela vaut également lorsque varify.js côté client, qui ne participe d'ailleurs pas du tout au test ; une opération manuelle window.varify.setTracking(true) Ce n'est pas nécessaire.
    • Si cette étape n'est pas effectuée, seule la configuration de l'expérience reste visible dans le tableau de bord ; aucune donnée d'analyse n'apparaît, car l'API Delivery ne dispose pas elle-même d'un point de terminaison permettant de signaler des événements.

    Exemple de balisage :

    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) :

    				
					<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 la variation.name zéro (variante originale), le bloc est tout de même affiché – Varify l'interprète alors comme une diffusion originale.

    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

  • Documentation utilisateur
    Premiers pas