UX-Analyse des Workflows: Wir messen die Effektivität der Schritte

1. Warum Workflows überhaupt messen

Kurz gesagt: Ohne Analytics leben Sie im Modus „mir scheint“, nicht im Modus „ich weiß“.

In den vorherigen Vorlesungen dieses Moduls haben wir das Szenario bereits in Schritte zerlegt, Rollen für GPT, Widget und MCP vergeben, Tool‑Gating besprochen und die Speicherung des Zustands zwischen Schritten diskutiert. Jetzt schauen wir auf dieselbe Konstruktion mit den Augen der Analytics: Funktioniert das alles so, wie wir es vorgesehen haben, und wo bleiben die Nutzer in Wirklichkeit hängen?

Im gewöhnlichen Web ist man seit Langem an Funnels gewöhnt: wie viele Leute auf der Landingpage landen, wie viele ein Produkt in den Warenkorb legen, wie viele bis zur Bezahlung kommen. In der ChatGPT App ist es dasselbe – nur dass Sie statt Seiten die Schritte des Workflows haben und statt eines „Klicks auf die Schaltfläche „Kaufen““ eine Kombination aus Nutzeräußerung, Tool‑Aufruf und Interaktion mit dem Widget.

Wenn Sie ein komplexes Szenario ohne Metriken bauen, sehen Sie nicht:

• an welchem Schritt die Leute am häufigsten „abspringen“;
• wo sie hängen bleiben und eine Minute lang lesen (oder einfach Tee holen und nicht zurückkehren);
• welcher Schritt überhaupt keinen Nutzen bringt und nur nervt;
• wie Änderungen in Prompts oder beim Tool‑Gating das Verhalten beeinflussen.

Das Ziel der Schritt‑Analytics ist einfach: den Anteil der abgeschlossenen Szenarien erhöhen, die Zeit bis zum Ergebnis verkürzen und die Anzahl der Fehler sowie Support‑Anfragen reduzieren.

Ab jetzt ist der Workflow nicht nur ein Architekturobjekt und nicht nur ein UX‑Quest. Er ist auch eine messbare Sache mit Zahlen.

2. Der Szenario‑Funnel in der ChatGPT App

Im klassischen Web sieht der Funnel linear aus: Landing → Product → Cart → Checkout. In der ChatGPT App ist das Bild etwas lebhafter: Der Nutzer kann einen Schritt „mit Worten“ überspringen, das Modell kann gelegentlich einen Schritt auslassen, und Widget und Text des Dialogs können asynchron werden.

Dennoch ist die Grundidee dieselbe: Wir haben eine Abfolge von Schritten, und bei jedem von ihnen geht ein Teil der Nutzer weiter – und ein Teil nicht.

Nehmen wir unseren GiftGenius:

1. collect_recipient – ChatGPT und das Widget sammeln Basisdaten über den Empfänger (Geschlecht, Alter, Beziehung, Interessen).
2. collect_budget – wir präzisieren Budget und Währung.
3. suggest_ideas – MCP/Agent wählt Ideen aus und liefert Geschenk‑Karten an das Widget zurück.
4. review_selection – der Nutzer liked/blendet Ideen aus und wählt 1–2 Favoriten.
5. checkout – es wird ein Commerce‑Intent erstellt, die Bestellung wird aufgegeben.

Als Funnel lässt sich das so darstellen:

flowchart TD
    A[Start des Workflows] --> B["1\. Empfänger"]
    B --> C["2\. Budget"]
    C --> D["3\. Geschenkideen"]
    D --> E["4\. Geschenkauswahl"]
    E --> F["5\. Checkout"]

Wichtig ist jedoch: Der Nutzer kann in den Chat schreiben „Lass uns direkt zur Zahlung gehen“ oder „Zeig zuerst die teuren Optionen“, und das Modell kann beschließen, einen Teil der Schritte zu überspringen. Deshalb ist Schritt‑Analytics in der ChatGPT App nicht nur über UI‑Bildschirme, sondern auch über das Modellverhalten: welche Schritte tatsächlich durchlaufen werden, in welcher Reihenfolge – und wer den Übergang initiiert hat: Nutzer, Widget oder GPT.

3. Basismetriken pro Schritt

Beginnen wir mit den Klassikern der Produkt‑Analytics und passen sie leicht an die ChatGPT App an.

Für jeden Workflow benötigen wir mindestens vier grundlegende Kennzahlen.

Der Übersicht halber fassen wir sie in einer Tabelle zusammen:

Hinzu kommen fast immer Aufwandsmetriken:

• durchschnittliche Zeit pro Schritt (wo die Leute „hängen bleiben“);
• Anzahl der Interaktionen pro Schritt (wie viele Nachrichten/Klicks benötigt wurden);
• Anteil der Schritte, die mit einem Fehler endeten oder einen erneuten Versuch erforderten.

Im Kontext von LLM‑Szenarien kommen noch spezifischere Dinge hinzu, etwa die Genauigkeit der Tool‑Auswahl durch das Modell oder der Anteil „halluzinierter“ Antworten in einem bestimmten Schritt. Das ist jedoch fortgeschritten und kommt in den Abschlussmodulen.

Für Commerce‑Szenarien werden auf die Schritte Business‑Metriken „aufgesattelt“:

• Conversion zur Zahlung ab Workflow‑Start;
• Conversion zur Zahlung ab einem bestimmten Schritt (z. B. ab „Ideen auswählen“);
• durchschnittlicher Warenkorbwert;
• Anteil von Stornierungen/Rücksendungen.

Wichtig: Diese Zahlen leben nicht isoliert – zwischen ihnen gibt es Kausalität. Ein Schritt mit hohem Drop‑off ist nicht immer schlecht: Vielleicht filtert er unpassende Nutzer, und es gehen nur diejenigen weiter, für die das Szenario tatsächlich nützlich ist. Analytics bedeutet daher nicht nur „Prozente zählen“, sondern eine Geschichte anhand der Daten erzählen zu können.

Damit man all diese Prozente und Funnels überhaupt berechnen kann, brauchen wir Rohereignisse: wer wann welchen Schritt durchlaufen (oder nicht durchlaufen) hat. Im nächsten Abschnitt einigen wir uns auf das Format solcher Ereignisse.

4. Wie Analytics‑Ereignisse aussehen

Bevor wir Code schreiben, müssen wir uns auf das Format des „Ereignisses“ (event) einigen, das wir aus dem Widget und dem Backend senden.

Typischerweise enthält ein Analytics‑Ereignis:

• wer: Nutzer‑ oder zumindest Sitzungs‑ID;
• welcher Workflow und welche Version;
• welcher Schritt;
• was passiert ist (Ereignistyp);
• ob es erfolgreich war, wie lange es gedauert hat;
• ein paar Metadaten (Locale, Device usw.).

Ein vereinfachtes Ereignisschema für den Workflow könnte so aussehen:

export type WorkflowEventType =
  | "workflow_started"
  | "workflow_finished"
  | "step_started"
  | "step_completed"
  | "step_failed";

export interface WorkflowAnalyticsEvent {
  eventId: string;              // uuid
  timestamp: string;            // ISO-String
  userId?: string;              // falls deanonymisierbar
  conversationId?: string;      // ChatGPT-Dialog-ID (falls verfügbar)
  workflowId: string;           // unsere interne Kennung
  workflowType: "gift_selection";
  workflowVersion: string;      // z. B. "1.2.0" oder "1.2.0-A"
  stepName?: string;            // collect_budget, suggest_ideas usw.
  eventType: WorkflowEventType;
  toolName?: string;            // falls mit Tool-Call verbunden
  success?: boolean;
  errorCode?: string | null;
  durationMs?: number;
  metadata?: Record<string, unknown>;
}

Einige Besonderheiten:

Erstens: workflowVersion ist sehr wichtig, wenn Sie A/B‑Tests machen wollen – ohne sie werden Sie nie herausfinden, welche Variante des Szenarios bessere Zahlen liefert.

Zweitens: conversationId oder eine andere Correlation‑ID ermöglicht es, Ereignisse zu verknüpfen: Schritte im Widget, Tool‑Aufrufe im MCP und den Textdialog. In späteren Modulen sprechen wir noch über Tracing und Observability; die Gewohnheit, von Anfang an an „end‑to‑end“‑Kennungen zu denken, ist sehr hilfreich.

Drittens: Man muss nicht alles ins Ereignis packen – vollständige Nachrichtentexte, E‑Mail, Adressen und andere PII sollten vermieden oder streng anonymisiert werden. Darauf kommen wir gegen Ende noch einmal zurück.

5. Instrumentierung im Widget (Next.js + Apps SDK)

Jetzt das Spannendste: Wie bringen wir unser GiftGenius‑Widget dazu, die Schritte still mitzuprotokollieren, wenn der Nutzer das Szenario durchläuft.

Nehmen wir an, Sie haben in den vorherigen Vorlesungen schon etwas in der Art gebaut:

// components/GiftWizard.tsx
type StepId = "recipient" | "budget" | "ideas" | "review" | "checkout";

export function GiftWizard() {
  const [currentStep, setCurrentStep] = useState<StepId>("recipient");
  const [workflowId] = useState(() => crypto.randomUUID());

  // ... hier werden die verschiedenen Schritte gerendert
}

Fügen wir eine kleine „Analytics‑Schicht“ in Form eines Hooks hinzu.

Hook useWorkflowAnalytics

Wir bauen eine Hülle, die workflowId, workflowVersion kennt und ein Ereignis an unseren Next.js‑API‑Route /api/workflow-analytics senden kann.

// lib/useWorkflowAnalytics.ts
import { useCallback } from "react";
import type { WorkflowAnalyticsEvent, WorkflowEventType } from "./types";

const WORKFLOW_VERSION = "1.0.0";

export function useWorkflowAnalytics(
  workflowId: string,
  workflowType: WorkflowAnalyticsEvent["workflowType"] = "gift_selection"
) {
  const sendEvent = useCallback(
    async (payload: Omit<WorkflowAnalyticsEvent, "eventId" | "timestamp" | "workflowType" | "workflowVersion" | "workflowId">) => {
      const event: WorkflowAnalyticsEvent = {
        eventId: crypto.randomUUID(),
        timestamp: new Date().toISOString(),
        workflowId,
        workflowType,
        workflowVersion: WORKFLOW_VERSION,
        ...payload,
      };

      // einfache Sendung an die API; in Prod könnte man Buffer/Debounce hinzufügen
      await fetch("/api/workflow-analytics", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify(event),
      });
    },
    [workflowId, workflowType]
  );

  const trackStepEvent = useCallback(
    async (stepName: string, eventType: WorkflowEventType, extra?: Partial<WorkflowAnalyticsEvent>) => {
      await sendEvent({ stepName, eventType, ...extra });
    },
    [sendEvent]
  );

  return { sendEvent, trackStepEvent };
}

Wichtig ist hier, dass der Hook nicht von einem konkreten UI‑Schritt abhängt. Er kennt nur stepName und eventType. Die konkreten Komponenten sagen ihm: „Hier habe ich den Schritt begonnen“, „hier habe ich ihn beendet“ usw.

workflow_started und workflow_finished senden

In der Komponente GiftWizard kann man beim Mounten und Unmounten den Beginn und das Ende des Szenarios registrieren:

// components/GiftWizard.tsx
export function GiftWizard() {
  const [currentStep, setCurrentStep] = useState<StepId>("recipient");
  const [workflowId] = useState(() => crypto.randomUUID());
  const { sendEvent } = useWorkflowAnalytics(workflowId);

  useEffect(() => {
    void sendEvent({ eventType: "workflow_started" });
    return () => {
      void sendEvent({ eventType: "workflow_finished" });
    };
  }, [sendEvent]);

  // ...
}

Natürlich ist das Beenden beim Unmounten eine grobe Näherung: Der Nutzer kann den Chat einfach minimieren oder in einen anderen Dialog wechseln. Aber selbst diese grobe Metrik vermittelt schon ein Gefühl dafür, wie viele Szenarien überhaupt „irgendwohin“ gelangen.

Ereignisse pro Schritt verfolgen

Jetzt sorgen wir dafür, dass jeder Schritt selbst in die Analytics meldet. Zunächst fügen wir eine einfache Hülle hinzu:

interface StepProps {
  stepId: StepId;
  onNext: () => void;
  trackStepEvent: (stepName: string, eventType: WorkflowEventType, extra?: Partial<WorkflowAnalyticsEvent>) => Promise<void>;
}

function StepRecipient({ stepId, onNext, trackStepEvent }: StepProps) {
  useEffect(() => {
    void trackStepEvent(stepId, "step_started");
  }, [stepId, trackStepEvent]);

  const handleSubmit = async () => {
    // ... Validierung, Speicherung in widgetState
    await trackStepEvent(stepId, "step_completed");
    onNext();
  };

  return (
    <div>
      {/* Formfelder des Empfängers */}
      <button onClick={handleSubmit}>Weiter</button>
    </div>
  );
}

In GiftWizard übergeben wir trackStepEvent:

export function GiftWizard() {
  // ...
  const { trackStepEvent } = useWorkflowAnalytics(workflowId);

  const goToNext = () => {
    setCurrentStep((prev) => NEXT_STEP[prev]);
  };

  if (currentStep === "recipient") {
    return (
      <StepRecipient
        stepId="recipient"
        onNext={goToNext}
        trackStepEvent={trackStepEvent}
      />
    );
  }

  // die übrigen Schritte...
}

Analog kann man in Schritten mit potenziellen Fehlern (z. B. ein externer API‑Aufruf in suggest_ideas) bei Misserfolg "step_failed" mit errorCode senden und bei erfolgreichem Laden der Varianten "step_completed".

So erhalten wir:

• eine klare Ereignisliste: wann Schritte starten und enden;
• die Möglichkeit, die Schrittzeit zu berechnen: Differenz zwischen "step_started" und "step_completed";
• Sichtbarkeit darüber, welche Schritte am häufigsten mit "step_failed" enden.

6. Instrumentierung im Backend/MCP

Client‑seitige Analytics sind gut, aber das Widget lebt in einer ziemlich fragilen Welt: Browser des Nutzers, iFrame, Sandbox‑Einschränkungen und all das. Daher sollten parallel Ereignisse auf der Serverseite geloggt werden – in MCP‑Tools oder im Backend‑API Ihrer App.

Angenommen, Sie haben ein Tool suggest_gifts, das die eigentliche Schwerarbeit erledigt: es greift auf den Product‑Feed zu, wendet Filter an und liefert Geschenke zurück. Innerhalb eines solchen Tools können Sie sowohl Business‑Logik als auch Analytics‑Ereignisse protokollieren.

Ein hypothetischer MCP‑Tool‑Handler in TypeScript könnte so aussehen:

// mcp/tools/suggestGifts.ts
import type { SuggestGiftsArgs } from "../schemas";
import { logWorkflowEvent } from "../analytics/log";

export async function handleSuggestGifts(args: SuggestGiftsArgs, context: { workflowId: string; stepName: string }) {
  const startedAt = Date.now();

  try {
    // ... Hauptlogik der Ideenauswahl

    await logWorkflowEvent({
      workflowId: context.workflowId,
      workflowType: "gift_selection",
      workflowVersion: "1.0.0",
      stepName: context.stepName,
      eventType: "step_completed",
      toolName: "suggest_gifts",
      success: true,
      durationMs: Date.now() - startedAt,
    });

    return {
      content: [{ type: "text", text: "Habe 5 Geschenkideen gefunden." }],
      _meta: {
        // Rohdaten für das Widget
      },
    };
  } catch (e) {
    await logWorkflowEvent({
      workflowId: context.workflowId,
      workflowType: "gift_selection",
      workflowVersion: "1.0.0",
      stepName: context.stepName,
      eventType: "step_failed",
      toolName: "suggest_gifts",
      success: false,
      errorCode: "SUGGEST_FAILED",
      durationMs: Date.now() - startedAt,
    });
    throw e;
  }
}

Und logWorkflowEvent kann in dieselbe Tabelle/dasselbe Storage schreiben, in das auch Ereignisse vom Frontend abgelegt werden – einfach mit der Markierung "source": "backend".

Warum Server‑Analytics zuverlässiger ist

Erstens: Ein Tool‑Aufruf hat entweder stattgefunden oder nicht – das ist eine harte Tatsache, keine Heuristik „der Nutzer scheint auf den Button geklickt zu haben“.

Zweitens: Auf dem Server lassen sich Daten einfacher aggregieren: Sie können zählen, wie oft jedes Tool aufgerufen wurde, wie hoch der durchschnittliche durationMs ist und welcher Anteil der Aufrufe mit einem Fehler endet.

Drittens: So sehen Sie den Unterschied zwischen einem UX‑Problem (der Nutzer erreicht den Schritt, in dem das Tool aufgerufen wird, nicht) und einem technischen Problem (man erreicht den Schritt, aber das Tool fällt häufig aus).

7. Daten lesen: Engpässe finden

Angenommen, Sie haben das Senden von "workflow_started", "step_started", "step_completed" und "step_failed" aus Widget und MCP bereits implementiert, und im Storage haben sich genügend Daten gesammelt. Stellen wir uns vor, Sie haben schon eine gewisse Menge Daten zu GiftGenius gesammelt und eine zusammenfassende Statistik pro Schritt erhalten. In der Tabelle unten sind beispielhafte Zahlen für 1000 gestartete Workflows aufgeführt:

Worauf man hier achten sollte:

Erstens: Der Schritt budget ist ein offensichtlicher Engpass. Hoher Drop‑off (26 %) und deutlich höhere Durchschnittszeit. Möglicherweise fragen Sie zu viel zu Währungen/Steuern ab, die Formulierungen sind unklar, oder die Nutzer sind sich beim Budget einfach unsicher. Ein guter Kandidat, um den Schritt zu vereinfachen, in zwei Unterschritte zu teilen oder die Fragen anders zu formulieren.

Zweitens: review hat ebenfalls starken Abfall. Vielleicht ist die UI der Geschenk‑Karten überladen oder es ist unklar, was „einen Geschenkartikel liken“ bedeutet. Eventuell liefert das Modell zu viele Varianten und das Widget wirkt wie eine endlose Liste. Hier lohnt es sich, nicht nur auf Zahlen, sondern auch auf Screenshots/Sitzungsaufzeichnungen (falls vorhanden) zu schauen – oder das Szenario zumindest manuell als Nutzer durchzugehen.

Drittens: checkout verliert 16 % – für ein Commerce‑Szenario ist das viel Geld. Man muss jedoch verstehen, wo sie verloren gehen: beim Auschecken, an Fehlern des Zahlungsproviders, daran, dass der Nutzer es sich anders überlegt hat. Das ist kein reines UX‑Thema, sondern eine Kombination aus UX und Business‑Einschränkungen.

Es ist wichtig, UI‑ und Modellprobleme zu unterscheiden.

• Wenn Nutzer häufig zum vorherigen Schritt zurückkehren und Antworten ändern, ist das ein Signal für eine unklare oder schlecht formulierte Frage.
• Wenn ein Schritt schnell abgeschlossen wird, aber der Tool‑Aufruf darin häufig fehlschlägt, ist es ein Backend/MCP‑Problem.
• Wenn ein Schritt lange dauert, ohne dass es Fehler oder Rücksprünge gibt, liest der Nutzer möglicherweise einen Longread‑Text, den er gar nicht braucht.

8. Experimente und A/B‑Tests des Workflows

Zahlen verbessern von sich aus nichts. Damit Analytics Nutzen stiftet, müssen Sie Experimente durchführen können: Schritte ändern und vergleichen, ob es besser geworden ist.

Im Kontext der ChatGPT App ist das typische Experiment der Vergleich zweier Versionen eines Schritts oder der Schrittfolge:

• langer Wizard mit mehreren einfachen Screens versus ein komplexes Formular;
• unterschiedliche Formulierungen der Fragen;
• unterschiedliche Reihenfolge der Schritte (z. B. Budget früher oder später fragen);
• unterschiedliche Tool‑Gating‑Strategien (im ersten Schritt weniger Tools, im zweiten mehr).

Eine gute Gewohnheit ist, die Szenarioversion in workflowVersion festzuhalten und dort die Experiment‑ID zu ergänzen, z. B. "1.3.0-A" und "1.3.0-B".

Einfachster A/B‑Split im Widget

Im Produktivbetrieb möchten Sie selbstverständlich ein stabiles Assignment auf Nutzer‑ oder Sitzungs‑Ebene (über das Backend). Für das Lernbeispiel genügt eine zufällige Variantenzuordnung.

// lib/useWorkflowVariant.ts
import { useMemo } from "react";

export type WorkflowVariant = "A" | "B";

export function useWorkflowVariant(): WorkflowVariant {
  return useMemo(() => {
    return Math.random() < 0.5 ? "A" : "B";
  }, []);
}

In GiftWizard bestimmen wir die Variante und geben sie in die Analytics weiter:

export function GiftWizard() {
  const [workflowId] = useState(() => crypto.randomUUID());
  const variant = useWorkflowVariant();
  const { sendEvent, trackStepEvent } = useWorkflowAnalytics(
    workflowId,
    "gift_selection"
  );

  useEffect(() => {
    void sendEvent({
      eventType: "workflow_started",
      metadata: { variant },
    });
  }, [sendEvent, variant]);

  // anschließend können Texte/Struktur der Schritte je nach variant variieren
}

Auf dem Server kann man die fixe "1.0.0" durch etwas wie "1.1.0-A" und "1.1.0-B" ersetzen oder einfach metadata.variant loggen und in der Analytics danach gruppieren.

Das Wichtigste beim A/B‑Test: im Voraus eine Zielmetrik wählen. Zum Beispiel: „Wir wollen die Completion Rate des Szenarios von 42 % auf 50 % erhöhen“ oder „die Zeit im Schritt budget um 20 % verringern“. Ohne Zielmetrik ähnelt jede Umstrukturierung des Workflows einem Umbau nach dem Prinzip „Wir haben den Schrank umgestellt – sieht irgendwie schöner aus“.

9. Datenschutz und Datenethik

Früher haben wir schon am Rande erwähnt, dass man in metadata und Analytics‑Ereignisse besser keine PII im Klartext zieht. Während wir Metriken diskutieren, ist es leicht, sich dazu hinreißen zu lassen, alles zu loggen. Man muss jedoch bedenken, dass Sie innerhalb von ChatGPT arbeiten und der Nutzer vernünftigerweise erwarten kann, dass seine privaten Nachrichten nicht im Rohformat in eine externe Analytics fließen.

Einige einfache Regeln, an die Sie sich schon jetzt halten sollten – noch bevor die Module zu Sicherheit und Store kommen:

• Erstens: Loggen Sie keine vollständigen Nachrichtentexte des Nutzers. Stattdessen kann man die Länge der Nachricht, den Antworttyp (Zahl, „Ja/Nein“, Auswahl aus Liste) oder anonymisierte Merkmale wie „Antwort leer/unvollständig/geändert“ speichern.
• Zweitens: Loggen Sie keine eindeutig identifizierenden Informationen (PII), wenn Sie sie für die Business‑Logik nicht brauchen: E‑Mail, Telefonnummern, Adressen, vollständige Namen. Wenn es ohne nicht geht, speichern Sie sie in einem anderen, geschützten Bereich und beschränken Sie den Zugriff streng.
• Drittens: Gehen Sie sorgfältig mit dem Dialogkontext um. Wenn Sie conversationId speichern, stellen Sie sicher, dass Sie in der Analytics nicht versuchen, einzelne Dialoge ohne triftigen Grund und Rechtsgrundlage zu „Super‑Profilen“ zusammenzuführen.
• Viertens: Beachten Sie die Richtlinien von OpenAI und die Anforderungen des Stores (wir gehen in den Modulen zu Veröffentlichung und Sicherheit ausführlich darauf ein), in denen klar steht, welche Daten aus ChatGPT herausgetragen werden dürfen und welche nicht. Es ist hilfreich, schon beim Design der Analytics Anonymisierung und Datenminimierung vorzusehen, um später nicht das halbe System umzuschreiben.

Und schließlich denken Sie daran, dass UX‑Analytics keine totale Überwachung und schon gar nicht „Surveillance“ im Stil von Big Brother ist. Ziel ist es, Szenarien zu verbessern und die Frustration der Nutzer zu verringern – nicht ein Big‑Brother‑Dashboard zu bauen: „wer um 2:37 Uhr den Checkout nicht erreicht hat“.

10. Typische Fehler in der UX‑Analytics von Workflows

Fehler Nr. 1: „Wir sind noch nicht im Prod, Metriken später“.
Sehr oft denken Entwickler erst dann über Analytics nach, wenn die App bereits von echten Menschen genutzt wird. Die Ereignisse werden „im Nachhinein“ eingeführt, die Daten sind lückenhaft, und alte und neue Szenarioversionen lassen sich kaum vergleichen. Den minimalen Funnel ("workflow_started", "step_started", "step_completed", "workflow_finished") baut man am besten sofort ein, solange der Code noch relativ einfach ist.

Fehler Nr. 2: Nur Erfolge loggen und Fehler ignorieren.
Manchmal gibt es in den Logs nur "step_completed", aber "step_failed" schreibt niemand, weil „das sollte ja nicht abstürzen“. Das Ergebnis: Sie sehen, dass wenige Leute bis zu einem bestimmten Schritt kommen, verstehen aber nicht, ob sie selbst gegangen sind oder durch Fehler herausgeflogen sind. Loggen Sie immer sowohl den erfolgreichen Abschluss eines Schritts als auch den nicht erfolgreichen – mit zumindest grobem errorCode.

Fehler Nr. 3: Vollständige fehlende Bindung an die Workflow‑Version.
Sie ändern Texte, die Reihenfolge der Schritte, führen Tool‑Gating ein, aber in den Ereignissen steht immer dieselbe workflowVersion: "1.0.0". Einen Monat später schauen Sie auf die Diagramme und können nicht erkennen, was vor und was nach den Änderungen war. Die Fixierung der Szenarioversion und – falls nötig – der A/B‑Variante ist ein Pflichtteil der Analytics.

Fehler Nr. 4: Zu detaillierte Analytics ohne Anlass.
Das Gegenteil: sofort ein „perfektes“ Ereignisschema mit 50 Feldern bauen, jeden Pixel‑Klick und jede neu getippte Taste loggen. Erstens kann das den Datenschutz verletzen. Zweitens sind solche Daten schwer zu analysieren, und Sie gehen im Rauschen unter. Starten Sie besser mit einem kleinen Set an Ereignissen und Metriken, die tatsächlich konkrete Produktfragen beantworten – und erweitern Sie das System bei Bedarf.

Fehler Nr. 5: Inkonsistenz bei Schritt‑ und Szenarionamen.
Manchmal heißt der Schritt im Code budget, in der Analytics collect_budget und im Report „der Schritt mit der Budgetfrage“. Nach ein paar Wochen weiß niemand mehr, was was ist. Es ist hilfreich, beim Design des Workflows stabile Schritt‑IDs (stepName) zu vereinbaren und sie in UI, Logs und Reports zu verwenden.

Fehler Nr. 6: Metriken, die niemand benutzt.
Die traurigsten Geschichten: Sie haben sorgfältig viele Daten gesammelt, das Senden von Ereignissen aus Widget und MCP eingerichtet – aber niemand öffnet später die Dashboards oder trifft Entscheidungen. Analytics um der Analytics willen ist nutzlos; fragen Sie sich immer: „Welche Entscheidung kann ich auf Basis dieser Metrik treffen?“ Wenn es darauf keine Antwort gibt, brauchen Sie die Metrik derzeit nicht.