Migracja z UA do GA4 — problemy i obejścia w 2026

16 kwietnia, 2026

Migracja z Universal Analytics do GA4 formalnie skończyła się 1 lipca 2024, gdy Google zamknął dostęp do UA także dla właścicieli nieruchomości 360. W 2026 rozmawiamy już nie o „jak przejść na GA4″, lecz o „jak naprawić migrację, którą zrobiono w pośpiechu”. To najczęstsze zlecenie audytowe ostatnich 18 miesięcy – właściciele sklepów i marek zauważają, że liczby w GA4 nie zgadzają się z UA, że historyczne raporty znikły, a zespół nie rozumie nowego modelu.

W tym tekście pokazuję konkretne problemy, które widzieliśmy w audytach migracji od 2023: dryf w raportach, podwójne liczenie, utrata danych historycznych, błędne mapowanie konwersji, niespójna atrybucja. Dla każdego z nich – sposób wykrycia i obejście, które da się wdrożyć teraz, bez cofania do UA (który i tak już nie działa).

Artykuł należy do klastra analityka marketingowa 2026. Jeśli migrację jeszcze planujesz (zdarza się – np. dla nowych klientów agencji, którzy mieli UA off-the-shelf), zacznij od GA4 zaawansowanego. Model zdarzeń omawiamy w zdarzeniach GA4, a kontener GTM w GTM od zera do produkcji.

W skrócie

  • UA zamknięty 1 lipca 2024 (oraz 2025 dla GA4 360 kontraktów). Historyczne dane UA są niedostępne w panelu – można je tylko ratować eksportem CSV/BigQuery zrobionym przed zamknięciem.
  • Typowe odchylenie liczb UA ↔ GA4: 15-40%, zależnie od domain set, consent mode i modelu zdarzeń. Powyżej 50% – błąd wdrożenia, nie „naturalna różnica”.
  • Najczęstszy bug migracji: podwójne liczenie page_view (tag GA4 w GTM + hardcoded gtag.js w theme WordPressa).
  • Konwersje z UA nie migrują automatycznie — trzeba ręcznie zaznaczyć mark as key event w GA4 dla każdej.
  • Okres, w którym sensownie porównasz rok do roku, to dopiero 2025 vs 2026. Wcześniejsze zestawienia są zawodne przez różnice metodologii UA/GA4.

Spis treści

  1. Stan migracji w 2026
  2. Dlaczego GA4 pokazuje inne liczby niż UA
  3. Podwójne liczenie: najczęstszy błąd
  4. Konwersje i cele – nowy model key events
  5. Ratunek dla danych historycznych UA
  6. Atrybucja: last-click UA vs DDA GA4
  7. Consent Mode i różnice liczb po odmowie zgody
  8. Checklist audytu migracji
  9. FAQ – najczęstsze pytania
  10. Co dalej

Stan migracji w 2026

Na wiosnę 2026 standardowe dane UA są całkowicie niedostępne. Nieaktywne nieruchomości UA trafiły w archiwum, a od 1 lipca 2024 panel analytics.google.com nie pokazuje już zakładek dla UA. Jedyne, co zostało: eksport CSV i eksport do BigQuery, jeśli zespół zrobił to przed zamknięciem. Jeżeli nie zrobił – historia UA jest bezpowrotnie stracona. Temat ten rozwijamy w GA4 zaawansowany.

Trzy scenariusze, w których firmy są w 2026

  1. Migracja skończona na czas, jakość zadbana. ~25% firm. GA4 działa od 18+ miesięcy, dane spójne, konwersje zmigrowane, zespół zna nowy panel. Audyt dotyczy zwykle optymalizacji, nie naprawy.
  2. Migracja „byle szybko”, bez jakości. ~55% firm. GA4 działa, ale zespół nie ufa liczbom. Konwersje liczą się inaczej niż w Google Ads. Kampanie ocenia się po uczuciach, nie po danych.
  3. Migracja dramatyczna, dużo strat. ~20% firm. Dane historyczne UA nie zostały zachowane. GA4 konfiguruje się dopiero teraz, w pośpiechu i bez strategii. Audyt YoY jest niemożliwy, bo punkt odniesienia nie istnieje.

Ten tekst jest dla dwóch ostatnich grup. Scenariusze 2 i 3 mają wspólny problem: decyzje marketingowe są podejmowane na danych, których zespół nie rozumie. To ryzyko budżetowe większe niż pojedyncza kampania – mówimy o 6-12 miesiącach błędnych optymalizacji.

Dlaczego GA4 pokazuje inne liczby niż UA

Między UA a GA4 jest co najmniej sześć metodologicznych różnic, z których każda zmienia raportowane liczby. Sumarycznie dają 15-40% odchylenia, nawet przy idealnie wdrożonym GA4. Szczegóły opisujemy w zdarzenia GA4.

Tabela porównawcza

AspektUniversal AnalyticsGA4
Model pomiaruSesje i pageviewsZdarzenia (każda akcja to event)
Session timeout30 min (konfigurowalne)30 min (konfigurowalne)
Definicja użytkownikaclient_id (cookie)device + user_id + modelowanie
Bounce rateSesja z 1 pageview bez eventuNie ma; zamiast zaangażowanie rate
Atrybucja domyślnaLast non-direct clickData-Driven Attribution
SamplingPowyżej 500k sesji w zapytaniu ad-hocTylko Explorations (10M events)
ThresholdingBrakAktywny dla demografii i Google Signals
Consent modelingBrakAdvanced CM v2 modeluje odmówione zdarzenia
Retention UI26 mies. default2 mies. default (14 po zmianie)

Najważniejsze metodologiczne „ale”

  • Users: UA liczyło unikalne client_id. GA4 próbuje stich deviceów i rozróżnia „active users” od „total users” – default w raportach to active, UA default to total. Różnica: 5-15%.
  • Sessions: W UA nowa sesja zaczynała się też przy zmianie kampanii (nawet w trakcie). W GA4 – nie, jeśli nie przekracza timeoutu. Kampania zmienia się w atrybucji, ale sesja pozostaje. Różnica: 3-8%.
  • Bounce rate vs engaged sessions: UA bounce = 1 pv + no event. GA4 engaged session = >10s LUB 2+ pv LUB event konwersji. Ta sama sesja może być „bounce” w UA i „engaged” w GA4.
  • Konwersje: UA zwykle liczyło cele per sesję (1 sesja max 1 konwersja na cel). GA4 liczy key events per event – jedna sesja może mieć 3x purchase i zobaczysz 3 konwersje. Dla e-commerce to zazwyczaj wzrost raportowanych konwersji o 5-15%.

Jak zredukować dryf podczas audytu

Jeżeli porównujesz UA vs GA4 w okresie nakładania się (1 stycznia 2023 – 30 czerwca 2024), ustaw:

  1. W UA: eksport do CSV raportu Acquisition → All Traffic → Source/Medium za konkretne dni.
  2. W GA4: raport User acquisition → Session source/medium, ten sam zakres, ten sam cel konwersji.
  3. Porównuj trendy, nie wartości bezwzględne. Jeżeli oba pokazują wzrost organic o 30% MoM, to dobra wiadomość — nawet jeśli liczby bezwzględne się różnią.

Podwójne liczenie: najczęstszy błąd migracji

W 70% audytów migracji trafiamy na podwójny page_view. Przyczyny:

  1. Gtag.js zahardcodowany w theme WordPressa (z czasów UA, gdy wtyczka Monster Wnioski albo szablon osadzał skrypt) + drugi tag GA4 przez GTM.
  2. Dwa GTM kontenery – np. jeden dla Ads, jeden dla Analytics, oba wysyłają page_view.
  3. SPA router bez zdjęcia default page_view: GA4 wysyła page_view przy załadowaniu, JS router wysyła drugi przy routingu, mimo że user nie zmienił strony.
  4. Test/staging GA4 podłączony do tej samej domeny w produkcji.

Jak wykryć duplikaty

Najłatwiej — w BigQuery:

SELECT
  DATE(TIMESTAMP_MICROS(event_timestamp)) AS day,
  user_pseudo_id,
  (SELECT value.int_value FROM UNNEST(event_params)
    WHERE key = 'ga_session_id') AS session_id,
  COUNT(*) AS pageviews_in_session
FROM `project.analytics_123.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260201' AND '20260207'
  AND event_name = 'page_view'
GROUP BY day, user_pseudo_id, session_id
HAVING pageviews_in_session > 30
ORDER BY pageviews_in_session DESC
LIMIT 100;

Wiersze, w których jedna sesja ma 50+ page_view, to sesje boty. Ale jeżeli mediana pageviews/sesja przekracza 8-12 (normalne dla większości branż), masz duplikację.

Alternatywna diagnostyka – GTM Preview

  1. Otwórz Tag Assistant (gtmpreview.google.com).
  2. Uruchom Preview dla swojego kontenera, odwiedź stronę docelową.
  3. Sprawdź zakładkę Events – ile razy pojawia się page_view przy jednym wejściu?
  4. Jeżeli 2+ – przejdź do Tags i sprawdź, które tagi GA4 się odpaliły. Jeden tag = OK, dwa = problem.

Naprawa

W zależności od źródła:

  • Gtag w theme: wyłącz w functions.php lub w wtyczce (np. Monster Wnioski → Settings → Disable śledzenie).
  • Dwa GTM: połącz w jeden kontener. Workspaces pozwolą na osobne zarządzanie działami, ale bez duplikacji eventów.
  • SPA: wyłącz automatically track page changes w konfiguracji tagu GA4 (Fields to Set → send_page_view: false) i wysyłaj ręcznie przez dataLayer.push przy routingu.

Po naprawie dane nie cofną się – historyczne duplikaty zostaną. Dokumentuj w changelog GA4 (komentarz w Admin → Property Settings), żeby analityk za 6 miesięcy nie liczył trendów przez moment naprawy. Zagadnienie to omawiamy szerzej w GTM od zera do produkcji.

Konwersje i cele — nowy model key events

W UA konwersje to były Goals: 20 goali per view, definiowane w Admin → View Settings. Każdy goal miał typ: destination URL, duration, pages/session, event. W GA4 to wszystko jest key events (wcześniej „konwersje”, przemianowano w 2024): dowolny event można zaznaczyć jako key. Praktyczne wskazówki znajdziesz w analityka marketingowa 2026.

Różnica praktyczna

UA GoalsGA4 Key Events
Max 20 per viewMax 30 per property
1 goal / sesja / celKażde zdarzenie liczy się osobno
Destination URL jako patternZdarzenie z parametrem (np. page_view + page_path matches)
Automatyczny import do AdsRęczny import po oznaczeniu jako key event
Cele działały wstecz dla istniejących danychOznaczenie jako key event dotyczy tylko przyszłych zdarzeń

Typowe błędy mapowania

  1. Destination URL goal UA → GA4 bez dedykowanego eventu. Np. UA goal „Thank-you page” dla /dziekujemy. W GA4 rozwiązanie: stwórz custom event lead_thank_you w Admin → Events → Create event z warunkiem event_name = page_view AND page_location contains /dziekujemy. Oznacz jako key event.
  2. Event goal UA z wartością → GA4 bez value. UA automatycznie łączył cel z wartością. W GA4 musisz dodać parametr value do eventu (może być dynamic lub stała). Bez niego w raportach ROAS nie policzy się dla tego eventu.
  3. Lejek goal UA → nie ma odpowiednika w GA4. W UA mogłeś zdefiniować lejek dla goalu (/strona-a → /strona-b → /konwersja). W GA4 lejek analizujesz w Explorations; nie jest elementem definicji key eventu.

Checklist migracji konwersji

  • Wyciągnij listę UA Goals (zrzut ekranu lub Measurement Protocol eksport).
  • Dla każdego zmapuj do GA4 eventu (istniejącego lub nowego custom event).
  • Oznacz jako key event (Admin → Events → toggle „Mark as key event”).
  • Jeśli wartość – dodaj parametr value; jeśli waluta – currency.
  • Google Ads: Tools → Konwersje → ponownie podłącz konwersje z nowego GA4 properta.
  • Po 48 godzinach porównaj liczby w GA4 vs Google Ads. Różnica > 15% — sprawdź, czy gclid dochodzi poprawnie.

Ratunek dla danych historycznych UA

Od lipca 2024 UA pokazuje pustą zakładkę. Jeśli w tym okresie (1 lipca 2023 – 30 czerwca 2024) zrobiłeś przynajmniej jedną z poniższych akcji – masz szansę:

  1. Eksport do BigQuery. UA 360 miał natywny eksport. Standard UA mógł eksportować przez skrypty Google Apps Script. Jeśli masz tabele ga_sessions_* w BQ – historia jest dostępna.
  2. Eksport CSV raportów. Każdy raport UA dało się eksportować ręcznie. Mądry zespół zrobił to dla kluczowych raportów (YoY) w czerwcu 2024.
  3. Reporting API v3. Ktoś w zespole mógł napisać skrypt Python lub Node, który co miesiąc zapisywał raporty do CSV/JSON. Te dane nadal tam są.
  4. Google Ads historical konwersje. Konwersje importowane z UA do Google Ads nadal są tam widoczne – agregowane per kampania.

Jeżeli żadnej z tych akcji nie było

Niewiele da się zrobić. Opcje:

  • Bazuj na Google Ads historical performance — pokaże trendy kampanijne, choć bez granularności per strona/produkt.
  • W Search Console wyciągnij dane do 16 miesięcy wstecz (zagregowane). Pozwoli to odtworzyć ruch organic na poziomie zapytań/stron.
  • Akceptuj, że YoY za pierwszy rok GA4 będzie trudny. Plan: zacznij zbieranie solidnych danych GA4+BQ od teraz, za 12 miesięcy miej czysty baseline.

Alternatywa: BigQuery UA ↔ GA4 unified view

Jeżeli masz obie tabele (UA export + GA4 export), możesz zbudować w BQ widok unifikujący format. Nie odtworzy pełnej metodologii, ale pozwoli na porównania na poziomie agregowanych KPI:

CREATE VIEW mart.sessions_unified AS
SELECT
  'UA' AS source,
  date, visitId AS session_id, fullVisitorId AS user_id,
  totals.pageviews AS pageviews,
  totals.transactionRevenue / 1e6 AS revenue,
  trafficSource.source AS source_name,
  trafficSource.medium AS medium
FROM `project.ua_export.ga_sessions_*`
UNION ALL
SELECT
  'GA4', event_date,
  CAST((SELECT value.int_value FROM UNNEST(event_params)
    WHERE key = 'ga_session_id') AS STRING),
  user_pseudo_id,
  COUNTIF(event_name = 'page_view') AS pageviews,
  SUM(IF(event_name = 'purchase',
    (SELECT value.double_value FROM UNNEST(event_params)
      WHERE key = 'value'), 0)) AS revenue,
  collected_traffic_source.manual_source,
  collected_traffic_source.manual_medium
FROM `project.analytics_123.events_*`
GROUP BY event_date, session_id, user_pseudo_id,
  collected_traffic_source.manual_source, collected_traffic_source.manual_medium;

Ograniczenia: UA sesji to nie to samo, co GA4 sesji; pageviews w UA vs w GA4 liczą się inaczej; przychód w UA było w mikrojednostkach. Traktuj to jako szacunek trendowy, nie absolutny.

Atrybucja: last-click UA vs DDA GA4

W UA domyślnym modelem atrybucji w raporcie acquisition był last non-direct click. W GA4 domyślnie masz Data-Driven Attribution (DDA). Zmiana jest wbudowana — GA4 nie oferuje last-click jako default, trzeba go włączyć.

Co się zmienia w liczbach

  • Kanały „zamykające” (paid search brand, direct) stracą udział w konwersjach — DDA rozdziela je po wielu touchpointach.
  • Kanały „otwierające” (organic, referral, display) zyskają – DDA przyznaje im fragment konwersji.
  • Różnica bywa znaczna: kanał, który w UA miał 40% konwersji (last-click), w GA4 DDA może mieć 25-30%.

Praktyczna rada

Jeżeli zespół decyzyjny (CMO, CFO) porównuje „to było 40% konwersji w UA, teraz tylko 25% w GA4″, pokaż obie wersje. W GA4 w Admin → Attribution Settings możesz zmienić reporting model na Last click i wtedy liczby zbliżą się do UA. Ale pamiętaj: DDA jest dokładniejszy, bo uwzględnia wszystkie touchpointy. Lepszą strategią jest edukacja zespołu niż powrót do last-click.

Jeżeli operujesz budżetami > 500 tys. PLN/rok, warto rozważyć Marketing Mix Modeling – omawiamy go w pillarze analityki marketingowej 2026. MMM uwzględnia kanały offline, których nie ma ani UA ani GA4.

UA nie miał natywnego consent mode. GA4 od marca 2024 musi mieć Consent Mode v2 (w EOG). Różnica praktyczna: UA widział dane tylko tych użytkowników, którzy zaakceptowali cookies. GA4 Consent Mode v2 (w wariancie advanced) modeluje także tych, którzy odmówili.

Oczekiwana różnica

  • W basic mode różnica GA4 vs UA po migracji jest mała – GA4 widzi mniej więcej te same dane, co UA widziało (tylko zgodzeni).
  • W advanced mode GA4 pokazuje więcej konwersji niż UA – modelowanie dodaje zwykle 15-30% do raportów key events.

Jeśli w panelu GA4 konwersje są wyraźnie wyższe niż w UA w tym samym okresie, nie panikuj – to prawdopodobnie CM v2 advanced robi swoje. Weryfikacja: w BigQuery rozróżnisz modelowane vs rzeczywiste przez flag w evencie – modelowane mają collected_traffic_source.manual_medium = 'cpc', ale brak user_pseudo_id.

Typowe problemy CM v2 przy migracji

  1. Brak wdrożenia CM v2. W EOG od marca 2024 obowiązkowy; jego brak oznacza, że Google Ads traci ~30% efektywności kampanii ze względu na brak modelowania.
  2. CM v2 w trybie basic zamiast advanced. Advanced pozwala na modelowanie konwersji. Basic – nie.
  3. Brak ad_user_data i ad_personalization sygnałów (wymagane od marca 2024). Bez nich modelowanie nie działa.

Więcej o CM v2 w materiale GA4 zaawansowanym i GTM od zera do produkcji.

Checklist audytu migracji po fakcie

Zbierane z 30+ audytów migracji UA → GA4 w latach 2024-2026. Dwanaście punktów, które w 8/10 projektów ujawniają problemy. Pełen obraz tematu znajdziesz w kompletnym przewodniku analityka marketingowa 2026.

  1. Page_view nie jest duplikowany. Mediana PV/sesja w normie (3-8 dla większości branż).
  2. Jeden GA4 property per domena. Brak test/staging podłączonego do produkcji.
  3. Konwersje zmapowane 1:1 z UA Goals. Każdy goal ma swoje key event w GA4.
  4. Key events są oznaczone i aktywne (nie wyłączone po migracji).
  5. Google Ads konwersja import zweryfikowany. Różnica liczb GA4 vs Ads < 15%.
  6. Consent Mode v2 advanced wdrożony. Sygnały ad_user_data i ad_personalization przekazywane.
  7. BigQuery link aktywny. Tabele events_YYYYMMDD pojawiają się codziennie.
  8. Retencja ustawiona na 14 miesięcy, nie 2 (default).
  9. Ecommerce śledzenie poprawny. purchase z value, currency i items[].
  10. Cross-domain śledzenie działa, jeśli masz sklep + checkout na subdomenie.
  11. User ID jest przekazywany dla zalogowanych (B2B SaaS, subskrypcja).
  12. Custom channel group z AI Assistants i AI Search (jeśli blog/content site).

Metryki sukcesu migracji

  • Różnica users GA4 vs UA (dla pokrywającego się okresu) < 15%.
  • Różnica sessions GA4 vs UA < 20%.
  • Różnica key events/konwersje GA4 vs UA < 30% (przy CM v2 basic) lub 0-20% wyżej w GA4 (przy CM v2 advanced).
  • Różnica GA4 vs Google Ads dla tego samego key eventu < 15%.

Powyżej tych progów — planuj audyt. Zwykle znajdziesz 2-5 konkretnych błędów (duplikacja, niezmapowane konwersje, brakujące sygnały CM v2), których naprawa zajmuje 1-2 dni pracy analityka.

Edukacja zespołu po migracji

Techniczna migracja to połowa sukcesu. Druga połowa to edukacja zespołu, który pracuje z raportami. Po audytach widzimy powtarzające się symptomy: CMO pyta „dlaczego mamy mniej organic niż w UA”, a odpowiedź brzmi „bo mierzymy engaged sessions”. Trzy moduły szkolenia, które warto przeprowadzić:

  • Model event-based. Jak GA4 liczy interakcje, czym różni się event od goalu, dlaczego session_id + user_pseudo_id to nowy fundament.
  • Data-Driven Attribution. Jak interpretować raporty, w których kanały „otwierające” mają inne wartości niż w UA last-click.
  • Consent Mode v2 i modelowanie. Dlaczego konwersje w GA4 mogą być wyższe niż faktyczne zebrane zdarzenia – i co to znaczy dla decyzji budżetowych.

Godzinna sesja z konkretnym raportem z Twojego properta daje więcej niż trzy dni czytania dokumentacji Google. Jeśli Twój zespół to 4-6 osób marketingu, zainwestuj 2h/osoba w pierwszym miesiącu po migracji – oszczędzi 10 godzin nieporozumień w kwartale.

Od audytu do stabilności

Audyt jednorazowy pokaże 80% problemów. Stabilne wdrożenie wymaga powtarzalnego procesu:

  1. Co miesiąc: weryfikacja duplikatów, audyt konwersji (GA4 vs Ads), sprawdzenie liczb DAU/MAU vs trendy oczekiwane.
  2. Co kwartał: audyt kompletności modelu (czy nowe features produktu mają śledzenie, czy nie pojawiły się nowe eventy, których nikt nie dokumentował).
  3. Co pół roku: re-audyt Consent Mode v2 i atrybucji — Google często zmienia zachowanie domyślne, warto być na bieżąco.
  4. Co rok: re-audyt całego stacku (GA4 + GTM + BigQuery + Looker Studio) pod kątem spójności danych i kosztów.

FAQ – najczęstsze pytania

Czy mogę jeszcze uzyskać dostęp do danych UA w 2026?

Nie bezpośrednio. Panel UA został wyłączony 1 lipca 2024 dla wszystkich kont standard i 1 lipca 2025 dla 360. Google potwierdził, że dane zostały usunięte z wewnętrznych systemów po okresie grace period. Jedyna szansa: (1) jeśli przed zamknięciem zrobiłeś eksport do BigQuery — dane są w BQ do dziś; (2) jeśli masz CSV/raporty wyeksportowane ręcznie; (3) jeśli pisałeś własny dashboard przez Reporting API v3 i zapisywałeś wyniki. Bez tego – danych UA w 2026 roku odzyskać się nie da.

Dlaczego mój GA4 pokazuje mniej sesji niż UA za ten sam okres?

Kilka możliwych przyczyn: (1) Consent Mode v2 w basic blokuje zdarzenia bez zgody — UA miał podobne ograniczenie, ale mogłeś przed CM v2 wdrożyć mniej rygorystyczną konfigurację; (2) thresholding w GA4 ukrywa sesje dla małych segmentów demograficznych; (3) definicja „engaged session” w GA4 wyklucza szybkie bounces z metryki „session”; (4) duplikacja sesji w UA, której GA4 już nie ma. Różnica do 20% jest normalna – powyżej skontroluj wdrożenie.

Czy warto trzymać stary goal UA jako referencja?

Nie – i tak już tego nie zrobisz (panel UA jest zamknięty). Strategia: zdokumentuj w arkuszu mapowanie UA Goal → GA4 Key Event z datami wdrożenia, opisami parametrów i oczekiwaną różnicą wolumenu. To dokument, który pozwala za 12 miesięcy zrozumieć, dlaczego dane wyglądają, jak wyglądają — ważniejszy niż sam goal.

Jak zrobić rok-do-roku, jeśli mam tylko częściowe dane UA?

Masz trzy opcje: (1) wyciągnij dane UA z Google Ads dla tych konwersji, które były importowane — to da YoY dla kampanii, choć bez granulacji per strona; (2) Search Console do 16 miesięcy wstecz – pokaże YoY dla ruchu organic z poziomu zapytań i stron; (3) akceptuj, że pierwszy rok po migracji YoY będzie ograniczony, a pełną zdolność YoY zyskasz dopiero w drugim roku po migracji (2026 vs 2025). Nie próbuj „magicznie” odtwarzać danych UA — to strata czasu i ryzyko błędnych decyzji na błędnych podstawach.

Czy GA4 kiedyś zostanie zamknięty, tak jak UA?

Google oficjalnie deklaruje, że GA4 jest platformą długoterminową. Realistycznie: następna wielka zmiana prawdopodobnie za 5-8 lat (analogia: UA powstał w 2012, zamknięty 2024, czyli 12 lat). Co zrobić, żeby nie powtórzyć chaosu migracji UA→GA4: (1) zawsze eksportuj do BigQuery – dane są Twoje, nie Google; (2) dokumentuj model pomiaru i nazewnictwo eventów w repo Git; (3) nie buduj dashboardów wyłącznie w panelu GA4 — Looker Studio i własne aplikacje łatwiej zmigrujesz do nowego źródła danych. Inwestycja w data stack „platform-agnostic” amortyzuje się przy każdej kolejnej migracji.

Czy Google Tag (gtag.js) jest w 2026 nadal potrzebny?

Tak, ale w większości przypadków używasz go przez GTM, nie bezpośrednio. Gtag.js to biblioteka, którą Google Tag Manager obsługuje pod spodem – wszystkie tagi GA4/Ads w GTM uruchamiają gtag.js. Bezpośrednie osadzanie gtag.js w kodzie strony w 2026 stosujemy rzadko – tylko w sytuacjach, gdy GTM nie jest dozwolony (strict CSP, PCI compliance) lub dla bardzo prostych stron, gdzie GTM to przesadny narzut. Standardem jest GTM + GTM szablon tagu GA4.

Co dalej

Migracja UA→GA4 technicznie się skończyła, ale audyty jej jakości będą trwać jeszcze 12-24 miesiące. Najważniejsze kroki, które możesz zrobić teraz:

Migracja nie jest jednorazowym projektem – to nowy sposób pracy z danymi. Zespoły, które traktują GA4 jako „takie samo UA tylko gorsze”, tracą 6-12 miesięcy na walkę z narzędziem. Zespoły, które uczą się nowego modelu event-based, BigQuery i atrybucji wieloetapowej, zyskują przewagę informacyjną nad konkurencją, która nadal próbuje odtworzyć zachowania UA. Sprawny audyt migracji jest pierwszym krokiem do tej drugiej grupy.