Feature Flags

Definition: Feature Flags (auch Feature Toggles oder Feature Switches) sind dynamische Konfigurationsschalter in Webanwendungen, die es ermöglichen, bestimmte Funktionen oder Inhalte zur Laufzeit ein- oder auszuschalten – ohne neuen Code deployen zu müssen. Sie trennen das technische Deployment vom fachlichen Release einer neuen Funktion: Code wird ins System deployt, bleibt aber deaktiviert bis zur gezielten Freischaltung. Feature Flags ermöglichen Canary Releases (schrittweises Ausrollen auf kleinen Nutzeranteil), Beta-Programme, Kill Switches bei Fehlern und zielgruppenbasierte Funktions-Freischaltung. Populäre Feature-Flag-Systeme: LaunchDarkly, Split.io, Flagsmith, Unleash, Optimizely Feature Experimentation. Im Marketing-Kontext bilden Feature Flags die technische Grundlage für serverseitiges A/B-Testing und risikoarme Kampagnen-Launches.

Erläuterung

Feature Flags lösen das Deployment-Dilemma: Neue Features landen täglich im Code, werden aber nur kontrolliert für ausgewählte Nutzergruppen aktiviert. Das Risiko von Produktionsfehlern sinkt drastisch, weil ein Flag-Deaktivierung innerhalb von Sekunden rückgängig macht, was ein Re-Deployment Stunden dauern würde. Für Marketing-Teams bedeutet das: Landingpage-Varianten, neue Preismodelle oder Checkout-Flows können ohne IT-Dependency für definierte Segmente getestet werden.

Feature-Flag-Typen

Release Flags (aka Feature Toggles): Kurzlebig; verstecken unfertigen Code bis zum Release; aktivieren neues Feature für alle Nutzer gleichzeitig oder schrittweise; sollten nach vollständigem Rollout aus dem Code entfernt werden; typische Lebensdauer: Tage bis Wochen
Experiment Flags: A/B-Testing und multivariate Tests; weisen Nutzer reproduzierbar Varianten zu (same user = same variant); statistische Auswertung über Flag-Plattform oder externes Tool; Daten-Grundlage für Feature-Entscheidungen; Lebensdauer: Dauer des Tests
Ops Flags (Operations Toggles): Langlebig; steuern Systemverhalten bei Lastspitzen oder Incidents; Beispiel: heavy computation deaktivieren wenn DB-Last kritisch; Kill Switch für externe Dienste (Chatbot, Empfehlungsengine) bei Performance-Problemen; auch als Circuit Breaker bekannt
Permission Flags: Dauerhaft; freischalten von Features für bestimmte Nutzergruppen; Beta-Programme, Enterprise-Features, A/B-Tests für eingeloggte Nutzer; Nutzer-ID oder Attribut (Plan, Region, Kundensegment) als Targeting-Kriterium

Feature-Flag-Plattformen

LaunchDarkly: Marktführer; Enterprise-fokussiert; SDKs für 25+ Sprachen; Targeting-Rules mit beliebigen Nutzerattributen; Experimentation-Modul integriert; Real-Time-Updates ohne App-Neustart; ab 10 USD/Monat (Starter); Data Export für Analytics-Integration
Flagsmith: Open Source (selbst-gehostet) oder SaaS; kostenloser Plan bis 50.000 Requests/Monat; Edge API für <10ms Flag-Evaluation; Remote Config (nicht nur Boolean sondern beliebige Werte); gut für kleine bis mittlere Teams; DSGVO-konform self-hosted
Unleash: Open Source; Enterprise-Version mit SSO und Compliance; Feature Toggle API; Strategie-Plugins (Gradual Rollout, UserID, Custom); gut für Teams mit eigener Infrastruktur; Hosting in EU möglich
Split.io: Fokus auf Feature Flags + Experimentation; Impression Data für Analyse; direkte Integration mit Analytics-Tools; gut geeignet für datengetriebene Marketing-Teams; teurer als Open-Source-Alternativen

Implementierungsmuster

Canary Release: Flag aktiviert Feature für 1 % → 5 % → 20 % → 50 % → 100 % der Nutzer; Metriken (Error Rate, Conversion Rate, Latenz) zwischen Flag-Gruppen vergleichen; automatisches Rollback wenn KPI-Schwellenwert unterschritten; reduziert Blast Radius bei Fehlern erheblich
Dark Launch: Feature läuft im Hintergrund für alle Nutzer aber UI zeigt es nicht; Performance und Korrektheit unter realer Last testen ohne Nutzerimpact; danach UI-Flag aktivieren; besonders sinnvoll für neue Datenbank-Queries oder API-Integrationen
Kill Switch: Flag deaktiviert in Produktion sofort kritisches Feature ohne Deployment; Incident-Response-Zeit von Stunden auf Sekunden reduziert; als Ops Flag dauerhaft im Code – nicht entfernen; muss regelmäßig getestet werden ob er tatsächlich funktioniert
Flag-Hygiene: Technische Schulden entstehen durch vergessene Flags; Stale Flags ab 30+ Tagen markieren; in Pull Request: Flag-Erstellungsdatum als Code-Kommentar; automatische Alerts wenn Flags älter als N Tage; LaunchDarkly zeigt Flag-Alter und letzte Evaluation an

Marketing-Anwendungsfälle

Server-Side A/B-Testing: Flag weist Nutzer serverseitig Varianten zu; kein Client-Side-Flickering wie bei JavaScript-basierten Tests; Varianten-Zuweisung in dataLayer für GA4-Analyse; Checkout-Tests ohne Performance-Impact durch DOM-Manipulation; höhere statistische Reliabilität als Client-Side-Testing
Geo- und Segment-Targeting: Neue Preisseite nur für DE-Nutzer aktivieren; Beta-Checkout nur für eingeloggte Premium-Kunden; Kampagnen-Landingpage nur für Nutzer aus bestimmter Google-Ads-Audience; alles ohne Deployment durch Targeting-Rules in Flag-Plattform
Kampagnen-Launch-Kontrolle: Black-Friday-Landingpage deployen aber Flag-deaktiviert halten; um Mitternacht Flag aktivieren ohne Deployment-Stress; bei Problemen sofortiger Kill Switch; Koordination Marketing / Tech entkoppelt – Marketing aktiviert selbst über Dashboard

Praxistipp: Beginnen Sie mit Flagsmith (Open Source, kostenloser Plan) und implementieren Sie zwei Flags: (1) Kill Switch für kritische externe Dienste (Chatbot, Empfehlungsengine) – deaktivierbar in Sekunden bei Performance-Problemen; (2) Gradual Rollout für den nächsten größeren Checkout-Umbau (Start 5 %, dann 20 %, dann 100 %). Dokumentieren Sie jeden Flag mit Ersteller, Zweck und Ablaufdatum direkt im Flag-Namen (z. B. «checkout-v2-rollout-2026-Q2»). Entfernen Sie Flags konsequent nach vollständigem Rollout – ein Codebase mit 50+ ungenutzten Flags verlangsamt das Debugging und schafft versteckte Abhängigkeiten.