AI będzie tak dobre, jak Twoje dane — dlaczego fundament wygrywa z dashboardem

W każdej firmie, z którą pracowałem, oczekiwania wobec danych wyglądają podobnie: zarząd chce dashboardów, prognoz, a od niedawna — AI. Rzeczy, które widać gołym okiem i robią wrażenie na slajdzie. Prawie nikt nie pyta o to, co jest pod spodem: czy dane, na których to wszystko stoi, są w ogóle dobre. A to jedyne pytanie, które naprawdę decyduje.

Biznes patrzy na szczyt piramidy

Wartość danych układa się w piramidę. Im wyżej, tym bardziej efektowny rezultat — i tam właśnie wędruje uwaga biznesu: raporty, analityka, a na szczycie sztuczna inteligencja. Problem w tym, że każdy poziom stoi na tym pod spodem, a dwie dolne warstwy — dane i ich architektura — są niewidoczne i wiecznie odkładane „na potem”.

To odwrócona kolejność inwestowania uwagi: najwięcej dostaje to, co na górze, najmniej — to, od czego wszystko zależy.

Fundament, którego nie widać: warstwa analityczna

W analityce internetowej fundamentem jest warstwa analityczna — dataLayer i schemat zdarzeń (event schema). To tu, zanim cokolwiek trafi do raportu, zapada decyzja: jakie zdarzenia zbierasz, jak je nazywasz, jakie parametry im towarzyszą, jak liczysz wartość. Tej warstwy nie widać na żadnym dashboardzie — a to ona określa, czy dashboard w ogóle mówi prawdę.

I rzecz kluczowa: narzędzie jest tu drugorzędne. GA4, Firebase, Amplitude, AppsFlyer — każde z nich, niezależnie od loga, wymaga pod spodem tego samego: dobrze zaprojektowanej architektury analitycznej. Jeśli Twój stack wygląda inaczej, teza się nie zmienia — zmienia się tylko nazwa w nagłówku panelu. Finalnie dane i tak lądują w hurtowni (przy stacku Google — w BigQuery), gdzie każda niespójność z warstwy zbierania mnoży się przez miliony wierszy.

Dobry vs rozjechany event

Nie musisz umieć czytać kodu, żeby zobaczyć problem. Poniżej ta sama konwersja — zakup — wysłana dwukrotnie. Oba zdarzenia „działają”, oba się wysyłają. Tylko jedno z nich da się później wykorzystać.

// Dobry event: spójny, kompletny, zgodny ze schematem
dataLayer.push({
  event: 'purchase',
  transaction_id: 'T-12345',
  value: 199.00,
  currency: 'PLN',
  items: [{ item_id: 'SKU-1', item_name: 'Buty', price: 199.00, quantity: 1 }]
});

// Rozjechany event: ta sama konwersja, inny zespół, inny tag
dataLayer.push({
  event: 'Purchase',     // inna wielkość liter → dla narzędzia to INNE zdarzenie
  value: '199,00 zł',    // tekst z walutą zamiast liczby → nie zsumujesz
  curr: 'pln',           // inna nazwa parametru → nikt jej nie podłączy
  items: 'Buty'          // brak struktury → produkty nie do odzyskania
});

Drugi wariant nie wywala żadnego błędu. Po prostu po cichu zatruwa dane: część zakupów ląduje pod osobną nazwą i znika z raportu, przychodu nie da się zsumować, produktów nie da się analizować. Nikt tego nie zauważa przez miesiące — bo na dashboardzie „coś tam jest”. Tę spójność nazw da się nawet egzekwować automatycznie; pisałem, jak reguła pilnuje taksonomii eventów, żeby drugi wariant nigdy nie powstał.

Garbage in → AI out

Tu wraca szczyt piramidy. Model AI — czy to predykcja, czy LLM — nie naprawia złych danych. On je wzmacnia. Karmiony niespójną taksonomią, brakami i duplikatami, nie powie „te dane są popsute” — policzy na nich z pełnym przekonaniem i zwróci wynik, który wygląda wiarygodnie i jest błędny. To gorsze niż brak odpowiedzi, bo brzmi jak prawda.

Dlatego jakość danych a sztuczna inteligencja to nie dwa osobne tematy. Najlepszy model na rynku, postawiony na rozjechanym fundamencie, da Ci szybciej i ładniej te same śmieci, które miałeś na wejściu. „Dane gotowe na AI” nie zaczynają się od modelu — zaczynają się od dataLayer.

Architektura danych pod AI: co zrobić, zanim zamarzysz o modelu

Kolejność jest odwrotna do intuicji biznesowej:

• Najpierw tracking plan i event schema — jeden uzgodniony słownik zdarzeń i parametrów, zanim cokolwiek wdrożysz w narzędziu.
• Potem jakość i własność — kto odpowiada za spójność, jak ją pilnujecie, jak wyłapujecie regresje.
• Dopiero na końcu raporty, BI i AI — bo teraz mają na czym stać.

To najmniej efektowna inwestycja na slajdzie i najwyższy zwrot w praktyce. Jak to wygląda przy realnej skali, opisałem w case study o analityce w skali. Bo architektura danych pod AI nie zaczyna się przy modelu — zaczyna się na samym dole piramidy. AI będzie tak dobre, jak dane u podstawy, długo zanim ktokolwiek wpisze pierwszy prompt.

Gdy fundament jest gotowy, kolejny krok to podłączenie agenta bezpośrednio do BigQuery i dbt — jak to zrobić przez MCP opisuję w Google MCP Toolbox i Data Agent Kit.