Dlaczego dane z różnych systemów się nie zgadzają
Rozbieżności między raportami mają zwykle trzy źródła, i tylko jedno z nich jest problemem technicznym.
Różne definicje tej samej metryki. GA4 liczy transakcję w momencie wywołania zdarzenia zakupu na stronie potwierdzenia zamówienia. System sklepowy liczy zamówienie w momencie jego złożenia, niezależnie od tego, czy zostało opłacone. Dział finansowy liczy sprzedaż po odjęciu zwrotów i anulowań. Wszystkie trzy liczby są poprawne w swoim kontekście i wszystkie trzy się różnią.
Różne okna czasowe i strefy czasowe. Platforma reklamowa raportuje w swojej strefie czasowej, system sklepowy w lokalnej. Przy raportowaniu dziennym daje to systematyczne przesunięcie części transakcji na sąsiedni dzień.
Braki w danych. Blokowanie skryptów śledzących, brak zgody na cookies, błędy implementacji tagów. Część transakcji zarejestrowanych w sklepie nigdy nie trafia do GA4.
Model danych nie usuwa tych rozbieżności. Sprawia, że są znane, udokumentowane i przewidywalne, dzięki czemu przestają być powodem sporu o to, która liczba jest prawdziwa.
Fundament: wybór kluczy łączących
Dane z różnych systemów łączy się na wspólnych identyfikatorach. Bez nich każde źródło pozostaje osobną wyspą.
Identyfikator transakcji (transaction_id). Najważniejszy klucz w e-commerce. Ta sama wartość musi być przekazywana do GA4, do konwersji w panelach reklamowych i występować w systemie sklepowym. Dopiero wtedy da się połączyć dane o koszcie kampanii z danymi o marży na konkretnym zamówieniu.
Identyfikator klienta (customer_id lub user_id). Pozwala połączyć zamówienia tego samego klienta w czasie, co jest warunkiem liczenia wartości życiowej klienta i analizowania powtarzalności zakupów w podziale na kanał pozyskania.
Identyfikator kampanii. Powstaje z ujednoliconej struktury parametrów UTM lub odpowiadających im pól w panelach reklamowych.
Konwencja nazewnictwa UTM jako warunek połączenia danych
To najczęstszy punkt, w którym model danych rozpada się w praktyce. Jeśli różne osoby oznaczają kampanie według własnych przyzwyczajeń, po roku w raportach pojawiają się dziesiątki wariantów tego samego źródła, których żaden system nie połączy automatycznie.
Konwencja powinna określać co najmniej:
- utm_source: nazwa platformy, zawsze małymi literami, zawsze tak samo (facebook, nie Facebook, FB czy fb-ads).
- utm_medium: typ ruchu według stałej, zamkniętej listy wartości (cpc, email, social, affiliate), bez tworzenia nowych wariantów ad hoc.
- utm_campaign: nazwa kampanii według ustalonego wzorca, na przykład kraj_kategoria_typ_okres.
- utm_content i utm_term: wykorzystywane konsekwentnie do rozróżnienia kreacji lub grup słów kluczowych, nie jako pole na dowolne notatki.
Warstwy modelu danych
Dojrzały model danych zwykle rozdziela dane na warstwy o rosnącym stopniu przetworzenia:
- Warstwa surowa (raw). Dane pobrane ze źródeł bez modyfikacji, w oryginalnej strukturze. Pozostają nietknięte, żeby w razie zmiany logiki przetwarzania nie trzeba było pobierać historii od nowa.
- Warstwa oczyszczona (staging). Dane ujednolicone pod względem nazewnictwa kolumn, formatów dat, walut i typów danych, wciąż jednak w podziale na źródła.
- Warstwa analityczna (mart). Gotowe tabele odpowiadające konkretnym potrzebom analitycznym, na przykład tabela łącząca wydatki kampanii z przychodem i marżą na poziomie dnia i kanału. To z niej korzystają dashboardy.
Rozdzielenie warstw ma praktyczne znaczenie: zmiana definicji metryki wymaga wtedy poprawki w jednym miejscu w warstwie analitycznej, a nie w każdym dashboardzie osobno.
Słownik metryk jako część modelu
Model danych obejmuje nie tylko strukturę techniczną, ale też jednoznaczne definicje metryk. Dla każdej kluczowej metryki warto zapisać:
- co dokładnie liczy (na przykład: przychód brutto z zamówień opłaconych, bez kosztów wysyłki, po odjęciu zwrotów zarejestrowanych w tym samym okresie),
- z jakiego źródła pochodzi,
- w jakim oknie czasowym jest raportowana,
- jakie są znane ograniczenia i typowe rozbieżności wobec innych źródeł.
Bez takiego słownika każda rozmowa o wynikach zaczyna się od ustalania, o czym właściwie mówimy.
Typowe błędy przy budowie modelu danych
| Błąd | Skutek | Jak temu zapobiec |
|---|---|---|
| Brak wspólnego identyfikatora transakcji | Nie da się połączyć kosztu kampanii z marżą na zamówieniu | Wymuszenie przekazywania transaction_id we wszystkich integracjach |
| Dowolność w oznaczaniu UTM | Rozsypanie kampanii na dziesiątki nieporównywalnych wariantów | Zamknięte listy wyboru w generatorze linków |
| Transformacja danych bezpośrednio przy pobieraniu, bez zachowania surowych | Zmiana logiki wymaga ponownego pobrania całej historii | Zachowanie warstwy surowej |
| Definicje metryk tylko w głowach zespołu | Każdy raport liczy inaczej, brak porównywalności | Spisany słownik metryk |
| Model budowany pod jeden konkretny raport | Każde nowe pytanie biznesowe wymaga przebudowy | Projektowanie warstwy analitycznej pod obszary, nie pod pojedyncze widoki |
Od czego zacząć budowę modelu danych
- Wypisz wszystkie systemy, w których powstają dane istotne dla decyzji marketingowych i sprzedażowych.
- Dla każdego z nich ustal, jaki identyfikator może posłużyć jako klucz łączący z pozostałymi.
- Zdefiniuj i spisz konwencję nazewnictwa UTM, zanim uruchomisz kolejne kampanie.
- Ustal listę kluczowych metryk i zapisz dla każdej jednoznaczną definicję.
- Dopiero wtedy przechodź do wyboru narzędzi i technicznej integracji, bo narzędzie nie naprawi braku ustaleń.
Najczęstsze pytania
Czy model danych wymaga hurtowni danych?
Model danych to warstwa koncepcyjna, którą można stosować także przy prostszych rozwiązaniach. Hurtownia ułatwia jego wdrożenie technicznie, ale ustalenia dotyczące kluczy, nazewnictwa i definicji metryk mają sens niezależnie od narzędzia.
Co zrobić z historycznymi danymi oznaczonymi niekonsekwentnie?
Zwykle stosuje się tabelę mapującą stare warianty nazw na nowe, ujednolicone wartości, żeby dane historyczne pozostały porównywalne z bieżącymi.
Kto powinien odpowiadać za model danych w organizacji?
Najczęściej jest to wspólna odpowiedzialność zespołu marketingowego, który definiuje potrzeby analityczne, i osoby technicznej odpowiedzialnej za implementację. Kluczowe jest wskazanie jednego właściciela konwencji nazewnictwa.
Sprawdź, ile różnych wariantów nazwy tej samej kampanii znajdziesz w danych z ostatniego roku, zanim uznasz, że model danych to problem wyłącznie techniczny.
Gotowi zobaczyć swoje liczby?
15-minutowe demo na Twoich danych, bez zobowiązań.
