Die Root-Cause-Analyse sucht die Ursache eines konkreten Problems, damit eine Korrektur am Auslöser ansetzt und die Wirkung überprüft werden kann. Im Deutschen heißt sie Ursachenanalyse oder Ursachenforschung. Wenn beispielsweise die Conversion-Rate eines Shops fällt, reicht es nicht, den Rückgang zu beschreiben: Entscheidend ist, an welcher Stelle, seit wann und unter welchen Bedingungen Käufe ausbleiben.
Für eine belastbare Ursachenanalyse werden Kennzahlen, Zeitverlauf, betroffene Segmente und mögliche Änderungen zusammengeführt. Methoden wie 5-Why, Ishikawa-Diagramm und Fehlerbaumanalyse helfen beim Ordnen der Hypothesen; Daten und Gegenproben entscheiden, welche Erklärung trägt. Das folgende Beispiel zeigt den Ablauf an einem fiktiven Einbruch im Checkout.
Quelle: datenbasiert.de
Was ist eine Root-Cause-Analyse?
Eine Root-Cause-Analyse ist ein strukturiertes Verfahren, um von einer beobachteten Abweichung zu den Bedingungen vorzudringen, die sie verursacht haben. Der Ausdruck Root Cause bezeichnet die Grundursache. Ein operativer Fehler kann mehrere Ursachen haben: Eine fehlerhafte Einstellung löst den Vorfall aus, ein fehlender Test lässt ihn unentdeckt, und eine unklare Zuständigkeit verzögert die Behebung. Eine gute Analyse macht diese Ursachenkette sichtbar, statt eine einzige Person oder einen einzelnen Klick zum ganzen Problem zu erklären.
Ein Symptom von seiner Ursache unterscheiden
Eine sinkende Conversion-Rate ist zunächst ein Symptom. „Weniger Käufe“ wiederholt die Beobachtung; „zu wenig attraktive Angebote“ ist bereits eine ungetestete Vermutung. Ein konkreter Befund wäre dagegen: Nach einer Änderung am mobilen Zahlungsformular steigt die Fehlerrate der Kartenautorisierung, während die Zahl der gestarteten Checkouts stabil bleibt. Aus Befund und zeitlichem Zusammenhang entsteht eine prüfbare Ursachehypothese.
Eine kurzfristige Maßnahme und eine dauerhafte Korrektur können verschieden sein. Das Zurücksetzen einer fehlerhaften Version stellt den Checkout wieder her. Um denselben Fehler künftig früher zu erkennen, werden anschließend etwa automatische Tests für Zahlungsarten und ein Alarm bei steigenden Zahlungsfehlern eingerichtet. Die Ursachenanalyse verbindet den beobachteten Schaden mit beiden Entscheidungen.
Wann ist eine Ursachenanalyse nötig?
Eine Ursachenanalyse lohnt sich bei einem wiederkehrenden Fehler, einer plötzlichen KPI-Abweichung oder einem Vorfall mit spürbaren Folgen für Kunden und Betrieb. Besonders wichtig ist sie, wenn eine schnelle Korrektur das sichtbare Problem zwar beseitigt, aber unklar bleibt, weshalb es überhaupt entstand. Ausgangspunkt ist eine genaue Frage: Warum sind seit Dienstagabend mobile Käufe zurückgegangen? Mit dieser Eingrenzung lassen sich Daten, Ereignisse und Verantwortlichkeiten gezielt prüfen.
Eine KPI-Abweichung zuerst richtig einordnen
Eine Kennzahl braucht einen passenden Bezugswert. Die Conversion-Rate ist das Verhältnis von Conversions zu den betrachteten Besuchen, Nutzern oder Prozessstarts. Welche Grundgesamtheit verwendet wird, muss im Vergleich gleich bleiben. Bei einem Checkout ist „Käufe pro gestartete Checkouts“ präziser für die Fehlersuche als „Käufe pro Website-Besuche“: Die zweite Kennzahl kann bereits durch eine veränderte Kampagne oder andere Besucherstruktur fallen. Die Grundlagen zu Zähler, Nenner und Zielhandlung stehen im Beitrag über Conversions.
Vergleiche denselben Wochentag und ähnliche Zeitfenster, sofern das Kaufverhalten stark schwankt. Prüfe absolute Fallzahlen neben Prozentwerten: Bei 20 Checkout-Starts kann ein einzelner verlorener Kauf die Rate stark bewegen; bei 20.000 Starts ist derselbe Effekt klein. Saison, Sonderaktion, geändertes Sortiment und eine neue Traffic-Quelle gehören in die Zeitleiste, bevor eine Abweichung als technischer Defekt interpretiert wird.
Messfehler von einer echten Veränderung trennen
Wenn das Kaufereignis im Analytics-Tool seltener erscheint, prüfe zuerst Bestellungen im Shopsystem und Zahlungseingänge. Stimmen die Bestellungen, aber nicht die gemessenen Conversions, liegt die Abweichung womöglich in Tracking, Consent, Event-Namen, Datenimport oder Reporting. Ein doppeltes Ereignis vor der Änderung kann sogar einen scheinbaren Rückgang erzeugen, obwohl die Bestellungen konstant geblieben sind.
Vergleiche Rohereignisse, Event-Definitionen und Zeitstempel. Achte auf Zeitzonen, Filter und verzögerte Datenverarbeitung. Werden Web- und App-Käufe getrennt erfasst? Hat eine Änderung am Consent-Banner die beobachtete Stichprobe verschoben? Diese Prüfung trennt einen Messbruch von einem echten Leistungsabfall. Erst danach ist eine Erklärung des Kundenverhaltens sinnvoll.
Quelle: datenbasiert.de
Wie läuft eine Root-Cause-Analyse ab?
Das Problem messbar beschreiben
Am Anfang steht eine überprüfbare Problembeschreibung: Welche Kennzahl weicht von welchem Ausgangswert ab, seit wann, in welchem System und für welche Nutzer? „Die Website funktioniert schlecht“ liefert keine Suchrichtung. „Die Quote abgeschlossener mobiler Checkouts fiel seit dem Release am Dienstag von 4,0 auf 1,7 Prozent; Desktop liegt weiter bei 4,5 Prozent“ grenzt den Vorfall deutlich ein.
Lege fest, was als Erfolg der Korrektur gilt. Im Beispiel wären das eine normalisierte mobile Abschlussrate, weniger Zahlungsfehler und wieder übereinstimmende Bestellzahlen. Halte zugleich den Untersuchungszeitraum und die Datenquelle fest. So lassen sich spätere Änderungen an der Definition erkennen, statt verschiedene Berechnungen unbemerkt miteinander zu vergleichen.
Zeitpunkt und betroffene Segmente eingrenzen
Lege die Kennzahl als Zeitreihe neben Release-Zeitpunkte, Kampagnenstarts, Preisänderungen und Störungen bei Dienstleistern. Zerlege die Abweichung anschließend nach Gerät, Browser, Zahlungsart, Kanal, Region und Neu- oder Bestandskunden. Beginne mit Segmenten, die eine plausible technische oder fachliche Erklärung ermöglichen. Zu viele beliebige Aufteilungen produzieren auffällige Zufallsmuster.
Ein Funnel zeigt, zwischen welchen Schritten Personen aussteigen: Warenkorb, Checkout-Start, Adresse, Zahlung und bestätigte Bestellung. Fällt nur der Übergang von Zahlung zu Kauf, kann die Ursachensuche dort beginnen. Fallen bereits die Checkout-Starts, ist ein Zahlungsfehler kaum die erste Erklärung. Wie solche Übergänge berechnet und verglichen werden, zeigt die Funnel-Analyse.
Ursachenhypothesen anhand von Daten prüfen
Formuliere jede Hypothese so, dass sie an einer Beobachtung scheitern kann. „Der neue Zahlungsdialog scheitert in einem mobilen Browser“ sagt voraus, dass Fehlerprotokolle, Browser-Segmente und Zeitpunkt zusammenpassen. „Eine neue Kampagne bringt weniger kaufbereite Besucher“ sagt eine Veränderung der Kanalverteilung und möglicherweise schon früher im Funnel niedrigere Abschlussraten voraus. Beide Erklärungen können getestet werden; eine allgemeine Vermutung über „schlechtere Nutzerqualität“ nicht.
Notiere für jede Hypothese erwartete Signale, tatsächliche Befunde und offene Gegenbeispiele. Vergleiche auch nicht betroffene Gruppen: Wenn Desktop trotz desselben Kampagnenmixes stabil bleibt, verliert eine reine Traffic-Erklärung an Gewicht. Wenn dagegen alle Zahlungsarten eines Browsers betroffen sind, spricht das für ein Browser- oder Formularproblem. Ändere jeweils möglichst nur einen Prüfgegenstand, damit Ergebnisse interpretierbar bleiben.
Die Wirkung einer Korrektur überprüfen
Nach der Behebung müssen die vorhergesagten Signale reagieren. Sinkt die Fehlerrate des Zahlungsdienstes? Steigt die Übergangsrate vom Zahlungsschritt zum Kauf? Schließen sich mobile und Desktop-Entwicklung wieder an? Ein einzelner guter Tag reicht bei stark schwankendem Traffic nicht. Nutze einen geeigneten Beobachtungszeitraum und prüfe, ob dieselbe Veränderung in Bestelldaten und Analytics sichtbar ist.
Bei einem kritischen technischen Defekt kann ein Rollback sofort nötig sein. Ist die Ursache weniger klar, ermöglicht ein kontrollierter Vergleich der alten und neuen Variante eine gezieltere Prüfung. Für solche Tests sind gleich definierte Zielgrößen und sauber getrennte Gruppen wesentlich; die Umsetzung erläutert der Beitrag zu A/B-Tests.
Welche Methoden helfen bei der Ursachensuche?
Die Methode richtet sich nach der Frage. Eine einzelne plausible Fehlerkette lässt sich anders untersuchen als viele gleichzeitig wirkende Bedingungen. Die folgenden Werkzeuge strukturieren die Suche; sie ersetzen weder Ereignisdaten noch die Prüfung einer Gegenhypothese.
5-Why: Einer Ursachenkette nachgehen
Bei der 5-Why-Methode wird auf eine beobachtete Antwort wiederholt „Warum?“ gefragt. Warum scheitern mobile Zahlungen? Weil ein Pflichtfeld im Formular nicht übermittelt wird. Warum nicht? Weil eine neue Validierungsregel es bei einem bestimmten Browser ausblendet. Warum blieb das unbemerkt? Weil der Test diese Kombination aus Browser und Zahlungsart nicht abdeckte. Die Zahl fünf ist eine Denkhilfe, kein Abbruchkriterium; die Kette endet bei einer prüfbaren und beeinflussbaren Ursache.
Die Methode funktioniert gut für eine konkrete Ereignisfolge. Sie kann aber eine verzweigte Situation zu früh auf eine Linie reduzieren. Falls mehrere Ursachen zusammenkommen, zeichne verschiedene Pfade auf und prüfe jeden Pfad mit Daten. Ein fehlender Test erklärt etwa, warum der Defekt in Produktion gelangte; die fehlerhafte Validierungsregel erklärt den unmittelbaren Abbruch. Beide Befunde führen zu unterschiedlichen Maßnahmen.
Ishikawa-Diagramm: Mehrere Erklärungen sammeln
Ein Ishikawa-Diagramm, auch Fischgrätendiagramm, setzt das Problem an den Kopf und ordnet mögliche Ursachen an Ästen. Für einen Checkout können Äste etwa Produkt und Preis, Traffic, Oberfläche, Zahlungssystem, Datenmessung, Prozesse und externe Abhängigkeiten sein. Unter „Zahlungssystem“ stehen dann beispielsweise Fehlermeldung, Timeout und nicht unterstützte Browser-Version. Die Kategorien werden für die konkrete Frage gewählt, nicht mechanisch aus einer Vorlage übernommen.
Das Diagramm hilft einem Team, konkurrierende Erklärungen sichtbar zu machen. Anschließend erhält jeder Ast eine Prüfidee: Welche Logdatei, Kennzahl oder Beobachtung würde ihn stützen? Ursachen, für die keine überprüfbare Vorhersage formuliert werden kann, bleiben Vermutungen. Das Ergebnis der Sitzung ist eine priorisierte Liste von Hypothesen und offenen Datenfragen.
Fehlerbaumanalyse: Zusammenwirkende Bedingungen prüfen
Die Fehlerbaumanalyse beginnt mit einem unerwünschten Ereignis und zerlegt es in Bedingungen. Eine ODER-Verknüpfung bedeutet, dass bereits eine der Bedingungen zum Ereignis führen kann; bei einer UND-Verknüpfung müssen Bedingungen zusammenkommen. Ein Kaufabbruch kann etwa durch eine abgelehnte Zahlung oder einen nicht erreichbaren Bestellbutton entstehen. Der spezielle mobile Fehler tritt vielleicht nur auf, wenn die neue Formularversion und ein bestimmter Browser gemeinsam vorliegen.
Diese Darstellung ist nützlich, wenn eine einfache Warum-Kette Verzweigungen überdeckt. Für jeden Zweig werden Protokolle, Reproduktionsschritte oder Segmentdaten gesammelt. Das Modell muss zu den beobachteten Fällen passen: Wenn derselbe Fehler auch ohne den angenommenen Browser auftritt, ist die UND-Verknüpfung falsch oder unvollständig.
Pareto-Analyse: Auffälligkeiten priorisieren
Bei vielen Fehlermeldungen oder Beschwerdearten ordnet die Pareto-Analyse Kategorien nach Häufigkeit oder Schaden. So wird sichtbar, welche Fehlerklasse den größten Teil der betroffenen Käufe erklärt. Wähle die Metrik bewusst: Die häufigste Meldung kann nur einen kleinen Umsatzverlust erzeugen, während ein seltener Fehler teure Bestellungen verhindert. Die Auswertung priorisiert Untersuchungen; die Ursache hinter der führenden Kategorie muss weiterhin geprüft werden. Ein ausführlicheres Beispiel steht im Beitrag zur Pareto-Analyse.
Datenanalyse und Hypothesentests
Segmentvergleiche, Zeitreihen und Kreuztabellen verbinden die qualitativen Methoden mit beobachtbarem Verhalten. Berechne etwa Fehlerraten pro Browser und Zahlungsart vor und nach dem Release. Prüfe bei kleinen Fallzahlen, ob Unterschiede stabil genug sind, um Entscheidungen zu tragen. Ein Hypothesentest kann einen Unterschied zwischen Varianten quantifizieren; die Wahl von Zielgröße, Stichprobe und Testzeitraum erfolgt vor der Auswertung.
Eine Korrelationsanalyse kann gemeinsame Bewegungen von Kennzahlen zeigen. Für die Ursachenfrage braucht es zusätzlich die Reihenfolge der Ereignisse, einen plausiblen Mechanismus und Gegenproben. Ein geändertes Kampagnenbudget und weniger Käufe am selben Tag liefern allein noch keine Erklärung dafür, warum genau mobile Zahlungsabschlüsse ausfallen.
Quelle: datenbasiert.de
Praxisbeispiel: Die Conversion-Rate sinkt
Die folgenden Zahlen sind ein fiktives Rechenbeispiel. In einer Woche starten 10.000 Personen den Checkout; 420 kaufen. Die Abschlussrate beträgt 4,2 Prozent. In der Folgewoche gibt es wieder 10.000 Checkout-Starts, aber nur 280 Käufe: 2,8 Prozent. Der Rückgang beträgt 1,4 Prozentpunkte beziehungsweise ein Drittel des Ausgangswerts. Weil der Nenner konstant ist, konzentriert sich die Untersuchung auf Abschlüsse nach dem Checkout-Start.
Den Einbruch im Funnel lokalisieren
Vor dem Einbruch entfallen 6.000 Checkout-Starts und 240 Käufe auf Mobilgeräte: 4,0 Prozent. Am Desktop sind es 4.000 Starts und 180 Käufe: 4,5 Prozent. Danach kaufen bei unveränderten Starts mobil nur noch 100 Personen, also rund 1,7 Prozent; am Desktop bleiben es 180 und 4,5 Prozent. Damit entfallen alle 140 fehlenden Käufe im Beispiel auf Mobilgeräte. Der Gesamtwert allein hätte diesen Befund verdeckt.
| Segment | Vorher: Starts / Käufe | Vorher: Rate | Nachher: Starts / Käufe | Nachher: Rate |
|---|---|---|---|---|
| Mobil | 6.000 / 240 | 4,0 % | 6.000 / 100 | 1,7 % |
| Desktop | 4.000 / 180 | 4,5 % | 4.000 / 180 | 4,5 % |
| Gesamt | 10.000 / 420 | 4,2 % | 10.000 / 280 | 2,8 % |
Die Funnel-Daten zeigen zusätzlich, dass mobile Nutzer den Adressschritt ähnlich häufig abschließen wie zuvor, aber am Zahlungsschritt abbrechen. Nun lassen sich gezielt Fehlercodes, Browser-Versionen und Zahlungsmethoden auswerten. Eine bloße Empfehlung, die Produktseite zu verbessern, würde am beobachteten Bruch vorbeigehen.
Eine mögliche Ursache gegen andere Erklärungen testen
Am Beginn des Rückgangs wurde eine neue Version des Zahlungsformulars veröffentlicht. Eine mögliche Ursache ist eine Validierungsregel, die in einem mobilen Browser eine nötige Eingabe blockiert. Dazu sollten die Zeitpunkte von Release, Fehlermeldungen und abgebrochenen Zahlungen übereinstimmen. Ein reproduzierbarer Fehler in genau dieser Konstellation stärkt die Hypothese. Zugleich werden andere Erklärungen geprüft: Hat sich der mobile Kampagnenmix geändert? Sind Zahlungen im Shopsystem tatsächlich gesunken? Betrifft der Fehler auch alte Formularversionen?
Im gedachten Fall bleiben die mobilen Checkout-Starts und der Desktop-Abschluss stabil, während ein bestimmter Zahlungsfehler nach dem Release sprunghaft zunimmt. Nach dem Zurücksetzen der betroffenen Regel sinkt seine Häufigkeit; die mobile Abschlussrate erholt sich im anschließenden Vergleichszeitraum. Damit stützen mehrere unabhängige Beobachtungen dieselbe Erklärung. Die anschließende Korrektur umfasst einen Test für die betroffene Kombination und einen Alarm für ähnliche Fehlercodes.
Wann ist eine Ursache ausreichend belegt?
Korrelation und zeitliche Abfolge einordnen
Eine plausible Ursache muss das Muster der Abweichung erklären: Beginn, betroffene Segmente, betroffenen Prozessschritt und erwartete Fehlersignale. Ein Release kurz vor dem Einbruch ist ein Hinweis, aber noch kein Beleg. Wenn die fehlerhafte Funktion nur Desktop-Nutzer betrifft, während ausschließlich mobile Abschlüsse fallen, widerspricht das der Hypothese. Ebenso kann eine gleichzeitig gestartete Werbekampagne zufällig mit einem Zahlungsdefekt zusammenfallen.
Stärker wird die Erklärung durch einen nachvollziehbaren Mechanismus und einen Vergleich: Der Fehler lässt sich reproduzieren, tritt unter den vorhergesagten Bedingungen auf, fehlt in einer nicht betroffenen Gruppe und verschwindet nach einer gezielten Korrektur. Dokumentiere auch widersprechende Befunde. Sie helfen, eine zu einfache Ursachenkette zu korrigieren, bevor daraus eine falsche Dauermaßnahme entsteht.
Für die Entscheidung hilft eine kleine Evidenzübersicht. Sie trennt die vermutete Ursache von dem Messsignal, das diese Hypothese vorhersagt. Im Checkout-Beispiel könnte das so aussehen:
| Ursachenhypothese | Erwarteter Befund | Geeignete Gegenprobe |
|---|---|---|
| Tracking-Ausfall | Analytics meldet weniger Käufe, das Shopsystem stabile Bestellungen. | Kaufereignisse mit bezahlten Bestellungen und Zahlungsprotokollen vergleichen. |
| Traffic-Verschiebung | Neue Kanäle bringen andere Nutzer und verändern die Abschlussrate schon vor dem Zahlungsschritt. | Abschlussraten innerhalb derselben Kanäle und Geräte vor und nach der Änderung prüfen. |
| Mobiler Formularfehler | Zahlungsfehler steigen nach dem Release in den betroffenen Browsern. | Alte Version oder andere Browser unter sonst gleichen Bedingungen testen. |
| Externer Zahlungsdienst | Fehler betreffen mehrere Formulare, aber dieselbe Zahlungsart oder Schnittstelle. | Fehlercodes und Zeitverlauf des Dienstes mit anderen Zahlungsarten abgleichen. |
Die Übersicht zeigt auch, welche Daten noch fehlen. Fehlt beispielsweise die Browser-Version in den Fehlerprotokollen, kann eine mobile Formularhypothese nicht gezielt geprüft werden. Dann wird zuerst die Datenerfassung ergänzt oder der Fehler mit dokumentierten Testfällen reproduziert. Ein fehlender Befund ist nicht automatisch ein Gegenbeweis: Entscheidend ist, ob die betreffende Kennzahl in diesem Zeitraum zuverlässig erfasst wurde.
Gegenproben und Experimente nutzen
Eine Gegenprobe fragt, was zu sehen sein müsste, wenn die Hypothese falsch wäre. Betrifft eine vermutete Browser-Inkompatibilität mehrere Zahlungsarten gleichermaßen? Funktioniert dieselbe Version auf einem anderen Browser? Lässt sich der Fehler mit der alten Konfiguration auslösen? Solche Vergleiche sind aussagekräftiger als das bloße Sammeln weiterer Beispiele für die bevorzugte Erklärung.
Wo ein kontrollierter Eingriff vertretbar ist, kann die alte und neue Variante getrennten Gruppen gezeigt werden. Die zentrale Frage lautet dann, ob sich die vorher definierte Abschlussrate und der konkrete Fehlercode zwischen den Varianten unterscheiden. Bei einem schwerwiegenden Defekt ist die sofortige Wiederherstellung wichtiger als eine lange Testphase. Die Wirkung des Rollbacks wird anschließend anhand des gleichen Messplans beobachtet.
Wie verhindert man, dass das Problem zurückkehrt?
Die Korrektur und ihre Verantwortlichkeit dokumentieren
Ein Abschlussprotokoll hält das Problem, die betroffenen Kennzahlen, die Zeitlinie, geprüfte Hypothesen, die bestätigten Ursachen und die Maßnahmen fest. Trenne dabei unmittelbaren Auslöser, begünstigende Bedingung und Lücke in der Entdeckung. Beim Zahlungsbeispiel sind das die defekte Validierungsregel, die fehlende Prüfung der Browser-Kombination und der ausgebliebene Alarm auf steigende Fehlercodes. Jede Maßnahme erhält eine verantwortliche Person und einen überprüfbaren Termin.
Die Dokumentation soll spätere Entscheidungen ermöglichen: Welche Version wurde zurückgesetzt? Welcher Test wurde ergänzt? Bei welcher Fehlerrate wird künftig alarmiert? So wird aus der einmaligen Fehlerbehebung eine Änderung am Prozess. Für kanalübergreifende Kennzahlen und die Verbindung von Datenquellen bietet der Beitrag zu Marketing Analytics den größeren Rahmen.
Die betroffene Kennzahl weiter beobachten
Nach der Korrektur werden mobile Checkout-Abschlussrate, Zahlungsfehler und Bestellungen weiterhin nach Browser und Zahlungsart beobachtet. Ein Grenzwert sollte auf der üblichen Schwankung der jeweiligen Kennzahl beruhen und bei einer relevanten Veränderung auslösen. Sinkt nur die Analytics-Conversion, während Bestellungen stabil bleiben, richtet sich die Prüfung erneut auf das Tracking. Sinkt die operative Bestellzahl mit derselben Fehlermeldung, wird der technische Zweig wieder geöffnet.
Überprüfe die Maßnahmen nach einigen Wochen: Wurde der Test tatsächlich in die Freigabe aufgenommen? Hat der Alarm bei einem späteren Vorfall ausgelöst? Eine Root-Cause-Analyse ist erst dann abgeschlossen, wenn die Korrektur im Betrieb funktioniert und die zuvor beobachtete Abweichung anhand derselben Definition nachvollziehbar behoben ist.
Quelle: datenbasiert.de
Fazit
Eine Root-Cause-Analyse beginnt mit einer präzisen Abweichung und endet mit einer überprüften Änderung. Im Checkout-Beispiel führt der Weg von der sinkenden Conversion-Rate über mobile Segmente und den Zahlungsschritt zur testbaren Formularursache. 5-Why, Ishikawa, Fehlerbaum und Pareto ordnen die Suche; Messdaten und Gegenproben entscheiden über die Erklärung. Wer Auslöser, Entdeckungslücke und Nachkontrolle gemeinsam bearbeitet, kann einen Vorfall beheben und sein Wiederauftreten gezielt erschweren.
