Wszyscy chcą automatyzować. Najpierw trzeba mieć co.
Teraz panuje moda na to, że przecież wszystko da się zautomatyzować. Owszem, da się — ale automat jest tak dobry, jak dane, które dostaje. A z danymi w e-commerce jest tak, że najgroźniejsze błędy nie świecą na czerwono. System pokazuje zielone światło, dane spływają — a mimo to bywają niekompletne albo nieprawdziwe, i nie dowiesz się o tym, dopóki ktoś tego nie sprawdzi: ręcznie albo odpowiednio zbudowaną, automatyczną procedurą kontrolną.
Dwa przykłady, żeby było namacalnie. Pierwszy — na wejściu, w momencie zbierania danych. Klient płaci przez zewnętrzną bramkę: PayU, Przelewy24, PayPal. Po opłaceniu nie wraca na stronę potwierdzenia albo wraca przez adres, na którym tag purchase nie strzela. Transakcja jest zrealizowana i opłacona — ale w analityce jej nie ma. Nic nie świeci na czerwono, bo z punktu widzenia systemu nic się nie stało. Po prostu realny przychód i ROAS kampanii są zaniżone, a nikt tego nie widzi.
Drugi — na wyjściu, gdy dane już spływają do raportów. Integracja, która ściąga dane z systemu reklamowego, działa bez zarzutu przez rok. Aż pewnego dnia platforma wycofuje starą wersję API — i połączenie zaczyna oddawać mniej danych. Nie zgłasza błędu, nie pokazuje ostrzeżenia. Raport dalej się generuje, bo pozostałe źródła działają normalnie — tyle że to jedno przestało zwracać komplet danych. A skoro w hurtowni brakuje części kosztów z jednego kanału, to suma kosztów i przychodów przestaje się zgadzać, i każdy wskaźnik policzony na jej podstawie — ROAS, marża, koszt pozyskania — jest po prostu nieprawdziwy. Dowiadujesz się o tym dopiero wtedy, gdy ktoś zauważy, że przychód z tego kanału „jakoś spadł". Zielone światło świeciło przez cały ten czas — bo raport działał. Tylko liczby w nim nie były prawdziwe.
To dwa różne błędy w dwóch różnych miejscach — ale łączy je jedno: interfejs pokazywał, że wszystko gra.
Używamy AI na co dzień w pracy z danymi. I właśnie dlatego znamy jego ograniczenie z pierwszej ręki. Jeśli po prostu każesz AI spojrzeć na dane i ocenić, czy są w porządku — zobaczy zielone światło i zwróci status „wszystko w porządku". Tyle że to „w porządku" nie zawsze jest prawdziwe, a decyzję podejmuje się wtedy na podstawie sygnału, którego tak naprawdę nie ma.
Powód jest strukturalny. Analityka e-commerce to dziesiątki niestandardowych połączeń, które nigdzie nie zostały porządnie udokumentowane: własne statusy zamówień, nietypowe integracje, wyjątki w logice płatności, lokalne specyfiki rynków. AI z natury wypełnia luki w dokumentacji najbardziej prawdopodobnym zgadywaniem — a w analityce „prawdopodobne" i „prawdziwe" to dwie różne rzeczy. Dlatego ryzyko halucynacji jest tu ogromne.
Nie znaczy to, że automatyzacja się nie sprawdza — znaczy tylko, że nie każda. Dobra automatyzacja tu nie polega na tym, że AI „patrzy i akceptuje". Polega na konkretnych, zaprojektowanych regułach kontrolnych, które sprawdzają dokładnie te miejsca, gdzie dane lubią się psuć — plus ręcznej weryfikacji tam, gdzie liczy się kontekst. Nie dlatego, że nie ufamy automatyzacji, tylko dlatego, że wiemy, gdzie się ona wykłada.
Dlatego na jakość danych warto patrzeć przez pryzmat dwóch miejsc: tego, jak dane trafiają do poszczególnych systemów, i tego, jak spływają z nich do jednej hurtowni. To dwa różne źródła błędów i dwa różne sposoby pracy. Ale jedno spina je od początku: najłatwiej cokolwiek zweryfikować, gdy dane ze wszystkich systemów leżą obok siebie w jednym miejscu.
Warstwa pierwsza decyduje, czy dane w ogóle są prawdziwe. Warstwa druga — czy pozostają spójne, gdy wszystko dookoła się zmienia.
Warstwa pierwsza — dane trafiające do systemów
Wszystko, co dzieje się zanim dane znajdą się w GA4, Meta Ads, systemie reklamowym czy CRM: strona, aplikacja, warstwa danych, tagi, eventy, Consent Mode, server-side. Najgroźniejsze błędy na tej warstwie mają jedną wspólną cechę — z poziomu interfejsu wszystko wygląda poprawnie.
Consent Mode, który tylko wygląda na poprawny
Użytkownik odrzuca zgody marketingowe — i przy okazji, przez błąd w konfiguracji, odrzucają się też analityczne. Komunikat o odrzuceniu wygląda prawidłowo. GA4 raportuje, że wszystko działa zgodnie z trybem zgód. A Ty po prostu masz mniej danych, niż powinieneś — systematycznie, na każdym kanale naraz, bez żadnego sygnału, że coś jest nie tak.
W EU to najczęściej największa pojedyncza, niewidoczna dziura w danych. Dlatego audyt sprawdza nie deklarację systemu, tylko realne requesty i parametry zgód (GCS, GCD, NPA) przed akceptacją, po odrzuceniu i po zgodzie.
Niezliczone zdarzenia purchase
Wracamy do przykładu z bramek płatniczych — bo to jedna z najczęstszych i najbardziej kosztownych dziur na tej warstwie. PayU, Przelewy24, PayPal, InPost Pay: klient płaci, ale nie wraca na stronę potwierdzenia, albo wraca przez adres, na którym tag purchase nie strzela. Transakcja jest zrealizowana i opłacona, ale w analityce jej nie ma.
Im więcej płatności przez zewnętrzne bramki i portfele, tym większa luka — i tym bardziej zaniżony realny przychód oraz ROAS każdej kampanii, która tę transakcję wygenerowała.
Bałagan w identyfikatorach i walucie
Każdy system zbiera dane po swojemu: item_id w warstwie danych nie zgadza się z ID w feedzie produktowym, transakcja przychodzi bez przekazanej wartości albo w złej walucie przy sprzedaży na kilku rynkach. Zdarzenie technicznie się policzyło, więc nic nie świeci na czerwono — ale dane nie matchują się między sobą, a ROAS liczony z takich wartości jest po prostu błędny.
Feed produktowy: niekompletny i bez sygnałów sterujących
Feed to nie tylko lista produktów — to dane, na których kampanie maszynowe Google i Meta podejmują decyzje za Ciebie. A feedy najczęściej mają dwa problemy naraz. Pierwszy to zwykłe błędy i braki: niespójne item_id, brakujące atrybuty, nieaktualne ceny i dostępność. Drugi, poważniejszy, to brak danych, które nadają kampaniom kierunek.
Custom labels zamieniają feed z biernej listy w narzędzie sterowania kampanią — niosąc to, czego algorytm sam nie wie: marżę, rotację, stan magazynu, status wyprzedaży.
User ID, który w ogóle nie jest wysyłany
Nie chodzi o subtelność typu „wysyłany tylko przy logowaniu". W praktyce często okazuje się, że user_id nie trafia do GA4 wcale — mimo że klient jest pewny, że jest wdrożony. Bez tego nie połączysz sesji jednego użytkownika między urządzeniami ani między stroną a aplikacją. Każda osoba rozsypuje się na kilku „nowych" użytkowników, a cała analiza retencji, cross-device i ścieżki zakupowej jest zbudowana na fikcji.
Skutek błędów na tej warstwie jest zawsze ten sam: dane są nieprawidłowe od źródła, a interfejs tego nie pokazuje. Wszystko dalej — raporty, optymalizacja kampanii, rekomendacje AI — dziedziczy ten błąd, nie mając jak go wykryć.
Dlatego audyt trackingu to nie odczyt z dashboardu — łączymy automatyczne testy z ręczną weryfikacją tam, gdzie liczy się kontekst. Przechodzimy całą ścieżkę od kliknięcia w reklamę do opłaconej transakcji i weryfikujemy: zdarzenia w warstwie danych (purchase, add_to_cart, begin_checkout), faktyczne zachowanie Consent Mode i CMP, integralność wartości i identyfikatorów, implementację User ID, kompletność i sygnały sterujące w feedzie oraz spójność między stroną a aplikacją. Wynik to dokument ze statusem każdego elementu i action plan dla IT. Automaty i AI robią pierwsze, szerokie przejście po danych; nietypowe połączenia, wyjątki i „zbyt ładne" wyniki potwierdzamy ręcznie — żeby żadna cicha dziura nie przeszła jako „OK".
Warstwa druga — utrzymanie danych w czasie
Tu zmienia się charakter problemu. Pierwszą warstwę można naprawić raz. Drugiej nie da się naprawić nigdy na stałe — bo dane marketingowe nie są stanem, tylko procesem, który zmienia się bez Twojej zgody.
I tu pojawia się pokusa, żeby po prostu zbudować własną hurtownię i mieć spokój. Problem w tym, że najtrudniejsza nie jest budowa — tylko utrzymanie.
Świeże dane są zawsze niekompletne
Konwersje przypisują się do daty kliknięcia, ale spływają przez kolejne dni i tygodnie, a część dochodzi jako modelowane. Dlatego wczorajszy i zeszłotygodniowy wynik zawsze wygląda gorzej, niż jest — i sam się „poprawi" w kolejnych dniach. To nie błąd, to dojrzewanie danych. Ale jeśli ktoś czyta świeży okres jako finalny, tnie budżet tam, gdzie kampania faktycznie działa.
Czytasz świeży tydzień jako wynik finalny — i tniesz budżet tam, gdzie kampania faktycznie działa. Reszta konwersji jest jeszcze w drodze.
Integracje psują się po cichu
To był drugi przykład ze wstępu — i wraca tu nie bez powodu, bo to jeden z najbardziej podstępnych błędów tej warstwy. API platform są wersjonowane i deprecjonowane. Integracja, która działała rok, potrafi przestać zwracać część danych bez żadnego błędu — po prostu zaczyna oddawać mniej. Tracking może być przy tym idealny: zdarzenia zbierane bez zarzutu, a hurtownia i tak ma trzytygodniową dziurę, bo zerwał się transfer z jednego źródła. I wystarczy jedno takie źródło, żeby zafałszować każdy zagregowany wskaźnik liczony z tych danych.
Klucze i struktury się zmieniają, a raporty sypią się po cichu
To codzienna, najbardziej żmudna część pracy z danymi. Sklep zmienia format item_id po migracji — i nagle dane z CRM nie matchują się z feedem ani z GA4, bo łączą się po identyfikatorze, którego już nie ma. Ktoś przemianuje kampanię i psuje regułę mapowania na kanał, więc koszty lądują w „pozostałe". Platforma marketplace zmienia nazwy kolumn w eksporcie. Żadna z tych zmian nie zgłasza błędu — raport się generuje, liczby się pokazują, tylko są niespójne albo niepełne.
Ręcznie sklejona hurtownia trzyma się na jednej osobie
Najczęstsza alternatywa wygląda tak: ktoś napisał skrypty ściągające dane z Meta, Google Ads i CRM, dołożył parę ręcznych poprawek na nietypowe przypadki, połączył to w BigQuery i zbudował na tym raporty. Działa — dopóki działa.
Im więcej źródeł i ręcznych wyjątków, tym kruchsza całość. Hurtownia danych nie powinna być prywatnym dziełem jednego specjalisty, które przestaje działać, gdy on przestaje je pilnować.
Definicje się rozjeżdżają. Historia ma szwy.
Każdy system liczy inaczej: inne okno atrybucji, inna definicja konwersji, inna obsługa zgód, inna strefa czasowa. Dlatego GA4 i CRM z zasady pokażą różne liczby konwersji — i to jest normalne, tego się nie „naprawia". Problem zaczyna się gdzie indziej: gdy te liczby rozjeżdżają się bardziej, niż wynika z samych definicji, albo gdy różnica nagle zmienia się w czasie bez powodu. Wtedy to już nie jest naturalna rozbieżność metodologii, tylko sygnał, że coś się zepsuło. A zmiana platformy analitycznej czy migracja sklepu to osobny moment ryzyka — dane się urywają lub zmieniają metodologię, więc porównanie rok do roku staje się bezwartościowe, chyba że ktoś świadomie ujednolici dane wstecz.
Tu jest różnica między ręcznie sklejoną hurtownią a utrzymywaną platformą. To nie projekt, który się kończy — to praca operacyjna: monitorowanie kompletności źródeł, wykrywanie anomalii, aktualizacja konektorów po zmianach API i — przede wszystkim — ciągłe ujednolicanie danych do jednego spójnego modelu. WitCloud robi to automatycznie i niezależnie od tego, kto akurat pracuje w zespole: mapuje dane z każdego systemu na wspólną strukturę i pilnuje, żeby zmiana formatu item_id czy nazwy kampanii nie wysadziła raportowania. Gdy transfer się zrywa lub dane odstają od normy, pojawia się alert — zanim dziura zafałszuje decyzję. Dane zostają w Twoim projekcie Google Cloud i są Twoje, ale ich utrzymanie i spójność nie zależą już od pamięci jednej osoby.
Hurtownia nie czeka, aż dane będą idealne — pomaga je naprawić
Łatwo z tego wszystkiego wyciągnąć błędny wniosek: „najpierw muszę pół roku doprowadzić dane do porządku, a dopiero potem wdrożyć hurtownię". To nieprawda — i odwraca kolejność.
Dopóki dane siedzą w pięciu osobnych systemach, nikt nie widzi, jak się mają do siebie. Że GA4 i CRM pokażą inne liczby — to naturalne. Ale czy różnica mieści się w tym, co tłumaczą atrybucja i consent, czy jest już za duża i rośnie w czasie — tego nie ocenisz, gdy każdą liczbę oglądasz w innym panelu, w inny dzień. Widać to dopiero wtedy, gdy wszystkie stoją obok siebie.
Zlanie danych do jednej hurtowni to najszybszy sposób, żeby problemy w ogóle zobaczyć — luki w purchase, zerwane integracje, feed bez etykiet.
Dlatego u nas to działa równolegle, nie po kolei. Bardzo często to właśnie dane w WitCloud dają pierwszy sygnał, że coś jest nie tak — liczby, które nagle przestają się spinać, kanał, który zniknął, przychód, który nie zgadza się z CRM. Hurtownia pokazuje, że problem istnieje. Audyt mówi, skąd się bierze i jak go usunąć. Jedno napędza drugie.
Nie musisz mieć idealnych danych, żeby zacząć. Musisz je widzieć w jednym miejscu — bo dopiero wtedy wiadomo, co naprawić w pierwszej kolejności, a co może zaczekać.
A nad tym wszystkim AI ma wreszcie czego się trzymać: nie surowych, sprzecznych systemów, tylko jednego, pilnowanego źródła — które samo sygnalizuje, kiedy przestaje być wiarygodne.
Najpierw prawda, potem spokój
Jakość danych rozgrywa się na dwóch warstwach i wymaga dwóch różnych ruchów. Pierwsza — czy dane w ogóle są prawdziwe u źródła — to robota do wykonania raz: audyt, który wyłapuje niewidoczne dziury w trackingu i mówi wprost, co naprawić. Druga — czy dane pozostają spójne, gdy wszystko dookoła się zmienia — to robota ciągła, której nie da się „odhaczyć". Właśnie dlatego samodzielne zbudowanie hurtowni rzadko się broni: nie na budowie się potykasz, tylko na utrzymaniu. To robi za Ciebie WitCloud — trzyma jedno, pilnowane źródło w Twoim projekcie Google Cloud i sam sygnalizuje, kiedy coś przestaje się zgadzać.
Audyt naprawia dane u źródła. WitCloud pilnuje, żeby nie zepsuły się znowu. Nie potrzebujesz idealnych danych, żeby zacząć — potrzebujesz zobaczyć je w jednym miejscu i wiedzieć, którym liczbom możesz ufać.