Staged Rollout ist ein Google-Play-Release-Mechanismus, der eine neue App-Version an einen konfigurierbaren Prozentsatz der Nutzer ausliefert, bevor der vollständige Rollout erfolgt. Der Entwickler legt den anfänglichen Prozentsatz fest (häufig 1 % oder 5 %), überwacht die Crash-free-Rate und andere Qualitätskennzahlen und erhöht den Prozentsatz schrittweise (z. B. 5 % → 20 % → 50 % → 100 %) über Stunden bis Tage. Wenn ein kritisches Problem während des Rollouts erkannt wird, kann der Entwickler den Rollout stoppen und so verhindern, dass der fehlerhafte Build weitere Nutzer erreicht.
Typische Staged-Rollout-Kadenz
- 1–5 %: erste 24–48 Stunden. Crash-free-Rate, ANR-Rate, Conversion der wichtigsten Flows prüfen. Pausieren, wenn eine Regression > 0,1 % festgestellt wird.
- 5–20 %: nächste 24–48 Stunden. Breitere Distribution validiert, dass der Build über mehr Gerät- und Regionskombinationen hinweg performt.
- 20–50 %: nächste 2–3 Tage. Zu diesem Zeitpunkt haben sich schwerwiegende Regressionen gezeigt. Fortsetzen, wenn Kennzahlen stabil sind.
- 50–100 %: finaler Hochlauf. Vollständiger Rollout innerhalb von 5–7 Tagen nach dem initialen Release abschließen.
Apples Äquivalent: "Phased Release" in App Store Connect. Dasselbe Konzept, leicht unterschiedliche Implementierung. Apples Phased Release folgt einem festen 7-Tage-Zeitplan (1 % → 2 % → 5 % → 10 % → 20 % → 50 % → 100 %) mit automatischen täglichen Erhöhungen. Weniger granulare Kontrolle als Googles prozentbasiertes System, aber der zugrundeliegende Zweck ist identisch.
Kritische Fähigkeit: die Möglichkeit, einen Rollout zu stoppen. Wenn die Crash-free-Rate sinkt, die ANR-Rate in die Höhe schießt oder eine wichtige Conversion-Kennzahl zurückgeht, stoppt der Entwickler den Rollout über die Play Console. Der Build bleibt für Nutzer verfügbar, die bereits aktualisiert haben, aber keine neuen Nutzer erhalten ihn. Ein Hotfix-Release kann dann als neuer Rollout eingesetzt werden und den fehlerhaften ersetzen.