Server-Side A/B Testing
Inhaltsverzeichnis
Kurz & Knapp
Die Server-side Delivery API richtet sich an Inhouse-Entwicklerteams, die A/B-Tests vollständig in ihre eigene Infrastruktur integrieren möchten. Varianten werden serverseitig zugewiesen, bevor die Seite gerendert und ausgeliefert wird – ganz ohne clientseitiges JavaScript. Das eliminiert Flackern, gibt dem Entwicklungsteam volle Kontrolle über die Implementierung und macht Testing in Architekturen möglich, wo ein klassisches Client-Side-Snippet nicht funktioniert: Headless-Setups, serverseitig gerenderte Applikationen oder native Mobile Apps.
So funktioniert es
Lege ein neues Experiment im Varify Dashboard an und wähle Server Side Experiment aus.
Danach findest du das Experiment im Dashboard und von dort aus kannst du die Traffic Verteilung steuern und das Experiment starten. Dort findest du ebenfalls die Experiment ID und die Variation IDs, die du zur Integration benötigst.
Die Integration läuft über zwei API-Endpoints, die euer Entwicklungsteam direkt in die bestehende Backend-Logik einbaut.
1. Nutzer anlegen POST /ss/{teamId}/users
Beim ersten Request eines neuen Besuchers wird über diesen Endpoint ein Nutzer angelegt. Die API gibt eine userId (UUID) zurück, die euer System persistieren muss – zum Beispiel in einem Cookie, einer Session oder eurer Datenbank. Diese ID identifiziert den Nutzer bei allen zukünftigen Requests.
Response-Beispiel:
{
"userId": "a9533ef0-bbc4-47a1-90b8-2f2d3bba43a3"
}
2. Variante abrufen GET /ss/{teamId}/experiments/{experimentId}/variations/{userId}
Mit der gespeicherten userId fragt ihr für ein konkretes Experiment die zugewiesene Variante ab. Ist noch keine Variante zugewiesen, wird sie beim ersten Aufruf automatisch zugeteilt. Die Zuweisung ist deterministisch – derselbe Nutzer bekommt für dasselbe Experiment immer dieselbe Variante, egal wie oft der Endpoint aufgerufen wird.
Response-Beispiel (Nutzer hat Variante zugewiesen bekommen):
{
"variation": 48838,
"tracking": {
"experiment": {
"id": 32596,
"name": "Homepage CTA Test"
},
"variation": {
"id": 48838,
"name": "variation-1"
}
}
}
Response-Beispiel (Nutzer bekommt die Originale ausgespielt):
{
"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 Variation (z.B. 48838) – diese IDs findest du im Varify-Dashboard – oder null, wenn der Nutzer die Originalvariante sehen soll. Das tracking-Objekt mit Experiment-Kontext wird in beiden Fällen mit zurückgegeben.
Euer Backend entscheidet dann anhand der zurückgegebenen Variation-ID, welche Version der Seite oder des Inhalts gerendert und ausgeliefert wird. Mappt dazu in eurer Backend-Logik jede Variation-ID auf die entsprechende Rendering-Variante – null bedeutet immer: zeige die Originalversion.
Die Experiment-Konfiguration selbst – Zielgruppen, Traffic-Verteilung, Start und Stop – verwaltet ihr weiterhin bequem im Varify-Dashboard.
Entwickler Dokumentation
Die vollständige API-Referenz (OpenAPI 3.1) mit allen Endpoints, Parametern und Fehlercodes für euer Entwicklungsteam: https://app.varify.io/ss/docs