Experimente auch im Backend
Triff Variantenentscheidungen serverseitig – zeichengenau identisch zum clientseitigen Snippet.
POST /v1/decide
{ "visitor_id": "a1b2-c3d4", "experiment": "pricing-cta" }
→ 200 OK
{
"variation": "variant-b",
"bucketing": "fnv1a",
"in_experiment": true
}
✓ zeichengenau identisch zum Client-Snippet
Das kann diese Funktion
- REST-Endpunkte /v1/decide und /v1/track mit Bearer-Authentifizierung.
- Identisches FNV-1a-Bucketing wie im Snippet – Client und Server bleiben synchron.
- Ideal für Feature-Flags und hybride Experimente.
- Programmatischer Ergebnis-Zugriff über die Results-API.
Das Problem
Preise, Algorithmen und Feature-Flags lassen sich im Browser nicht sauber testen.
Die Lösung
Die Feature-API trifft Entscheidungen serverseitig – mit identischem Bucketing zum Snippet, sodass Client und Server synchron bleiben.
Bleiben client- und serverseitige Zuteilung konsistent?
Ja. Server und Snippet nutzen denselben FNV-1a-Hash, daher landet ein Besucher überall in derselben Variante.
Häufige Fragen dazu
Bleiben Client- und Server-Entscheidungen synchron?
Ja. Der Server nutzt dasselbe FNV-1a-Bucketing wie das Snippet – zeichengenau identisch. Ein Besucher erhält client- wie serverseitig dieselbe Variante.
Wie sichere ich die API ab?
Die Endpunkte /v1/decide und /v1/track nutzen Bearer-Authentifizierung mit dem projektbezogenen Secret-Key. Ergebnisse liest du per Token-gesicherter Results-API.
Eignet sich das für Feature-Flags?
Ja. Server-Side-Decisions sind ideal für Feature-Flags und hybride Experimente, bei denen Backend und Frontend dieselbe Zuteilung brauchen.
Starte dein erstes Experiment in Minuten
Snippet einbauen, Variante bauen, Ergebnisse messen – ohne Entwickler, ohne Cookies.