Analityka UX workflow: mierzymy efektywność kroków

1. Po co w ogóle mierzyć workflow

Krótko mówiąc: bez analityki działasz w trybie „wydaje mi się”, a nie „wiem”.

W poprzednich wykładach tego modułu podzieliliśmy już scenariusz na kroki, przydzieliliśmy role GPT, widżetowi i MCP, omawialiśmy tool‑gating i przechowywanie stanu między krokami. Teraz spojrzymy na tę samą konstrukcję oczami analityka: czy to wszystko działa tak, jak zakładaliśmy, i gdzie użytkownicy faktycznie się zatrzymują.

W zwykłym webie wszyscy dawno przyzwyczaili się do lejków: ile osób przyszło na landing, ile włożyło produkt do koszyka, ile dotarło do płatności. W ChatGPT App jest podobnie, tylko zamiast stron masz kroki workflow, a zamiast „kliknięcia Kup” — kombinację wypowiedzi użytkownika, wywołania narzędzia i interakcji z widżetem.

Kiedy budujesz złożony scenariusz bez metryk, nie widzisz:

• na którym kroku ludzie najczęściej „odpadają”;
• gdzie się zawieszają i czytają po minucie (albo po prostu poszli po herbatę i nie wrócili);
• który krok w ogóle nie daje wartości i tylko irytuje;
• jak zmiany w promptach lub tool gatingu wpływają na zachowanie.

Cel analityki po krokach jest prosty: nauczyć się zwiększać odsetek zakończonych scenariuszy, skracać czas do rezultatu i zmniejszać liczbę błędów oraz zgłoszeń do wsparcia.

Od tego momentu workflow to nie tylko obiekt architektoniczny i nie tylko UX‑quest. To także mierzalna rzecz z liczbami.

2. Lejek scenariusza w ChatGPT App

W klasycznym webie lejek wygląda liniowo: Landing → Product → Cart → Checkout. W ChatGPT App obrazek jest trochę ciekawszy: użytkownik może „przeskoczyć” krok słowami, model może czasem pominąć krok, a widżet i tekst dialogu mogą się rozsynchronizować.

Niemniej podstawowa idea jest ta sama: mamy sekwencję kroków i na każdym z nich część użytkowników idzie dalej, a część — nie.

Weźmy naszego GiftGenius:

1. collect_recipient — ChatGPT i widżet zbierają podstawowe dane o odbiorcy (płeć, wiek, relacja, zainteresowania).
2. collect_budget — doprecyzowujemy budżet i walutę.
3. suggest_ideas — MCP / agent dobiera pomysły i zwraca karty prezentów do widżetu.
4. review_selection — użytkownik lajkuje / ukrywa pomysły i wybiera 1–2 faworytów.
5. checkout — tworzy się commerce intent, następuje złożenie zamówienia.

W formie lejka można to narysować tak:

flowchart TD
    A[Początek workflow] --> B["1\. Odbiorca"]
    B --> C["2\. Budżet"]
    C --> D["3\. Pomysły na prezenty"]
    D --> E["4\. Wybór prezentu"]
    E --> F["5\. Checkout"]

Ale ważne jest, by pamiętać: użytkownik może napisać w czacie „Przejdźmy od razu do płatności” albo „Pokaż najpierw drogie opcje”, a model zdecyduje się przeskoczyć część kroków. Dlatego analityka kroków w ChatGPT App to nie tylko ekrany UI, ale i zachowanie modelu: które kroki faktycznie są przechodzone, w jakiej kolejności i kto zainicjował przejście — użytkownik, widżet czy GPT.

3. Podstawowe metryki dla kroków

Zaczniemy od klasyki analityki produktowej i lekko dostosujemy ją do ChatGPT App.

Dla każdego workflow potrzebujemy przynajmniej czterech podstawowych wskaźników.

Dla wygody zestawmy je w tabeli:

Do nich prawie zawsze dodaje się metryki wysiłku:

• średni czas na kroku (gdzie ludzie „zawieszają się”);
• liczbę interakcji na kroku (ile wiadomości/kliknięć było potrzebne);
• odsetek kroków zakończonych błędem lub wymagających ponownej próby.

W kontekście scenariuszy LLM dochodzą jeszcze bardziej specyficzne rzeczy, jak trafność wyboru narzędzia przez model czy udział „halucynacyjnych” odpowiedzi na konkretnym kroku, ale to już bardziej zaawansowana historia — do niej dojdziemy w końcowych modułach.

Dla scenariuszy commerce ponad krokami nakłada się metryki biznesowe:

• konwersja do płatności od startu workflow;
• konwersja do płatności od konkretnego kroku (np. od „dobór pomysłów”);
• średni koszyk;
• odsetek anulacji/zwrotów.

Ważne: te liczby nie żyją same dla siebie — łączy je historia przyczynowo‑skutkowa. Krok z dużym drop‑offem nie zawsze jest zły: możliwe, że filtruje nieodpowiednich użytkowników i dalej idą tylko ci, dla których scenariusz jest realnie użyteczny. Dlatego analityka to nie tylko „liczyć procenty”, ale umieć opowiadać historię danymi.

Aby te procenty i lejki było w ogóle z czego policzyć, potrzebujemy surowych zdarzeń: kto, kiedy i jaki krok przeszedł (lub nie przeszedł). W kolejnym rozdziale umówimy się co do formatu takich zdarzeń.

4. Jak wyglądają zdarzenia analityczne

Zanim napiszemy kod, musimy uzgodnić format „zdarzenia” (event), które będziemy wysyłać z widżetu i backendu.

Zwykle zdarzenie analityczne zawiera:

• kto: identyfikator użytkownika albo przynajmniej sesji;
• jaki to workflow i jaka jego wersja;
• jaki krok;
• co się wydarzyło (typ zdarzenia);
• czy było udane, ile zajęło czasu;
• odrobinę metadanych (lokalizacja, urządzenie itp.).

Uproszczony schemat zdarzeń dla workflow można opisać tak:

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

export interface WorkflowAnalyticsEvent {
  eventId: string;              // uuid
  timestamp: string;            // ciąg w formacie ISO
  userId?: string;              // jeśli można zdeanonimizować
  conversationId?: string;      // id rozmowy w ChatGPT (jeśli dostępne)
  workflowId: string;           // nasz wewnętrzny identyfikator
  workflowType: "gift_selection";
  workflowVersion: string;      // na przykład "1.2.0" lub "1.2.0-A"
  stepName?: string;            // collect_budget, suggest_ideas itd.
  eventType: WorkflowEventType;
  toolName?: string;            // jeśli związane z wywołaniem narzędzia (tool-call)
  success?: boolean;
  errorCode?: string | null;
  durationMs?: number;
  metadata?: Record<string, unknown>;
}

Kilka niuansów:

Po pierwsze, workflowVersion jest bardzo ważne, jeśli zamierzasz robić testy A/B: bez tego nigdy nie dowiesz się, która wersja scenariusza daje lepsze wyniki.

Po drugie, conversationId lub inny identyfikator korelacyjny pozwala powiązać zdarzenia: kroki w widżecie, wywołania narzędzi w MCP i tekstowy dialog. W kolejnych modułach będziemy mówić o trasowaniu i obserwowalności, ale nawyk myślenia od początku o „przepływowych” identyfikatorach jest bardzo przydatny.

Po trzecie, nie ma potrzeby wrzucać do zdarzenia wszystkiego jak leci: pełnych tekstów wiadomości, e‑maili, adresów i innego PII lepiej unikać lub mocno anonimizować — o tym jeszcze porozmawiamy pod koniec.

5. Instrumentacja w widżecie (Next.js + Apps SDK)

Teraz najciekawsze: jak sprawić, by nasz widżet GiftGenius sam po cichu raportował kroki, gdy użytkownik przechodzi scenariusz.

Załóżmy, że w poprzednich wykładach zrobiliście coś w tym stylu:

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

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

  // ... tutaj renderujemy różne kroki
}

Dodamy niewielką „warstwę analityki” w postaci hooka.

Hook useWorkflowAnalytics

Zrobimy otoczkę, która zna workflowId, workflowVersion i potrafi wysłać zdarzenie do naszej trasy API w Next.js /api/workflow-analytics.

// 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,
      };

      // proste wysłanie do API; w produkcji można dodać bufor/debounce
      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 };
}

Tu ważne jest to, że hook nie zależy od konkretnego UI kroku. Po prostu wie, czym są stepName i eventType. Konkretnym komponentom powiemy: „tu zaczynam krok”, „tu go kończę” i tak dalej.

Wysyłamy workflow_started i workflow_finished

W komponencie GiftWizard można w momencie montowania i odmontowania zarejestrować start i zakończenie scenariusza:

// 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]);

  // ...
}

Oczywiście, zakończenie przy odmontowaniu to grube przybliżenie: użytkownik może po prostu zwinąć czat lub przejść do innego dialogu. Ale nawet taka metryka daje już obraz tego, ile scenariuszy „dotarło dokądkolwiek”.

Śledzimy zdarzenia kroków

Zróbmy teraz tak, aby każdy krok sam raportował się do analityki. Na początek dodamy prostą otoczkę:

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 () => {
    // ... walidacja, zapis do widgetState
    await trackStepEvent(stepId, "step_completed");
    onNext();
  };

  return (
    <div>
      {/* pola formularza odbiorcy */}
      <button onClick={handleSubmit}>Dalej</button>
    </div>
  );
}

W GiftWizard przekazujemy 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}
      />
    );
  }

  // pozostałe kroki...
}

Podobnie, w krokach, gdzie mogą wystąpić błędy (np. zapytanie do zewnętrznego API w suggest_ideas), można przy niepowodzeniu wysłać "step_failed" z errorCode, a przy udanym wczytaniu propozycji — "step_completed".

W ten sposób zyskujemy:

• czytelną listę zdarzeń: kiedy kroki startują i kończą się;
• możliwość policzenia czasu kroku: różnica między "step_started" a "step_completed";
• widoczność tego, które kroki najczęściej kończą się "step_failed".

6. Instrumentacja po stronie backend / MCP

Analityka po stronie klienta jest dobra, ale widżet żyje w dość kruchym świecie: przeglądarka użytkownika, iframe, ograniczenia piaskownicy i wszystko, co z tym związane. Dlatego równolegle warto logować zdarzenia po stronie serwera — w narzędziach MCP lub backendowym API twojej App.

Na przykład masz narzędzie suggest_gifts, które wykonuje ciężką pracę: chodzi po product feed, stosuje filtry i zwraca prezenty. Wewnątrz takiego narzędzia możesz logować zarówno logikę biznesową, jak i zdarzenia analityczne.

Przykładowy handler MCP‑tool w TypeScript może wyglądać tak:

// 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 {
    // ... główna logika doboru pomysłów

    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: "Znaleziono 5 pomysłów na prezent." }],
      _meta: {
        // surowe dane dla widżetu
      },
    };
  } 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;
  }
}

A logWorkflowEvent może pisać do tej samej tabeli/magazynu, gdzie trafiają zdarzenia z frontu, tylko z oznaczeniem "source": "backend".

Dlaczego analityka serwerowa jest bardziej niezawodna

Po pierwsze, wywołanie narzędzia albo zaszło, albo nie — to twardy fakt, a nie heurystyka „użytkownik chyba kliknął przycisk”.

Po drugie, na serwerze łatwiej agregować dane: możesz liczyć, ile razy wywoływane jest każde narzędzie, jaki ma średni durationMs i jaki odsetek wywołań kończy się błędem.

Po trzecie, widzisz różnicę między problemem UX (użytkownik nie dociera do kroku, gdzie wywoływane jest narzędzie) a problemem technicznym (do kroku docierają, ale narzędzie często się wywraca).

7. Jak czytać dane: szukamy wąskich gardeł

Załóżmy, że zaimplementowałeś już wysyłkę zdarzeń "workflow_started", "step_started", "step_completed" i "step_failed" z widżetu i MCP, i w magazynie zebrało się dość danych. Wyobraźmy sobie, że zebraliście już pewną liczbę danych o GiftGenius i otrzymaliście statystykę zbiorczą po krokach. W poniższej tabeli przedstawiono przykładowe liczby dla 1000 uruchomionych workflow:

Na co warto tu zwrócić uwagę:

Po pierwsze, krok budget — oczywiste wąskie gardło. Wysoki drop‑off (26 %) i zauważalnie wyższy średni czas. Być może pytasz zbyt wiele o waluty/podatki, sformułowania są niejasne, albo ludzie po prostu nie mają pewności co do budżetu. To dobry kandydat do uproszczenia kroku, rozbicia go na dwa podkroki lub zmiany brzmienia pytań.

Po drugie, review też daje spory odpływ. Może UI kart prezentów jest przeładowany albo użytkownik nie rozumie, co znaczy „zalaikować” prezent. Może model zwraca zbyt wiele opcji i widżet przypomina nieskończoną listę. Warto zajrzeć nie tylko w liczby, ale i w zrzuty ekranu/nagrania sesji (jeśli je prowadzisz), albo przynajmniej przejść scenariusz ręcznie jak użytkownik.

Po trzecie, checkout traci 16 % — dla scenariusza commerce to dużo pieniędzy. Ale trzeba zrozumieć, gdzie je tracisz: przy finalizacji zamówienia, na błędach dostawcy płatności, czy dlatego, że użytkownik po prostu się rozmyślił. To już nie czysty temat UX, a kombinacja UX + ograniczeń biznesowych.

Ważne jest umieć odróżniać problemy UI od problemów modelu.

• Jeśli użytkownicy często wracają do poprzedniego kroku i zmieniają odpowiedzi — to sygnał o niejasnym lub źle sformułowanym pytaniu.
• Jeśli krok szybko się kończy, ale wywołanie narzędzia na nim często się wywraca — to problem backend/MCP.
• Jeśli krok trwa długo i nie ma ani błędów, ani powrotów, możliwe, że użytkownik po prostu czyta długi tekst, którego nie potrzebuje.

8. Eksperymenty i testy A/B w workflow

Same liczby niczego nie poprawią. Żeby z analityki był pożytek, trzeba umieć robić eksperymenty: zmieniać kroki i porównywać, czy jest lepiej.

W kontekście ChatGPT App typowy eksperyment to porównanie dwóch wersji kroku lub sekwencji kroków:

• długi kreator z kilkoma prostymi ekranami kontra jeden złożony formularz;
• różne sformułowania pytań;
• różny porządek kroków (np. budżet wcześniej lub później);
• różne strategie tool gatingu (na pierwszym kroku mniej tools, na drugim — więcej).

Dobrą praktyką jest utrwalać wersję scenariusza w workflowVersion i dodawać tam identyfikator eksperymentu, np. "1.3.0-A" i "1.3.0-B".

Najprostszy split A/B w widżecie

W produkcji będziesz chciał stabilny przydział na poziomie użytkownika lub sesji (przez backend), ale do przykładu edukacyjnego wystarczy losowy wybór wariantu.

// 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";
  }, []);
}

W GiftWizard określamy wariant i przekazujemy go do analityki:

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]);

  // dalej można zmieniać teksty/strukturę kroków w zależności od variant
}

Na serwerze możesz zamienić twarde "1.0.0" na coś w rodzaju "1.1.0-A" i "1.1.0-B" lub po prostu logować metadata.variant i grupować po nim w analityce.

Główny sens testu A/B: z góry wybrać metrykę docelową. Na przykład: „chcemy podnieść completion rate scenariusza z 42% do 50%” albo „zmniejszyć czas na kroku budget o 20%”. Bez metryki docelowej każda restrukturyzacja workflow będzie przypominać remont na zasadzie „przestawiliśmy szafę, chyba jest ładniej”.

9. Prywatność i etyka danych

Wcześniej wspomnieliśmy już mimochodem, że w metadata i zdarzeniach analityki lepiej nie przenosić PII wprost. Łatwo się rozpędzić, gdy mówimy o metrykach, i zacząć logować wszystko. Trzeba jednak pamiętać, że działasz wewnątrz ChatGPT, a użytkownik może rozsądnie oczekiwać, że jego prywatne wiadomości nie wylatują do zewnętrznej analityki w surowej postaci.

Kilka prostych zasad, których warto trzymać się już teraz, zanim dojdziemy do modułów o bezpieczeństwie i Store:

• Po pierwsze, nie loguj pełnych tekstów wiadomości użytkownika. Zamiast nich możesz zapisywać długość wiadomości, typ odpowiedzi (liczba, „tak/nie”, wybór z listy) lub zanonimizowane cechy w rodzaju „odpowiedź pusta/niepełna/zmieniona”.
• Po drugie, nie loguj jednoznacznie identyfikujących informacji (PII), jeśli nie są potrzebne do logiki biznesowej: e‑mail, telefony, adresy, pełne imiona i nazwiska. Jeśli bez tego się nie da, przechowuj je w innym, chronionym środowisku i rygorystycznie ograniczaj dostęp.
• Po trzecie, uważnie podchodź do kontekstu dialogu. Jeśli zapisujesz conversationId, upewnij się, że w analityce nie próbujesz „sklejać” oddzielnych dialogów w super‑profile bez uzasadnionej przyczyny i podstawy prawnej.
• Po czwarte, zwróć uwagę na polityki OpenAI i wymagania Store (szczegółowo dojdziemy do tego w modułach o publikacji i bezpieczeństwie), gdzie jasno jest powiedziane, jakie dane można wynosić z ChatGPT, a jakich — nie. Na etapie projektowania analityki warto od razu założyć anonimizację i minimalizację danych, by później nie przepisywać pół systemu.

I wreszcie pamiętaj, że analityka UX to nie totalna inwigilacja i na pewno nie surveillance w duchu Big Brothera. Cel — ulepszać scenariusze i zmniejszać frustrację użytkownika, a nie budować tablicę Big Brother „kto o 2:37 w nocy nie dotarł do checkoutu”.

10. Typowe błędy w analityce UX workflow

Błąd nr 1: „Jeszcze nie jesteśmy na produkcji, metryki później”.
Bardzo często programiści zaczynają myśleć o analityce w momencie, gdy App jest już używana przez prawdziwych ludzi. W efekcie zdarzenia wprowadza się „z mocą wsteczną”, dane są porwane, a porównanie starej i nowej wersji scenariusza jest prawie niemożliwe. Minimalny lejek ("workflow_started", "step_started", "step_completed", "workflow_finished") lepiej założyć od razu, póki kod jest względnie prosty.

Błąd nr 2: Logowanie tylko sukcesów i ignorowanie błędów.
Czasem w logach są tylko "step_completed", a "step_failed" nikt nie zapisuje, bo „przecież nie powinno padać”. W rezultacie widzisz, że do jakiegoś kroku dociera mało osób, ale nie rozumiesz, czy odeszli sami, czy wyrzuciły ich błędy. Zawsze loguj zarówno udane zakończenie kroku, jak i nieudane, z choćby zgrubnym errorCode.

Błąd nr 3: Brak powiązania z wersją workflow.
Zmieniasz teksty, kolejność kroków, wprowadzasz tool gating, a w zdarzeniach cały czas widnieje workflowVersion: "1.0.0". Po miesiącu patrzysz na wykresy i nie możesz zrozumieć, co było przed zmianami, a co po nich. Utrwalanie wersji scenariusza i, w razie potrzeby, wariantu A/B — to obowiązkowy element analityki.

Błąd nr 4: Zbyt szczegółowa analityka bez powodu.
Przeciwna skrajność — od razu budować „idealny” schemat zdarzeń na 50 pól, logować każde kliknięcie w piksel i każde przepisywanie znaku. Po pierwsze, to może naruszać prywatność. Po drugie, takie dane trudno analizować i utoniesz w szumie. Lepiej zacząć od niewielkiego zestawu zdarzeń i metryk, które realnie odpowiadają na konkretne pytania produktowe, a potem rozwijać system w miarę potrzeb.

Błąd nr 5: Niespójność nazw kroków i scenariuszy.
Czasem w kodzie krok nazywa się budget, w analityce — collect_budget, a w raporcie — „krok z pytaniem o pieniądze”. Po paru tygodniach nikt nie pamięta, co jest czym. Na etapie projektowania workflow warto uzgodnić stabilne identyfikatory kroków (stepName) i używać ich w UI, logach i raportach.

Błąd nr 6: Posiadanie metryk, z których nikt nie korzysta.
Najsmutniejsza historia: skrupulatnie zebrałeś masę danych, ustawiłeś wysyłkę zdarzeń z widżetu i MCP, ale nikt potem nie otwiera dashboardów i nie podejmuje decyzji. Analityka dla samej analityki nie ma sensu; zawsze zadawaj sobie pytanie: „Jaką decyzję podejmę na podstawie tej metryki?”. Jeśli nie ma odpowiedzi — ta metryka na razie nie jest ci potrzebna.