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
- Stan migracji w 2026
- Dlaczego GA4 pokazuje inne liczby niż UA
- Podwójne liczenie: najczęstszy błąd
- Konwersje i cele – nowy model key events
- Ratunek dla danych historycznych UA
- Atrybucja: last-click UA vs DDA GA4
- Consent Mode i różnice liczb po odmowie zgody
- Checklist audytu migracji
- FAQ – najczęstsze pytania
- 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
- 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.
- 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.
- 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
| Aspekt | Universal Analytics | GA4 |
|---|---|---|
| Model pomiaru | Sesje i pageviews | Zdarzenia (każda akcja to event) |
| Session timeout | 30 min (konfigurowalne) | 30 min (konfigurowalne) |
| Definicja użytkownika | client_id (cookie) | device + user_id + modelowanie |
| Bounce rate | Sesja z 1 pageview bez eventu | Nie ma; zamiast zaangażowanie rate |
| Atrybucja domyślna | Last non-direct click | Data-Driven Attribution |
| Sampling | Powyżej 500k sesji w zapytaniu ad-hoc | Tylko Explorations (10M events) |
| Thresholding | Brak | Aktywny dla demografii i Google Signals |
| Consent modeling | Brak | Advanced CM v2 modeluje odmówione zdarzenia |
| Retention UI | 26 mies. default | 2 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
purchasei 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:
- W UA: eksport do CSV raportu Acquisition → All Traffic → Source/Medium za konkretne dni.
- W GA4: raport User acquisition → Session source/medium, ten sam zakres, ten sam cel konwersji.
- 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:
- Gtag.js zahardcodowany w theme WordPressa (z czasów UA, gdy wtyczka Monster Wnioski albo szablon osadzał skrypt) + drugi tag GA4 przez GTM.
- Dwa GTM kontenery – np. jeden dla Ads, jeden dla Analytics, oba wysyłają
page_view. - 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.
- 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
- Otwórz Tag Assistant (gtmpreview.google.com).
- Uruchom Preview dla swojego kontenera, odwiedź stronę docelową.
- Sprawdź zakładkę Events – ile razy pojawia się
page_viewprzy jednym wejściu? - 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 Goals | GA4 Key Events |
|---|---|
| Max 20 per view | Max 30 per property |
| 1 goal / sesja / cel | Każde zdarzenie liczy się osobno |
| Destination URL jako pattern | Zdarzenie z parametrem (np. page_view + page_path matches) |
| Automatyczny import do Ads | Ręczny import po oznaczeniu jako key event |
| Cele działały wstecz dla istniejących danych | Oznaczenie jako key event dotyczy tylko przyszłych zdarzeń |
Typowe błędy mapowania
- Destination URL goal UA → GA4 bez dedykowanego eventu. Np. UA goal „Thank-you page” dla
/dziekujemy. W GA4 rozwiązanie: stwórz custom eventlead_thank_youw Admin → Events → Create event z warunkiemevent_name = page_view AND page_location contains /dziekujemy. Oznacz jako key event. - Event goal UA z wartością → GA4 bez value. UA automatycznie łączył cel z wartością. W GA4 musisz dodać parametr
valuedo eventu (może być dynamic lub stała). Bez niego w raportach ROAS nie policzy się dla tego eventu. - 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
gcliddochodzi 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ę:
- 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. - 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.
- 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ą.
- 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.
Consent Mode i różnice liczb po odmowie zgody
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
- 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.
- CM v2 w trybie basic zamiast advanced. Advanced pozwala na modelowanie konwersji. Basic – nie.
- Brak
ad_user_dataiad_personalizationsygnałó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.
- Page_view nie jest duplikowany. Mediana PV/sesja w normie (3-8 dla większości branż).
- Jeden GA4 property per domena. Brak test/staging podłączonego do produkcji.
- Konwersje zmapowane 1:1 z UA Goals. Każdy goal ma swoje key event w GA4.
- Key events są oznaczone i aktywne (nie wyłączone po migracji).
- Google Ads konwersja import zweryfikowany. Różnica liczb GA4 vs Ads < 15%.
- Consent Mode v2 advanced wdrożony. Sygnały
ad_user_dataiad_personalizationprzekazywane. - BigQuery link aktywny. Tabele events_YYYYMMDD pojawiają się codziennie.
- Retencja ustawiona na 14 miesięcy, nie 2 (default).
- Ecommerce śledzenie poprawny.
purchasezvalue,currencyiitems[]. - Cross-domain śledzenie działa, jeśli masz sklep + checkout na subdomenie.
- User ID jest przekazywany dla zalogowanych (B2B SaaS, subskrypcja).
- 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:
- Co miesiąc: weryfikacja duplikatów, audyt konwersji (GA4 vs Ads), sprawdzenie liczb DAU/MAU vs trendy oczekiwane.
- Co kwartał: audyt kompletności modelu (czy nowe features produktu mają śledzenie, czy nie pojawiły się nowe eventy, których nikt nie dokumentował).
- Co pół roku: re-audyt Consent Mode v2 i atrybucji — Google często zmienia zachowanie domyślne, warto być na bieżąco.
- 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.