Zum Hauptinhalt springen

Serverseitiges A/B-Testing

Zuletzt aktualisiert am 09. Sept. 20263 Min. Lesezeit
Inhaltsverzeichnis

Kurz gesagt​

Die serverseitige Delivery API richtet sich an interne Entwicklungsteams, die A/B-Testing vollständig in ihre eigene Infrastruktur integrieren wollen. Varianten werden serverseitig zugewiesen, bevor die Seite gerendert und ausgeliefert wird - ohne clientseitiges JavaScript. Das eliminiert Flackern, gibt dem Entwicklungsteam volle Kontrolle über die Implementierung und macht Testing in Architekturen möglich, in denen ein klassisches clientseitiges Snippet nicht funktioniert: Headless-Setups, serverseitig gerenderte Anwendungen oder native mobile Apps.

So funktioniert es​

Serverseitiges A/B-Testing

Erstelle ein neues Experiment im Varify-Dashboard und wähle Server Side Experiment aus.

Das Experiment findest du anschließend im Dashboard, wo du die Traffic-Verteilung steuern und das Experiment starten kannst. Dort findest du auch die Experiment ID und die Variation IDs, die du für die Integration benötigst.

Die Integration läuft über zwei API-Endpunkte, die dein Entwicklungsteam direkt in die bestehende Backend-Logik integriert.

1. Benutzer anlegen POST /ss/{teamId}/users​

Beim ersten Aufruf eines neuen Besuchers wird über diesen Endpunkt ein Benutzer angelegt. Die API liefert eine userId (UUID), die dein System persistieren muss - zum Beispiel in einem Cookie, einer Session oder deiner Datenbank. Diese ID identifiziert den Benutzer für alle zukünftigen Requests.

Beispiel-Response:

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

2. Variante abrufen GET /ss/{teamId}/experiments/{experimentId}/variations/{userId}​

Mit der gespeicherten userId fragst du mit der gespeicherten UUID die zugewiesene Variante für ein bestimmtes Experiment ab. Wurde noch keine Variante zugewiesen, erfolgt die Zuweisung beim ersten Aufruf automatisch. Die Zuweisung ist deterministisch - derselbe Benutzer erhält für dasselbe Experiment immer dieselbe Variante, unabhängig davon, wie oft der Endpunkt aufgerufen wird.

Beispiel-Response (Benutzer wurde eine Variante zugewiesen):

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

Beispiel-Response (Benutzer erhält die Originale):​

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

Das Feld variation enthält entweder die ID der zugewiesenen Variante (z. B. 48838) - diese IDs findest du im Varify-Dashboard - oder null, wenn der Benutzer die Original-Variante sehen soll. Das tracking-Objekt mit dem Experimentkontext wird in beiden Fällen zurückgegeben.

Dein Backend nutzt anschließend die zurückgegebene Variation-ID, um zu entscheiden, welche Version der Seite oder des Inhalts gerendert und ausgeliefert wird. Ordne dazu jede Variation-ID in deiner Backend-Logik der entsprechenden Rendering-Variante zu - null bedeutet immer: die Originalversion anzeigen.

Die Experimentkonfiguration selbst - Zielgruppen, Traffic-Verteilung, Start und Stopp - lässt sich weiterhin bequem im Varify-Dashboard verwalten.

3. Tracking einrichten​

Damit das Server-Experiment im Dashboard ausgewertet werden kann, muss der tracking-Block aus der Response von GET /ss/{teamId}/experiments/{experimentId}/variations/{userId} clientseitig eingebunden werden:

  • Den Inhalt des tracking-Objekts unverändert als JSON in ein type="application/json" data-varify-tracking>-Tag im gerenderten HTML schreiben.
  • Varify löst dann automatisch die Tracking-Funktionen aus - unter Berücksichtigung des Einwilligungsstatus des Benutzers. Das gilt auch dann, wenn varify.js clientseitig ansonsten überhaupt nicht am Test beteiligt ist; ein manuelles window.varify.setTracking(true) ist dafür nicht nötig.
  • Wird dieser Schritt ausgelassen, ist im Dashboard nur die Experimentkonfiguration sichtbar - keine Auswertungsdaten, da die Delivery API selbst keinen Endpunkt für das Reporting von Events besitzt.

Beispiel-Markup:

Mit der gespeicherten userId fragst du mit der gespeicherten UUID die zugewiesene Variante für ein bestimmtes Experiment ab. Wurde noch keine Variante zugewiesen, erfolgt die Zuweisung beim ersten Aufruf automatisch. Die Zuweisung ist deterministisch - derselbe Benutzer erhält für dasselbe Experiment immer dieselbe Variante, unabhängig davon, wie oft der Endpunkt aufgerufen wird.

Beispiel-Response (Benutzer wurde eine Variante zugewiesen):

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

Sind variation.id und variation.name null (Originalversion), wird der Block trotzdem gerendert - Varify behandelt dies dann als Original-Ausspielung.

Entwicklerdokumentation​

Die vollständige API-Referenz (OpenAPI 3.1) mit allen Endpunkten, Parametern und Fehlercodes für dein Entwicklungsteam: https://app.varify.io/ss/docs

Auf dieser Seite