Server-Side-Testing & Feature Flags

Nicht jedes Experiment lässt sich sinnvoll im Browser umsetzen. Sobald es um Preise, Backend-Logik oder Feature-Flags geht, ist serverseitiges Testen die bessere Wahl. Splitwave unterstützt beides – und hält beide Welten synchron.

Client-Side vs. Server-Side

Beim clientseitigen Testen entscheidet das Snippet im Browser, welche Variante ein Besucher sieht. Das ist ideal für sichtbare Änderungen: Texte, Layout, Buttons.

Beim serverseitigen Testen entscheidet dein Backend. Das ist nötig, wenn die Änderung tief im System sitzt – etwa eine andere Preislogik, ein anderer Algorithmus oder ein Feature, das nur für einen Teil der Nutzer aktiv ist.

Warum Konsistenz entscheidend ist

Wenn Client und Server unterschiedlich „würfeln", sieht ein Besucher womöglich serverseitig Variante A, clientseitig aber Variante B. Das verfälscht jede Auswertung.

Splitwave löst das über identisches Bucketing: Der Server nutzt denselben FNV-1a-Hash wie das Snippet, zeichengenau. Derselbe Besucher landet überall in derselben Variante.

Die Feature-API

Zwei Endpunkte genügen:

• POST /v1/decide liefert die Variantenentscheidung für einen Besucher – authentifiziert per Bearer-Token mit dem Secret-Key des Projekts.
• POST /v1/track meldet Conversions zurück.

So baust du Feature-Flags und hybride Experimente: serverseitige Entscheidung, clientseitige Darstellung – konsistent dank gemeinsamem Bucketing.

Wann serverseitig testen?

• Preise und Rabatte, die nicht im Frontend manipulierbar sein sollen.
• Algorithmen wie Such- oder Empfehlungslogik.
• Feature-Rollouts für einen definierten Nutzeranteil.
• Sensible Flows, bei denen Flackern oder Manipulation inakzeptabel sind.

Fazit

Server-Side-Testing erweitert A/B-Testing über die Oberfläche hinaus. Mit identischem Bucketing bleibt die Zuteilung verlässlich – die Voraussetzung für belastbare Ergebnisse.