GA4 vs Universal Analytics — co musisz wiedzieć jako analityk

Universal Analytics przestało zbierać dane w lipcu 2023, ale wciąż regularnie widzę ten sam problem: analitycy próbują czytać GA4 przez okulary UA i się dziwią, że liczby "nie zgadzają się" albo że coś, co kiedyś było oczywiste, teraz nie działa tak samo. Prawda jest taka, że GA4 to nie jest "UA z nowym interfejsem" — to zupełnie inny model danych, inna filozofia zbierania eventów i inna logika raportowania. Jeśli robisz audyt trackingu albo tłumaczysz stakeholderom, dlaczego liczba sesji spadła o 20%, musisz rozumieć te różnice u podstaw, a nie na poziomie UI.

Model danych: sesje kontra eventy

W UA wszystko kręciło się wokół sesji jako jednostki centralnej — pageview, event, transakcja, to wszystko były "hity" przypisane do konkretnej sesji z jasno zdefiniowanym początkiem i końcem (30 minut nieaktywności, północ, zmiana kampanii).

GA4 odwraca tę hierarchię: absolutnie wszystko jest eventem, łącznie z samą sesją. session_start to zwykły event z parametrem session_id, page_view to event, purchase to event. Sesje są w GA4 wyliczane wtórnie na podstawie tych eventów, nie są jednostką pierwotną.

To ma konkretne konsekwencje praktyczne:

• Bounce rate zniknął (a właściwie wrócił niedawno, ale liczony inaczej) — GA4 domyślnie mówi o "engagement rate" (sesje trwające >10s, z conversion eventem lub ≥2 page_view). To zupełnie inna definicja niż UA bounce rate, więc porównywanie tych dwóch liczb rok do roku nie ma sensu.
• Liczba sesji będzie inna dla tego samego ruchu, bo GA4 liczy nową sesję przy zmianie UTM w trakcie tej samej wizyty inaczej niż UA, i nie zamyka sesji o północy.

E-commerce tracking zmienił się od podstaw

To jest sekcja, gdzie widzę najwięcej błędów w audytach. UA miało Enhanced Ecommerce jako osobną warstwę (ecommerce.js / analytics.js plugin) z eventami typu add, detail, purchase wysyłanymi przez ec: parametry. GA4 ma to wbudowane jako standardowe, rekomendowane eventy z konkretną strukturą items[]:

// GA4 recommended ecommerce event przez GTM / gtag
gtag('event', 'add_to_cart', {
  currency: 'PLN',
  value: 149.99,
  items: [{
    item_id: 'SKU_12345',
    item_name: 'Sukienka midi',
    item_category: 'Sukienki',
    price: 149.99,
    quantity: 1
  }]
});

Najczęstsze problemy, które widzę w audytach GA4 e-commerce:

• brak currency w evencie purchase — GA4 wtedy w ogóle nie liczy przychodu do raportów
• zduplikowany transaction_id przy odświeżeniu strony potwierdzenia — GA4 sam nie deduplikuje tak agresywnie jak UA kiedyś
• niespójne item_id między view_item a purchase — psuje to raporty ścieżki zakupowej i attribution

Atrybucja i raportowanie: inny model domyślny

UA domyślnie liczyło konwersje modelem "last non-direct click". GA4 domyślnie używa data-driven attribution (DDA) — modelu opartego na uczeniu maszynowym, który rozkłada zasługę konwersji między wszystkie touchpointy w ścieżce, a nie tylko ostatni.

To oznacza, że te same dane surowe dadzą różne liczby konwersji per kanał w UA i w GA4 — i to nie jest błąd w trackingu, to różnica w modelu. Do tego domyślne channel groupings (Default Channel Group) różnią się między systemami — GA4 ma bardziej granularne kategorie (np. rozdziela "Paid Social" i "Organic Social" inaczej niż UA). Jeśli robisz raport porównawczy rok do roku przez migrację, koniecznie zaznacz to stakeholderom z wyprzedzeniem, inaczej dostaniesz pytania "dlaczego kanał X nagle ma o 30% mniej konwersji".

Dane historyczne: czego nie przeniesiesz

UA nie eksportowało się automatycznie donikąd — po deadline'ie dane w UI zniknęły (chyba że ktoś wcześniej zrobił eksport do BigQuery albo pobrał raporty ręcznie). GA4 ma wbudowaną integrację z BigQuery Export, ale trzeba ją włączyć świadomie:

• darmowy tier GA4 w UI ma retencję danych 2 lub 14 miesięcy (do ustawienia w Admin → Data Settings → Data Retention) — to nie jest to samo co "dane są przechowywane wiecznie"
• BigQuery Export, jeśli włączony, trzyma surowe dane eventów bezterminowo (w Twoim projekcie GCP, płacisz za storage/query)
• jeśli robisz projekt migracyjny i ktoś pyta "a możemy porównać do danych z UA sprzed 2 lat" — odpowiedź brzmi: tylko jeśli macie wcześniejszy eksport, bo UA data jest już nieodwracalnie niedostępna w UI

Praktyczna rekomendacja: jeśli configurujesz nowy projekt GA4 (albo audytujesz istniejący), pierwsza rzecz do sprawdzenia to czy BigQuery Export jest włączony i czy leci na streaming (nie tylko daily export) — potem można robić dowolne SQL-owe analizy bezpośrednio na surowych danych.

-- Szybki check w BigQuery: eventy purchase bez waluty (sygnał błędu trackingu)
SELECT
  event_date,
  COUNT(*) AS purchase_events,
  COUNTIF(
    (SELECT value.string_value FROM UNNEST(event_params)
     WHERE key = 'currency') IS NULL
  ) AS missing_currency
FROM `project.analytics_XXXXXXXXX.events_*`
WHERE event_name = 'purchase'
  AND _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'
GROUP BY event_date
ORDER BY event_date;

Praktyczna checklista audytu przy migracji lub weryfikacji GA4

• [ ] Sprawdź, czy wszystkie kluczowe eventy e-commerce (view_item, add_to_cart, begin_checkout, purchase) mają komplet parametrów, szczególnie currency i value
• [ ] Zweryfikuj item_id spójne na całej ścieżce zakupowej
• [ ] Ustaw retencję danych na maksimum (14 miesięcy) od razu przy starcie projektu
• [ ] Włącz BigQuery Export (streaming) zanim będzie potrzebny do analizy historycznej
• [ ] Zdefiniuj konwersje (Key Events) na nowo — nic nie przenosi się automatycznie z UA
• [ ] Odbuduj audiences do remarketingu w Google Ads — stare listy z UA nie migrują się same
• [ ] Uprzedź stakeholderów, że porównania rok-do-roku przez punkt migracji będą miały metodologiczny szum, nie tylko biznesowy

TL;DR

• GA4 to inny model danych niż UA — wszystko jest eventem, sesje są wtórne, nie pierwotne
• E-commerce tracking wymaga struktury items[] i pełnych parametrów (currency, value, spójny item_id) — brak currency w purchase cicho psuje raporty przychodu
• Domyślny model atrybucji to data-driven attribution, nie last non-direct click — liczby konwersji per kanał będą się różnić od UA nie przez błąd, tylko przez metodologię
• Dane historyczne z UA nie migrują się automatycznie — jeśli nie było wcześniejszego eksportu, są nieodwracalnie stracone w UI
• Włącz BigQuery Export od razu i traktuj go jako podstawowe źródło do głębszych analiz SQL, a nie tylko backup