Event-Tracking-Plan für SaaS: Namen, Eigenschaften, 10 Dashboards

Was du früh verstehen musst (und warum es schwer ist)

Frühe Analysen in einer ersten SaaS-App wirken oft verwirrend, weil zwei Probleme gleichzeitig auftreten: wenige Nutzer und wenig Kontext. Eine Handvoll Power-User kann deine Charts verzerren, während einige „Touristen“ (Leute, die sich anmelden und wieder gehen) alles kaputt aussehen lassen.

Die schwierigste Aufgabe ist, Nutzungsrauschen von echten Signalen zu trennen. Rauschen sind Aktivitäten, die beschäftigt aussehen, aber keinen Fortschritt bedeuten, zum Beispiel in den Einstellungen herumklicken, Seiten neu laden oder mehrere Testkonten anlegen. Signale sind Aktionen, die Wert vorhersagen, etwa das Abschließen des Onboardings, das Einladen eines Teamkollegen oder das erfolgreiche Abschließen des ersten Workflows.

Ein guter event tracking plan für SaaS sollte dir in den ersten 30 Tagen ein paar grundlegende Fragen beantworten, ohne dass du ein Data-Team brauchst.

Was du schnell beantworten können solltest

Wenn dein Tracking diese Fragen beantworten kann, bist du auf einem guten Weg:

• Wo fallen neue Anmeldungen ab, bevor sie den ersten Wert erreichen?
• Wie viele Nutzer erreichen den „first value“ innerhalb von 24 Stunden bzw. innerhalb von 7 Tagen?
• Welche Features werden von Leuten genutzt, die nächste Woche wiederkommen?
• Was ist der häufigste Pfad zum Erfolg (und die häufigste Sackgasse)?
• Kommen wiederkehrende Nutzer zurück, um die gleiche Aufgabe zu erledigen, oder stöbern sie nur herum?

Kurz: Aktivierung ist der Moment, in dem ein Nutzer seinen ersten echten Erfolg hat. Retention (Bindung) ist, ob er wegen dieses Erfolgs wiederkommt. Du brauchst nicht sofort eine perfekte Definition, aber eine klare Vermutung und eine Messmethode.

Wenn du schnell baust (zum Beispiel täglich neue Flows in einer Plattform wie Koder.ai auslieferst), ist die Gefahr, alles zu instrumentieren. Mehr Events können mehr Verwirrung bedeuten. Starte mit einer kleinen Menge von Aktionen, die zu „first win“ und „repeat win“ führen, und erweitere nur, wenn eine Entscheidung davon abhängt.

Aktivierung und Retention einfach definieren

Aktivierung ist der Moment, in dem ein neuer Nutzer zum ersten Mal echten Nutzen erhält. Retention ist, ob er wiederkommt und über die Zeit weiterhin Nutzen hat. Wenn du beides nicht einfach beschreiben kannst, wird dein Tracking zu einem Haufen Events, die nichts beantworten.

Beginne damit, zwei "Personen" in deinem Produkt zu benennen:

• Core user: die Person, die die Arbeit macht (die klickt, hochlädt, sendet, baut).
• Account: der Kunde, der bezahlt und die Abrechnung besitzt (eine Person oder ein Unternehmen).

Viele SaaS-Apps haben Teams, daher kann ein Account viele Nutzer enthalten. Deshalb sollte dein event tracking plan für SaaS immer klar machen, ob du Nutzerverhalten, Account-Gesundheit oder beides misst.

Aktivierung in einem Satz

Formuliere Aktivierung als einen Satz mit einer klaren Aktion und einem klaren Ergebnis. Gute Aktivierungsmomente lesen sich wie: Ich habe X getan und bekam Y.

Beispiel: Ein Nutzer erstellt sein erstes Projekt und veröffentlicht es erfolgreich. (Wenn du mit einem Tool wie Koder.ai baust, könnte das „first successful deploy“ oder „first source code export“ sein, je nach Versprechen deines Produkts.)

Um das messbar zu machen, liste die wenigen Schritte auf, die normalerweise kurz vor dem ersten Wert passieren. Halte es kurz und beobachtbar:

• Sign up
• Create the first workspace/project
• Add the key input (data, content, integration, or settings)
• Run the core action (send, publish, generate, invite)
• Reach a success state (completed, delivered, deployed)

Was Retention für dich bedeutet

Retention ist „sind sie nach einem Zeitplan zurückgekommen, der zu deinem Produkt passt“.

Wenn dein Produkt täglich genutzt wird, schaue auf tägliche Retention. Bei einem Arbeitstool, das ein paar Mal pro Woche genutzt wird, nimm wöchentliche Retention. Bei monatlichen Workflows (Abrechnung, Reporting) nutze monatliche Retention. Die beste Wahl ist die, bei der „zurückkommen“ realistisch fortlaufenden Wert signalisiert, nicht aus schlechtem Gewissen einloggen.

Schritt-für-Schritt: Erstelle deinen ersten Event-Tracking-Plan

Beginne mit dem Pfad zum ersten Wert

Ein event tracking plan für SaaS funktioniert am besten, wenn er eine einfache Geschichte verfolgt: wie eine neue Person von der Anmeldung zum ersten echten Erfolg kommt.

Schreibe den kürzesten Onboarding-Pfad auf, der Wert erzeugt. Beispiel: Signup -> verify email -> create workspace -> invite teammate (optional) -> connect data (oder project einrichten) -> complete first key action -> see result.

Markiere die Momente, an denen jemand abbrechen oder stecken bleiben kann. Diese Momente werden zu den ersten Events, die du trackst.

Definiere und teste das Minimum

Halte die erste Version klein. Meist brauchst du 8–15 Events, nicht 80. Ziel sind Events, die beantworten: Haben sie gestartet? Haben sie den ersten Wert erreicht? Sind sie zurückgekommen?

Eine praktische Reihenfolge:

• Mappe das Onboarding- und First-Value-Pfad (eine Seite, kein Streit)
• Wähle eine kurze Event-Liste, die jeden Schritt abdeckt
• Definiere jedes Event in einer winzigen Spez (Name, wann es feuert, Schlüssel-Properties)
• Füge jeder Event-Payload eine stabile user ID und eine account/workspace ID hinzu
• Teste die Events, indem du die echten Flows vor Release durchläufst

Für die Event-Spez genügt normalerweise eine kleine Tabelle: event name, trigger (was im Produkt passieren muss), wer es triggern kann, und welche properties du immer sendest.

Zwei IDs verhindern die meisten frühen Verwirrungen: eine eindeutige user_id (Person) und eine account- oder workspace_id (der Ort, an dem sie arbeiten). So trennst du persönliche Nutzung von Team-Adoption und späteren Upgrades.

Vor dem Release mache einen "fresh user"-Test: Erstelle einen neuen Account, durchlaufe das Onboarding und prüfe, dass jedes Event einmal feuert (nicht null, nicht fünfmal) mit den richtigen IDs und Zeitstempeln. Wenn du auf einer Plattform wie Koder.ai baust, integriere diesen Test in deine Pre-Release-Checks, damit Tracking mit der App mitwandert.

Eine einfache Namenskonvention für Events

Eine Konvention ist nicht dazu da, „richtig“ zu sein, sondern konsistent, damit deine Charts nicht brechen, wenn sich das Produkt ändert.

Eine einfache Regel, die für die meisten SaaS-Apps funktioniert, ist verb_noun in snake_case. Halte das Verb klar und das Nomen spezifisch.

Beispiele, die du übernehmen kannst:

• created_project, invited_teammate, uploaded_file, scheduled_demo
• submitted_form (Vergangenheitsform liest sich wie eine abgeschlossene Aktion)
• connected_integration, enabled_feature, exported_report

Bevorzuge Vergangenheitsform für Events, die „das ist passiert“ bedeuten. Das reduziert Ambiguität. Zum Beispiel kann started_checkout nützlich sein, aber completed_checkout ist das, was du für Revenue- und Retention-Arbeit brauchst.

Vermeide UI-spezifische Namen wie clicked_blue_button oder pressed_save_icon. Buttons und Layouts ändern sich, sonst wird dein Tracking zur Historie alter Bildschirme. Benenne die zugrunde liegende Absicht: saved_settings oder updated_profile.

Halte Namen stabil, auch wenn die UI sich ändert. Wenn du created_workspace später in created_team umbenennst, kann dein Aktivierungs-Chart in zwei Linien splitten und Kontinuität verlieren. Wenn du einen Namen ändern musst, behandle es wie eine Migration: mappe alt auf neu und dokumentiere die Entscheidung.

Reservierte Präfixe (klein und pragmatisch)

Eine kurze Menge von Präfixen hilft, die Event-Liste ordentlich und scanbar zu halten. Wähle ein paar und bleibe dabei.

Zum Beispiel:

• auth_ (signup, login, logout)
• onboarding_ (Schritte, die zum ersten Wert führen)
• billing_ (trial, checkout, invoices)
• admin_ (Rollen, Berechtigungen, Org-Einstellungen)

Wenn du dein SaaS in einem Chat-getriebenen Builder wie Koder.ai baust, gilt diese Konvention weiterhin. Ein Feature, das heute gebaut wird, kann morgen redesigned sein, aber created_project bleibt über alle UI-Iterationen hinweg sinnvoll.

Eigenschaften (Properties), die du mitschicken solltest (und wie du sie konsistent hältst)

Gute Event-Namen sagen, was passiert ist. Properties sagen, wer es getan hat, wo es passiert ist und wie das Ergebnis war. Wenn du eine kleine, vorhersehbare Menge beibehältst, bleibt dein event tracking plan für SaaS lesbar, wenn du Features hinzufügst.

Beginne mit einem kleinen Always-on-Core

Wähle ein paar Properties, die auf fast jedem Event erscheinen. Damit kannst du später Charts nach Kundentyp aufschlüsseln, ohne Dashboards neu zu bauen.

Ein praktischer Core:

• user_id und account_id (wer es getan hat und zu welchem Workspace es gehört)
• plan_tier (free, pro, business, enterprise)
• timestamp (wann es passiert ist, möglichst vom Server)
• app_version (um Änderungen nach Releases zu erkennen)
• signup_source (woher der Nutzer kam: ads, referral, organic)

Füge Kontext nur dann hinzu, wenn er die Bedeutung des Events ändert. Zum Beispiel ist "Project Created" mit project_type oder template_id viel nützlicher, und "Invite Sent" wird handhabbar mit seats_count.

Tracke Ergebnisse, nicht nur Aktionen

Wenn eine Aktion fehlschlagen kann, sende ein explizites Ergebnis. Ein einfaches success: true/false reicht oft. Falls false, ergänze ein kurzes error_code (z. B. "billing_declined" oder "invalid_domain"), damit du Probleme gruppieren kannst, ohne Rohlogs zu lesen.

Ein realistisches Beispiel: Auf Koder.ai ist „Deploy Started“ ohne Outcome-Daten verwirrend. Füge success plus error_code hinzu, dann siehst du schnell, ob neue Nutzer wegen fehlender Domain-Konfiguration, Kreditkartenfehlern oder Regionseinstellungen scheitern.

Konsistenzregeln, die deine Dashboards retten

Entscheide Name, Typ und Bedeutung einmal und halte dich daran. Wenn plan_tier ein String in einem Event ist, sende ihn nicht als Zahl in einem anderen. Vermeide Synonyme (account_id vs workspace_id) und ändere niemals im Zeitverlauf, was eine Property bedeutet.

Wenn du eine bessere Version brauchst, erstelle eine neue Property-Name und behalte die alte, bis Dashboards migriert sind.

Datenhygiene und Datenschutz-Basics

Sauberes Tracking ist hauptsächlich zwei Gewohnheiten: nur das Nötige senden und es einfach machen, Fehler zu beheben.

Behandle Analytics als Log von Aktionen, nicht als Ort, um persönliche Details zu speichern. Vermeide das Senden von rohen E-Mails, vollständigen Namen, Telefonnummern oder alles, was Nutzer in Freitextfeldern schreiben (Support-Notizen, Feedback, Chats). Freitext enthält oft sensible Infos, mit denen du nicht gerechnet hast.

Verwende interne IDs statt PII. Tracke user_id, account_id und workspace_id und halte die Zuordnung zu persönlichen Daten in deiner eigenen Datenbank oder CRM. Wenn jemand wirklich ein Event einer Person zuordnen muss, geschieht das über interne Tools, nicht durch Kopieren von PII in Analytics.

IP-Adressen und Standortdaten brauchen eine Entscheidung von Anfang an. Viele Tools erfassen IP standardmäßig; Stadt/Land kann harmlos wirken, ist aber trotzdem personenbezogen. Wähle eine Vorgehensweise und dokumentiere sie: nichts speichern, nur grobe Location (Land/Region) speichern oder IP nur temporär für Sicherheit speichern und dann löschen.

Eine einfache Hygiene-Checkliste für die ersten Dashboards:

• Definiere eine Allow-List von Event-Properties, die du senden darfst (alles andere blockieren)
• Baue eine Möglichkeit, Daten eines Nutzers auf Anfrage zu löschen (per user_id und account_id)
• Beschränke Zugriff: wer Roh-Events sehen, exportieren oder Tracking ändern kann
• Führe ein kurzes Tracking-Dokument mit Beispielen für "safe" vs "not safe" Properties

Wenn du dein SaaS auf einer Plattform wie Koder.ai aufbaust, wende dieselben Regeln auf Systemlogs und Snapshots an: Identifikatoren konsistent halten, PII aus Event-Payloads fernhalten und dokumentieren, wer was sehen darf und warum.

10 unverzichtbare Dashboards für frühe Aktivierung und Bindung

Ein guter event tracking plan für SaaS verwandelt rohe Klicks in beantwortbare Fragen. Diese Dashboards konzentrieren sich auf zwei Dinge: wie Leute den ersten Wert erreichen und ob sie wiederkommen.

Dashboards, die Aktivierung erklären

• 1) Trend neuer Nutzer (täglich/wöchentlich) + signup_source: Zähle neue Accounts und brich sie nach Herkunft auf (Ads, Organic, Referral, Invite). Achte auf Spike-Quellen, die später nicht aktivieren.
• 2) Aktivierungs-Funnel mit Drop-offs: Ein einfacher Funnel wie Signup -> Email verified -> Project created -> First value action. Hebe den größten Drop hervor und untersuche Sessions.
• 3) Time to first value (Median, p75): Miss, wie lange Nutzer bis zum first value brauchen. Median zeigt den typischen Pfad; p75 zeigt, wer kämpft.
• 4) Feature-Adoption (Top 5 Value-Aktionen): Tracke die wenigen Aktionen, die echten Gebrauch bedeuten (keine Einstellungs-Klicks). Begrenze auf Top 5 für Lesbarkeit.
• 5) Aktivierungsrate nach signup_source: Dieselbe Aktivierungsdefinition, aufgeteilt nach Quelle. Ein Kanal bringt oft Neugierige, ein anderer Käufer.

Wenn du die erste Version in einer Plattform wie Koder.ai gebaut hast, gelten dieselben Dashboards — der Schlüssel sind konsistente Events.

Dashboards, die Retention erklären

• 6) Retention-Kohorten (Woche 1, Woche 4): Kohorten nach Anmelde-Woche, Retention gemessen durch das Ausführen einer Schlüssel-Aktion. Zeigt, ob das Produkt über die Zeit „stickier“ wird.
• 7) Trend wiederkehrender Nutzer (WAU): Weekly active users (basierend auf einer Schlüssel-Aktion), um Logins von echtem Gebrauch zu trennen.
• 8) Häufigkeit des wiederholten Werts: Wie viele Tage pro Woche Nutzer die Kern-Aktion durchführen. Zeigt, ob du einen Habit-Forming-Workflow hast.
• 9) Re-Activation-Funnel: Inactive -> Returned -> Did key action. Hilft zu sehen, ob Erinnerungen und neue Features Leute wirklich zurückbringen.
• 10) Friction-Dashboard (Fehler und fehlgeschlagene Aktionen): Tracke error_shown, payment_failed oder integration_failed. Peaks hier töten still Aktivierung und Retention.

Beispiel-Szenario: Tracking eines neuen SaaS von Signup bis First Value

Stell dir ein einfaches B2B-SaaS mit 14-tägiger Trial vor. Eine Person meldet sich an, erstellt einen Workspace für ihr Team, testet das Produkt und lädt idealerweise einen Teamkollegen ein. Dein Ziel ist, schnell zu lernen, wo Menschen stecken bleiben.

Definiere "first value" so: Der Nutzer erstellt einen Workspace und schließt eine Kern-Aufgabe ab, die beweist, dass das Produkt für ihn funktioniert (z. B. "import a CSV and generate the first report"). Alles frühe Tracking sollte auf diesen Moment zurückführen.

Hier ist ein leichtgewichtiges Set von Events, das du am ersten Tag verschicken kannst (Namen in einfacher Vergangenheitsform):

• created_workspace
• completed_core_task
• invited_teammate

Für jedes Event füge gerade genug Properties hinzu, um zu erklären, warum es passiert ist (oder nicht). Gute frühe Properties sind:

• signup_source (google_ads, referral, founder_linkedin, etc.)
• template_id (welches Start-Setup sie gewählt haben)
• seats_count (wichtig bei Team-Invites)
• success (true/false) plus ein kurzes error_code, wenn success false ist

Stell dir dann deine Dashboards vor. Dein Aktivierungs-Funnel zeigt: signed_up -> created_workspace -> completed_core_task. Wenn zwischen Workspace-Erstellung und Kern-Aktion ein großer Drop sichtbar ist, segmentiere nach template_id und success. Du könntest entdecken, dass eine Vorlage viele fehlgeschlagene Läufe erzeugt (success=false) oder Nutzer aus einer bestimmten signup_source die falsche Vorlage wählen und keinen Wert erreichen.

Die Ansicht zur Team-Erweiterung (completed_core_task -> invited_teammate) sagt dir, ob Leute erst nach dem Erfolg einladen oder ob Invites früh passieren, die eingeladenen Nutzer aber nie die Kern-Aktion abschließen.

Das Ziel eines event tracking plan für SaaS ist nicht, alles zu sammeln, sondern die größte Engstelle zu finden, die du nächste Woche beheben kannst.

Häufige Fehler, die frühe Insights ruinieren

Die meisten Tracking-Fehler haben nichts mit Tools zu tun. Sie passieren, wenn dein Tracking zeigt, was Leute geklickt haben, aber nicht, was sie erreicht haben. Wenn deine Daten nicht beantworten können, ob ein Nutzer den Wert erreicht hat, fühlt sich dein event tracking plan für SaaS beschäftigt an und du rätselst trotzdem.

Fehler 1: Klicks statt Ergebnisse messen

Klicks sind einfach zu tracken und leicht fehlzuinterpretieren. Ein Nutzer kann dreimal auf "Create project" klicken und trotzdem scheitern. Bevorzuge Events, die Fortschritt beschreiben: created a workspace, invited a teammate, connected data, published, sent first invoice, completed first run.

Fehler 2: Events jeden Sprint umbenennen

Wenn du Namen änderst, um zur aktuellen UI zu passen, brechen Trends und du verlierst Wochen-über-Wochen-Kontext. Wähle einen stabilen Event-Namen und erweitere die Bedeutung über Properties (z. B. behalte project_created und füge creation_source hinzu, wenn ein neuer Einstiegspunkt kommt).

Fehler 3: B2B-Identifikatoren vergessen

Wenn du nur user_id sendest, kannst du keine Account-Fragen beantworten: welche Teams aktivierten, welche Accounts churnen, wer Power-User in einem Account ist. Sende immer eine account_id (und idealerweise role oder seat_type), damit du sowohl Nutzer- als auch Account-Retention sehen kannst.

Fehler 4: Zu viele Properties senden

Mehr ist nicht besser. Ein riesiges, inkonsistentes Property-Set erzeugt leere Werte, Rechtschreibvarianten und Dashboards, denen niemand vertraut. Halte ein kleines Always-on-Set und füge nur dann Properties hinzu, wenn sie eine konkrete Frage beantworten.

Fehler 5: Nicht Ende-zu-Ende testen

Vor dem Release prüfe:

• Events feuern einmal (nicht zweimal) und zum richtigen Zeitpunkt
• Pflicht-IDs sind vorhanden (user_id, account_id wo nötig)
• Property-Werte entsprechen der vereinbarten Liste (keine Überraschungs-Strings)
• Dashboards aktualisieren sich aus echten Flows, nicht nur aus Testdaten
• Du kannst die Nutzerreise in der richtigen Reihenfolge abspielen

Wenn du dein SaaS in einem Chat-getriebenen Builder wie Koder.ai baust, behandele Tracking wie jede andere Funktion: Definiere erwartete Events, durchlaufe eine komplette Nutzerreise und publiziere erst dann.

Schnelle Checkliste vor dem Shipping des Trackings

Bevor du mehr Events hinzufügst, stelle sicher, dass dein Tracking in Woche 1 die Fragen beantwortet, die du wirklich hast: Erreichen Leute den ersten Wert und kommen sie zurück?

Beginne mit deinen Schlüssel-Flows (Signup, Onboarding, First Value, Returning Use). Für jeden Flow wähle 1–3 Outcome-Events, die Fortschritt beweisen. Wenn du jede Schaltfläche trackst, ertrinkst du im Rauschen und verpasst den wichtigen Moment.

Verwende eine Namenskonvention überall und halte sie in einem einfachen Doc fest. Ziel ist, dass zwei Personen unabhängig dasselbe Event gleich benennen.

Eine kurze Pre-Ship-Checkliste, die die meisten Fehler fängt:

• Outcome first: Jeder Key-Flow hat wenige Outcome-Events, nicht Dutzende UI-Clicks.
• Konsistente Namen: Events folgen Verb+Nomen-Stil und die Bedeutung ist an einem Ort dokumentiert.
• Properties sind getyped: Kritische Properties behalten den gleichen Typ (z. B. plan ist immer String, seat_count immer Zahl).
• Dashboards passen zu Definitionen: Dein Aktivierungs-Dashboard nutzt dein Aktivierungs-Event, das Retention-Dashboard dein Retention-Event (nicht irgendein Proxy).
• QA wie ein Nutzer: Durchlaufe die App und bestätige, dass Events einmal, zur richtigen Zeit und mit den richtigen Properties feuern.

Ein einfacher QA-Trick: Mach die komplette Reise zweimal. Der erste Lauf prüft Aktivierung. Der zweite Lauf (nach Ausloggen/Wiederanmeldung oder am nächsten Tag) prüft Retention-Signale und verhindert Double-Fire-Bugs.

Wenn du mit Koder.ai baust, wiederhole die QA nach Snapshot/Rollback oder Code-Export, damit Tracking mit der App synchron bleibt.

Nächste Schritte: Leichtgewichtig bleiben und iterieren

Dein erstes Tracking-Setup sollte klein wirken. Wenn die Implementierung Wochen dauert, vermeidest du Änderungen später und die Daten bleiben hinter dem Produkt zurück.

Wähle eine einfache Wochenroutine: Schau dir die gleichen Dashboards an, notiere Überraschungen und ändere Tracking nur, wenn es einen klaren Grund gibt. Ziel ist nicht „mehr Events“, sondern klarere Antworten.

Eine gute Regel: Füge 1–2 Events gleichzeitig hinzu, jeweils für eine Frage, die du heute nicht beantworten kannst. Beispiel: "Aktivieren Nutzer, die ein Team einladen, häufiger?" Wenn du bereits invite_sent trackst, aber nicht invite_accepted, füge nur das fehlende Event und eine Property hinzu, die du zum Segmentieren brauchst (z. B. plan tier). Deploy, beobachte eine Woche, und entscheide dann die nächste Änderung.

Eine einfache Cadence für frühe Teams:

• Review Activation- und Retention-Dashboards einmal pro Woche, am selben Tag und zur selben Zeit
• Schreibe 3 Erkenntnisse und 1 Follow-up-Frage
• Füge oder passe Tracking nur an, wenn es diese Frage beantwortet
• Behalte Event-Namen stabil; füge Properties hinzu, bevor du neue Events erstellst
• Lösche nichts, bis du sicher bist, dass es ungenutzt ist (Löschen bricht Trends)

Führe ein kleines Changelog für Tracking-Updates, damit später alle Zahlen vertrauenswürdig sind. Es kann in einem Doc oder Repo-Note leben. Enthält:

• Datum und Owner
• Was sich geändert hat (Event/Property-Name)
• Warum es geändert wurde (die Frage)
• Erwartete Auswirkungen (betroffene Dashboards)

Wenn du deine erste App baust, plane den Flow, bevor du implementierst. In Koder.ai ist der Planning Mode ein praktischer Weg, Onboarding-Schritte zu skizzieren und die benötigten Events pro Schritt aufzulisten, bevor es Code gibt.

Wenn du das Onboarding iterierst, schütze die Tracking-Konsistenz. Mit Koder.ai-Snapshots und Rollbacks kannst du Bildschirme und Schritte anpassen und gleichzeitig festhalten, wann sich der Flow geändert hat, sodass plötzliche Verschiebungen in der Aktivierung leichter zu erklären sind.