Backend Engineering, Produkt
B2B-Marktplatz
2022-2024
Ein B2B-Marktplatz musste UI-Varianten, Backend-Verhalten und ganze Features testen, ohne separate Codepfade zu deployen oder eine Drittanbieter-Experimentierplattform zu kaufen. Der bestehende Stack war ein Django-Monolith. Die Lösung: django-waffle Flags mit prozentualer Ausrollung, besucherbasierter Persistenz und einer benutzerdefinierten Admin-Oberfläche, die dem Produktteam erlaubt, Experimente in Sekunden umzuschalten.
Die Plattform hatte keine Experimentierinfrastruktur. Jede Änderung war ein vollständiger Deploy. Rollbacks erforderten einen weiteren Deploy. Es gab keine Möglichkeit, Feature X 20% der Besucher zu zeigen und den Unterschied zu messen. Das Produktteam wollte Kontaktformular-Layouts, Preisanzeigen und Onboarding-Abläufe A/B-testen. Eine vollständige Experimentierplattform zu bauen lag außerhalb des Umfangs. Die Lösung musste innerhalb des bestehenden Django-Stacks ohne zusätzliche Infrastruktur funktionieren.
Jeder Deploy war eine Alles-oder-Nichts-Wette. Feature Flags verwandelten Deploys in Experimente mit Rollback-Button.
django-waffle bietet Feature Flags, die pro Nutzer, pro Gruppe oder als Prozentsatz aller Requests umgeschaltet werden können. Das System bindet die Flag-Auswertung an die Visitor-Tracking-Middleware: Jeder Besucher erhält einen deterministischen Hash, und der Prozentschwellenwert des Flags entscheidet, ob er Variante A oder B sieht. Einmal zugewiesen, sieht der Besucher dieselbe Variante für seine gesamte Session. Der Flag-Status wird über einen Context Processor in jedes Template injiziert, was Template-Conditionals ohne Python-Änderungen ermöglicht. Dieselben Flags steuern Backend-Verhalten über Python-Level-Checks.
Der benutzerdefinierte FlagAdmin mit Inline-Toggles:
class FlagAdmin(WaffleFlagAdmin):
list_display = [
'name',
'everyone',
'percent',
'superusers',
'staff',
'authenticated',
'note',
'created',
'modified',
]
list_editable = [
'everyone',
'percent',
'superusers',
'staff',
'authenticated',
'note',
]
list_filter = ['everyone', 'superusers', 'staff']Ein Live-Flag-Simulator. Flag umschalten, Ausrollungs-Prozentsatz anpassen und beobachten, wie Besucher in Echtzeit Varianten zugewiesen werden.
Template-Level Flag-Conditionals:
{# base template — contact form A/B test #}
{% load waffle_tags %}
{% flag "show_new_contact_form" %}
{# Variant B: simplified form #}
{% include "contact/_form_v2.html" %}
{% else %}
{# Variant A: original form #}
{% include "contact/_form_v1.html" %}
{% endflag %}Neue Features starten bei 0% und steigen stufenweise: 5% für internes QA, 10% für frühe Signale, 50% für statistische Signifikanz, 100% für vollen Launch. Jede Stufe läuft für eine definierte Periode mit Monitoring. Wenn die Conversion sinkt oder Fehlerraten steigen, rollt das Flag sofort auf 0% zurück - kein Deploy nötig.
Jedes Flag hat ein zugehöriges Ticket mit Ablaufdatum. Nach Abschluss eines Tests wird die gewinnende Variante zum Standard-Codepfad und das Flag entfernt. Tote Flags werden über auskommentierte Model-Felder nachverfolgt, die als historischer Nachweis vergangener Experimente dienen. Das verhindert Flag-Ansammlung und hält die Codebasis lesbar.
Dasselbe Waffle-Flag steuert sowohl die Template-Ausgabe als auch die Python-Logik. Wenn Variante B ein anderes Kontaktformular-Layout zeigt, prüft auch der Backend-Endpoint, der das Formular verarbeitet, das Flag, um variantenspezifische Validierungsregeln anzuwenden. Das verhindert Inkonsistenzen, bei denen das Frontend eine Variante zeigt, aber das Backend eine andere erwartet.
Das Flag-System führte 14 A/B-Tests über 18 Monate durch. Die neue Kontaktformular-Variante steigerte die Conversion um 23%. Eine vereinfachte Preisanzeige reduzierte die Absprungrate um 11%. Drei vorgeschlagene Features wurden vor der vollständigen Entwicklung eingestellt, weil frühe Flag-Daten kein Nutzerinteresse zeigten. Durchschnittliche Zeit von der Idee zum Live-Experiment: 2 Stunden. Durchschnittliche Rollback-Zeit: 30 Sekunden. Null experimentbezogene Vorfälle.
"Früher haben wir wochenlang über Features diskutiert. Jetzt liefern wir beide Versionen, lassen 500 Besucher entscheiden und machen weiter. Drei Features, von denen wir überzeugt waren, erwiesen sich als wertlos. Die Daten haben uns Monate verschwendeter Entwicklung gespart."
Product Manager
B2B-Marktplatz · Produktteam