GA4 custom dimensions dla SEO 2026 — 15 wymiarów + framework GTM

TL;DR: Standardowe raporty GA4 pokazują, ile ruchu przyszło z wyszukiwarki — ale nie mówią, dlaczego jedne podstrony konwertują, a inne nie. W 2026 roku przewagę dają zespoły SEO, które wzbogacają GA4 o własne wymiary niestandardowe: typ treści, długość artykułu, autor, cluster tematyczny, obecność schema, źródło AIO, głębokość scrolla, czy formularz był przewijany w całości. Ten pillar pokazuje 15 najważniejszych custom dimensions dla SEO, gotowy framework konfiguracji w 7 krokach, dwa snippety dataLayer do wklejenia w GTM oraz listę najczęstszych błędów, przez które wymiary stają się bezużyteczne już po tygodniu. Jeśli masz więcej niż 200 indeksowanych URL-i i prowadzisz content marketing, custom dimensions są tym, co zamienia GA4 z dashboardu w narzędzie decyzyjne.

Dlaczego custom dimensions w GA4 są w 2026 ważniejsze niż kiedykolwiek?

GA4 z natury jest oparte na zdarzeniach i parametrach — ale parametry same z siebie nie pojawią się w raportach Exploration czy w Looker Studio. Musisz je zarejestrować jako custom dimension lub custom metric. W 2026 roku zmieniły się trzy rzeczy, które podniosły wagę tego kroku. Po pierwsze, AI Overviews i odpowiedzi generatywne w SERP zmniejszają liczbę kliknięć do witryny, więc każda sesja jest cenniejsza i wymaga głębszej analizy. Po drugie, Google od końca 2025 roku rozszerzyło limity custom dimensions w property Standard z 50 do 75, a w 360 z 125 do 200 — przestrzeń jest, trzeba ją tylko mądrze zagospodarować. Po trzecie, integracja GA4 z BigQuery jest teraz domyślna nawet dla darmowych kont, co oznacza, że każdy parametr zdarzenia trafia do hurtowni i można go analizować poza limitami interfejsu.

Dla SEO oznacza to jedno: jeśli nadal pracujesz na domyślnych raportach „Landing page + Source/Medium”, tracisz 70 procent insightów, które dałoby się wyciągnąć z tego samego ruchu. Custom dimensions pozwalają zobaczyć, że pillary z cluster „analityka” konwertują 3,2 razy lepiej niż pillary z cluster „narzędzia” — i że różnica nie wynika z jakości treści, tylko z długości artykułu. Takich wniosków nie zobaczysz w domyślnym raporcie Engagement.

Jakie custom dimensions warto dodać w pierwszej kolejności?

Najczęstszy błąd polega na tym, że zespół dodaje 40 wymiarów „na wszelki wypadek”, nigdy ich nie raportuje, a potem okazuje się, że 30 z nich zbiera dane z jedną literówką i trzeba zaczynać od zera. Lepsza strategia to zacząć od 12-15 wymiarów, które pokrywają trzy obszary: klasyfikacja treści, zachowanie użytkownika i kontekst SEO. W tabeli poniżej zebrałem te 15, od których zaczynałbym dziś każdy nowy projekt, wraz z zakresem (event vs user), typem danych i przykładową wartością. Zakres event oznacza, że wymiar jest przypięty do konkretnego zdarzenia i zmienia się z każdym trafieniem — to najczęstszy wybór dla SEO. Zakres user jest trwały i powinien być używany tylko wtedy, gdy naprawdę opisuje użytkownika (np. segment newslettera), nigdy dla atrybutów strony.

Nazwa wymiaru	Parametr eventu	Zakres	Do czego służy w SEO	Przykład wartości
Typ treści	content_type	Event	Porównanie performance pillar vs supporting vs listicle	pillar
Cluster tematyczny	topic_cluster	Event	Atrybucja ruchu do konkretnego hubu treści	analityka-ga4
Autor	author_slug	Event	Ocena, który autor przyciąga najwięcej zaangażowanych czytelników	kamil-nowak
Długość artykułu	word_count_bucket	Event	Czy długie treści rzeczywiście konwertują lepiej	3000-5000
Data publikacji	publish_year_month	Event	Wiek treści vs ruch organiczny	2026-02
Ostatnia aktualizacja	last_updated	Event	Czy refresh treści daje wzrost	2026-04-12
Obecność FAQ schema	has_faq_schema	Event	Test wpływu schema na CTR i dwell time	true
Typ schema	schema_type	Event	Porównanie Article vs HowTo vs Product	Article
Głębokość scrolla	scroll_depth	Event	Realne zaangażowanie zamiast Engagement Time	75
Źródło AIO	aio_referrer	Event	Czy ruch przyszedł z cytowania w AI Overview	google-aio
SERP feature	serp_feature	Event	Z jakiej featury SERP przyszedł klik	featured-snippet
Internal search query	site_search_query	Event	Czego szukają użytkownicy, gdy są już u Ciebie	ga4 custom dimensions
Sygnalizowany intent	search_intent	Event	Atrybucja intentu do konwersji	informational
Logged-in state	user_logged_in	User	Segmentacja ruchu SEO dla konwersji produktowej	false
Segment CRM	crm_segment	User	Łączenie ruchu organicznego z segmentami marketingowymi	mql-b2b

Jeśli prowadzisz integrację GA4 z Search Console, wymiary serp_feature i search_intent wypełnisz częściowo danymi z GSC, a częściowo z własnej klasyfikacji URL-i. To połączenie daje najciekawsze raporty — bo pokazuje, które intenty faktycznie konwertują, a nie tylko generują impresje.

Jak skonfigurować custom dimension krok po kroku? (framework 7 kroków)

Poniższy framework zakładam na nowej property GA4 z podstawowym eventem page_view oraz Google Tag Managerem jako warstwą przekazującą parametry. Jeśli używasz gtag.js bezpośrednio, kroki 3-4 wyglądają inaczej, ale reszta jest taka sama.

Zdefiniuj naming convention zanim wyślesz pierwszy event. Używaj snake_case, maksymalnie 40 znaków, bez polskich znaków i bez spacji. Trzymaj listę w jednym arkuszu Google Sheets i wersjonuj — „content_type” i „contentType” to dla GA4 dwa różne wymiary, a raport będzie dzielony na pół.
Wypchnij parametr do dataLayer na poziomie szablonu. W WordPressie najprościej wstrzyknąć to w head.php lub przez hook wp_head. Parametry przypisane statycznie (typ treści, cluster, autor) wypychaj przed kontenerem GTM, parametry dynamiczne (scroll, search) — przez triggery GTM.
Odbierz parametr w GTM. Stwórz zmienną typu „Data Layer Variable”, wskaż klucz z dataLayer i wersję 2. Dla zmiennych bool/number ustaw domyślną wartość fallback, np. „unknown”, żeby GA4 nie dostał pustego stringa, którego nie policzy.
Przekaż parametr do tagu GA4 Event. W konfiguracji tagu GA4 Configuration lub GA4 Event dodaj sekcję „Event Parameters”, wpisz dokładnie tę samą nazwę co w dataLayer i ustaw wartość na zmienną GTM. Parametry z GA4 Configuration są rozsyłane do wszystkich eventów w tej property — to najlepsze miejsce na atrybuty strony typu content_type, topic_cluster, author_slug.
Zarejestruj parametr jako custom dimension w GA4. Admin → Custom definitions → Custom dimensions → Create. Wpisz „Display name” (to widzi analityk), „Event parameter” (to odebrał GTM) i wybierz scope. UWAGA: po rejestracji wymiar będzie zbierał dane dopiero od tego momentu, dane historyczne nie zostaną uzupełnione.
Poczekaj 24-48 godzin i zwaliduj w DebugView oraz raporcie Exploration. W DebugView zobaczysz parametr na zdarzeniu od razu, w raportach standardowych dopiero po agregacji. Stwórz prostą eksplorację typu Free-form z custom dimension w wierszu i Views w kolumnie, żeby sprawdzić, czy na pewno nie masz kardynalności „unknown” = 99 procent.
Dopnij BigQuery export i Looker Studio. W BigQuery parametry zdarzeń trafiają do tabeli event_params jako struktura key/value — nie trzeba ich rejestrować jako custom dimension, żeby je tam odczytać. Ale w Looker Studio, który podpina się do GA4 Data API, custom dimension musi być zarejestrowany, inaczej nie pojawi się na liście pól.

Cały proces zajmuje jedno popołudnie dla pierwszych 5 wymiarów i kolejne 2-3 godziny na każdą dodatkową piątkę. Rozpisuj sobie kolejne batche w sprincie, nie rób 15 naraz — wrzucenie 15 parametrów jednym deployem w 80 procentach przypadków kończy się tym, że trzy z nich mają literówkę i nikt tego nie zauważy przez miesiąc.

Jak wypchnąć parametry do dataLayer? (GTM snippet)

Pierwszy snippet to statyczne atrybuty strony — wypychamy je raz, przed inicjalizacją GTM, z danych, które WordPress generuje po stronie serwera. W pliku header.php motywu albo w dedykowanym pluginie umieszczamy:

<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  content_type: 'pillar',
  topic_cluster: 'analityka-ga4',
  author_slug: 'kamil-nowak',
  word_count_bucket: '3000-5000',
  publish_year_month: '2026-04',
  last_updated: '2026-04-18',
  has_faq_schema: true,
  schema_type: 'Article',
  search_intent: 'informational'
});
</script>
<!-- Google Tag Manager container goes here -->

Wartości podstawiaj ze zmiennych PHP — w WordPressie użyj get_post_meta() dla pól własnych, get_the_author_meta(’user_nicename’) dla autora i prostej funkcji, która zlicza długość post_content i mapuje na bucket. Nie wypychaj surowego word count jako liczby, bo GA4 potraktuje go jako wymiar tekstowy i dostaniesz 8000 unikalnych wartości zamiast 5 bucketów.

Drugi snippet dotyczy zdarzeń dynamicznych — np. scroll depth i kliknięcia w link zewnętrzny. Najłatwiej wyzwolić je z GTM (Scroll Depth Trigger), ale można też pushować ręcznie:

<script>
(function () {
  var thresholds = [25, 50, 75, 100];
  var fired = {};
  window.addEventListener('scroll', function () {
    var pct = Math.round(
      (window.scrollY + window.innerHeight) /
      document.documentElement.scrollHeight * 100
    );
    thresholds.forEach(function (t) {
      if (pct >= t && !fired[t]) {
        fired[t] = true;
        window.dataLayer.push({
          event: 'scroll_milestone',
          scroll_depth: t
        });
      }
    });
  }, { passive: true });
})();
</script>

W GTM twórz Trigger „Custom Event” z nazwą scroll_milestone, a w tagu GA4 Event wyślij parametr scroll_depth — zarejestruj go później jako custom dimension. To daje znacznie lepszy obraz zaangażowania niż domyślny Engagement Time, który liczy tylko sekundy aktywnej karty.

Jak raportować custom dimensions w Exploration i Looker Studio?

Po 48 godzinach zbierania danych można tworzyć raporty. W GA4 Exploration zacznij od szablonu Free-form i wrzuć custom dimension jako wiersz, a Sessions / Engaged sessions / Conversions jako wartości. Filtrem ogranicz się do sesji z source = organic, bo inaczej zobaczysz też Direct i Social, które zaburzą obraz SEO. Druga eksploracja, którą warto zbudować od razu, to Path exploration z krokiem 1 = landing page i krokiem 2 = page_path — ale z podziałem na content_type. Wtedy widać, czy z pillar users faktycznie przechodzą na supporting, czy uciekają od razu na stronę główną.

W Looker Studio custom dimensions pojawiają się w sekcji „Available fields” pod nazwą Display name, którą ustawiłeś przy rejestracji. Można je wrzucić jako Breakdown dimension na dowolny wykres lub jako Filter control, żeby użytkownik raportu mógł przełączać się między clusterami. Najczęściej budowanym raportem jest matryca content_type × topic_cluster z metrykami Sessions, Engaged sessions rate i Conversions per session — to jedna strona A4, która zastępuje 10 różnych raportów ad hoc.

Jeśli potrzebujesz danych poza limitem kardynalności GA4 Data API (500 wartości na wymiar), przełącz się na BigQuery — tam w tabeli events_* masz dostęp do wszystkich parametrów bez rejestracji jako custom dimension i bez samplingu.

Jak łączyć custom dimensions z konwersjami (events) w GA4?

Sam pomiar atrybutów treści jeszcze niczego nie zmienia — wartość pojawia się wtedy, gdy podłączysz je pod konwersje. W GA4 każde zdarzenie oznaczone jako „Key event” (następca starego „Conversion” z 2024 roku) może być rozbite po custom dimension w raportach standardowych i Exploration. Kluczowe jest, żeby custom dimension był event-scoped i żeby parametr był wypychany razem z eventem konwersji, a nie tylko przy page_view. Jeśli konwersja leci na evencie form_submit, a parametr content_type był tylko w page_view, raport „form_submit by content_type” pokaże „(not set)” dla wszystkich konwersji.

Rozwiązanie: w GA4 Configuration tagu GTM ustaw parametry, które mają lecieć na każdym evencie z tej property. To tzw. „shared event parameters” i są w konfiguracji od połowy 2024 roku. Dzięki temu content_type, topic_cluster, author_slug automatycznie dopinają się do każdego eventu, również do konwersji, bez konieczności mapowania ich osobno dla każdego tagu eventowego. Jest to także bardziej wydajne w GTM, bo nie trzeba duplikować konfiguracji.

Drugi trick to konwersje z parametrami kontekstu interakcji. Gdy user klika CTA „pobierz ebook” w środku pillara, wypchnij parametr cta_position ze scrollem i sekcją (np. „h2-3-below-table”). To daje odpowiedź na pytanie, które CTA w artykule faktycznie generują pobrania — i może się okazać, że 80 procent konwersji pochodzi z jednego CTA na 70 procent długości, a pierwsze dwa CTA w intro są bezużyteczne. Taki wniosek bez custom dimensions jest niedostępny.

Czym różni się custom dimension od custom metric?

Custom dimension to atrybut tekstowy (albo liczba potraktowana jako kategoria), po którym możesz grupować i filtrować. Custom metric to liczba, którą GA4 sumuje, uśrednia i pokazuje jako wartość w kolumnie raportu. Długość artykułu może być jednym i drugim — jeśli wypchniesz „3000-5000” jako bucket, to dimension, jeśli wypchniesz 3412 jako integer i zarejestrujesz jako metric, GA4 policzy średnią długość czytanych artykułów w sesji.

Dla SEO przydatne custom metryki to: internal_links_clicked (ile wewnętrznych linków kliknął user w sesji), faq_toggles (ile razy rozwinął accordion FAQ), time_to_first_scroll (sekundy od page_view do pierwszego scrolla). Metryki trzymają dane numeryczne, więc nie zjadają kardynalności tak szybko jak dimensions — limit wynosi 50 na property Standard i jest rzadko osiągany.

Co zrobić, gdy custom dimension ma 90 procent wartości „(not set)”?

To najczęstszy problem po pierwszym deployu i ma trzy typowe przyczyny. Po pierwsze, parametr jest wypychany do dataLayer po zestrzeleniu tagu GA4 Configuration — wtedy pierwszy event (najczęściej page_view) leci bez niego. Rozwiązanie: wypchnij dataLayer w head, przed kontenerem GTM, albo użyj custom HTML z triggerem „Consent Initialization — All Pages”. Po drugie, literówka w nazwie parametru — „content_type” w dataLayer vs „content-type” w GTM. Po trzecie, parametr nie jest mapowany w tagu GA4 Configuration, tylko w osobnym tagu eventowym, przez co leci tylko przy konkretnych interakcjach, a nie przy każdej odsłonie.

Debugowanie: otwórz DebugView w GA4, odśwież stronę z parametrem ?gtm_debug=x i sprawdź, czy parametr widać przy evencie page_view, a nie dopiero przy scroll albo click. Jeśli widać — problem jest w rejestracji (scope, nazwa). Jeśli nie widać — problem jest po stronie GTM/dataLayer.

Najczęstsze błędy w konfiguracji custom dimensions

Brak naming convention — wymiary nazywane przez różne osoby różnie (contentType, content_type, ContentType) tworzą duplikaty, których nie da się scalić po fakcie.
Używanie scope User dla atrybutów strony — typ treści przypisany do usera oznacza, że GA4 pamięta go między sesjami i nadpisuje przy każdej wizycie. To psuje raporty, bo user staje się „ostatnim typem treści, jaki widział”.
Wysyłanie surowych liczb jako stringów — word count jako „3412”, „3413”, „3414” generuje tysiące unikalnych wartości i raport staje się bezużyteczny. Zawsze bucketuj.
Rejestracja wymiaru bez wcześniejszego wypchnięcia parametru — GA4 zarejestruje dimension jako „(not set)” przez pierwsze dni, a potem i tak będzie to widoczne w raportach. Lepiej najpierw wdrożyć push do dataLayer, poczekać 24 h, sprawdzić w DebugView i dopiero rejestrować.
Przekraczanie limitu kardynalności (500 wartości) — GA4 agreguje wszystko powyżej tego limitu do wiaderka „(other)”. To się dzieje najczęściej przy internal search query i page_path — dla nich lepiej używać raportów Exploration z filtrem, nie custom dimensions.
Zmiana nazwy eventu po rejestracji wymiaru — jeśli wymiar jest scoped do eventu „view_article”, a potem zmienisz nazwę na „article_view”, wymiar przestaje zbierać dane. Trzeba zarejestrować go ponownie.
Ignorowanie consent mode — jeśli użytkownik nie wyraził zgody na analytics_storage, GA4 dostanie zdarzenie w trybie cookieless i parametry user-scoped mogą nie zostać zapisane. Testuj z odmową zgody.
Wrzucanie PII do custom dimensions — email, numer telefonu, adres IP w custom dimension to naruszenie ToS GA4 i property może zostać zawieszona. Hashuj albo nie wysyłaj w ogóle.

Jak custom dimensions wspierają raportowanie dla zarządu i klienta?

Custom dimensions to nie tylko narzędzie analityka — to też sposób na lepszy storytelling w raportach. Zamiast pokazywać zarządowi „ruch organiczny wzrósł o 18 procent”, możesz pokazać „pillary z cluster analityka wzrosły 37 procent, podczas gdy listicle spadły 12 procent, bo AIO przejęło tamten intent”. To są wnioski, które prowadzą do decyzji budżetowych — a bez custom dimensions ich po prostu nie widać.

Dla klienta agencyjnego najlepiej pracuje raport miesięczny w Looker Studio z czterema przełącznikami: cluster, content type, author, search intent. Klient sam filtruje, widzi swój ulubiony cluster i nie trzeba co miesiąc robić nowej prezentacji. Zespół z kolei może wrócić do Looker Studio z nowymi wymiarami i dobudować kolejne strony bez przebudowy źródła.

Co dalej po wdrożeniu pierwszych 15 wymiarów?

Pierwszy deploy to dopiero początek. Po 6-8 tygodniach zbierania danych zrób audyt: które wymiary mają sens (rozkład nie jest 95 procent jednej wartości), które są duplikatami w ukryciu (np. content_type i page_template mogą pokrywać to samo), a które są martwe (wszyscy mają „unknown”). Wyrzuć nieużywane — masz limit 75 i lepiej zostawić przestrzeń na eksperymenty z 2026 roku, np. parametr ai_generated (czy treść była pisana przez AI), content_refresh_count (który raz z rzędu aktualizujemy ten artykuł) albo sitemap_priority (jaką priorytetyzację nadałeś w XML).

Drugi krok to podpięcie custom dimensions do audiencji i konwersji. Audiencja „users with content_type = pillar AND engaged session” to świetna baza do remarketingu w Google Ads — wiesz, że ci ludzie czytali Twój cornerstone content i są ciepli. Konwersja z parametrem source_content_type pokazuje, z której kategorii treści przychodzą rejestracje — i to natychmiast zmienia priorytety w kalendarzu redakcyjnym.

Trzeci krok to BigQuery i własne modele atrybucji. Gdy masz 20-30 custom dimensions w evencie, możesz zbudować model, który pokaże, jaka kombinacja cech treści najlepiej konwertuje. Takie modele w 2026 robi się w Looker Studio Pro albo w zewnętrznych narzędziach BI — ale fundamentem są custom dimensions, bez nich nie ma danych wejściowych.

Jeśli robisz to po raz pierwszy, rekomenduję prosty plan: tydzień 1 — 5 wymiarów klasyfikujących treść, tydzień 2 — 5 wymiarów zachowań, tydzień 3 — 5 wymiarów kontekstu SEO, tydzień 4 — raport w Looker Studio i prezentacja dla zespołu. Po 30 dniach masz system, który wyprzedza 80 procent polskich stron, bo większość nadal patrzy tylko na Landing page + Source.

Jak przygotować dokumentację custom dimensions dla zespołu?

Im większy zespół, tym ważniejsza staje się dokumentacja. W praktyce rekomenduję prowadzenie jednego arkusza Google Sheets z kolumnami: nazwa wymiaru, parametr dataLayer, zakres, typ danych, zbiór dopuszczalnych wartości (enum lub wzorzec regex), kto właściciel biznesowy, data wdrożenia, data ostatniej weryfikacji i link do Exploration, gdzie wymiar jest używany. Taki arkusz pełni rolę kontraktu między analityką, developmentem i redakcją. Każdy nowy wymiar trafia do tego arkusza przed wdrożeniem i jest tam aktualizowany po każdej zmianie konfiguracji.

Druga warstwa dokumentacji to krótki opis w samym GA4 — pole „Description” przy rejestracji custom dimension. Pisz tam dokładnie, co oznacza każda wartość i kiedy parametr jest wypychany. Przyszły analityk, który zobaczy wymiar „content_type” z wartością „longform”, powinien od razu wiedzieć, czy to oznacza 2000+ słów, czy 3000+ słów — bo inaczej interpretacje rozjadą się między zespołami. W 2026 roku dodanie tego opisu zajmuje 30 sekund na wymiar, a oszczędza 2-3 godziny wyjaśnień kwartalnie.

FAQ — GA4 custom dimensions dla SEO

Ile custom dimensions można mieć w GA4?

W property Standard od końca 2025 roku limit wynosi 75 event-scoped i 25 user-scoped custom dimensions. W GA4 360 to odpowiednio 200 i 50. Do tego dochodzi 50 custom metrics w Standard. Dla większości projektów SEO wystarczy 15-25 wymiarów, więc limit nie jest barierą — barierą jest dyscyplina konfiguracji.

Czy custom dimensions działają wstecz?

Nie. GA4 zaczyna zbierać wymiar dopiero w momencie rejestracji. Parametry eventów mogą być w dataLayer wcześniej, ale żeby pojawiły się w standardowych raportach, trzeba je zarejestrować — i od tej chwili dane płyną. Dane historyczne zostają w postaci surowych event_params w BigQuery, jeśli masz włączony export.

Czy custom dimension wpływa na limit kardynalności GA4?

Tak, każdy wymiar event-scoped ma limit 500 unikalnych wartości dziennie. Po jego przekroczeniu wszystkie wartości powyżej trafiają do kubła „(other)”. Dlatego nie rejestruj jako custom dimensions rzeczy o wysokiej kardynalności (URL-e, zapytania wyszukiwania, user IDs) — dla nich używaj raportów Exploration z dynamicznym filtrem lub BigQuery.

Co jest ważniejsze: custom dimension czy custom metric?

Dla SEO w 2026 roku custom dimensions są znacznie ważniejsze, bo pozwalają grupować dane po atrybutach treści i intencji użytkownika. Custom metrics dodaje się wtedy, gdy chcesz mierzyć zachowania numeryczne (liczba kliknięć, czas, scroll), które nie są agregowane automatycznie. Zacznij od dimensions, metryki dodaj w drugiej kolejności.

Czy custom dimensions dzielą się między GA4 property?

Nie. Każda property ma własną listę wymiarów i własne rejestracje. Jeśli masz kilka property (np. osobne dla .pl i .com), musisz je zarejestrować dwa razy, choć w samym GTM kontenerze i dataLayer parametry mogą być te same. Zachowaj identyczne nazewnictwo, żeby móc później scalać dane w BigQuery.

Jak testować custom dimensions bez psucia produkcyjnej property?

Stwórz osobną property staging w GA4, podepnij ją pod ten sam GTM container, ale przez osobny workspace z preview mode. Wdrażaj i debuguj na stagingu przez 3-7 dni, a gdy działa, promuj workspace do produkcji. Alternatywnie, używaj filtra testowego w GA4 Admin → Data Streams → Configure tag settings — możesz wysyłać eventy z flagą „debug_mode” i zobaczyć je w DebugView bez zanieczyszczania raportów.

Czy custom dimensions mogą złamać RODO?

Mogą, jeśli wrzucisz do nich dane osobowe: email, imię i nazwisko, dokładną lokalizację, identyfikator CRM. Obowiązuje zasada: wszystko, co trafia do GA4, powinno być zanonimizowane lub zhashowane. Custom dimension user_logged_in = true jest OK, ale user_email = jan@example.com — to naruszenie RODO i ToS Google. Wrzucaj identyfikatory wewnętrzne (hashe), nie surowe dane.

Jak łączyć custom dimensions z Search Console?

Bezpośrednio się nie da — GA4 nie eksponuje wymiarów SC w eventach. Obejście polega na tym, że w BigQuery łączysz tabele events_* z GA4 i searchconsole.searchdata_url_impression po kluczu page_location/page. Wtedy do każdego eventu możesz dopisać impresje i CTR z SC i analizować je razem z własnymi custom dimensions. To standard raportów SEO na 2026 rok — patrz też oficjalna dokumentacja GA4 Event Parameters i przewodnik Custom dimensions w GA4.

Case study — jak polski e-commerce zyskał 42 procent insightów dzięki 12 custom dimensions

Dla kontekstu pokażę wdrożenie, które robiłem z jednym z polskich sklepów z kategorii home & garden — 450 indeksowanych URL-i, 180 tysięcy sesji miesięcznie z organika, standardowe wdrożenie GA4 zrobione w 2023 roku bez żadnych custom dimensions. Problem: dział marketingu nie potrafił odpowiedzieć na pytanie, dlaczego blog generuje 38 procent ruchu, ale tylko 4 procent transakcji. Hipotezy były różne: za mało CTA, zły intent, user nie wraca na produktówki. Bez danych rozstrzygnięcie było niemożliwe.

Wdrożyliśmy 12 custom dimensions w dwóch sprintach. Pierwszy sprint: content_type (blog vs category vs product), blog_intent (how-to, comparison, buying-guide, inspirational), product_category_l1, price_bucket, stock_status i has_video. Drugi sprint: scroll_depth, cta_clicked, internal_links_to_product, faq_interaction, newsletter_signup_source i returning_blog_reader. Po 45 dniach zbierania danych zbudowaliśmy raport w Looker Studio, który pokazał trzy rzeczy. Po pierwsze, blog z intentem buying-guide miał 9 procent transakcji w tej samej sesji, podczas gdy inspirational 0,4 procent — różnica 22x. Po drugie, użytkownicy, którzy kliknęli CTA internal_links_to_product z pozycji po 60 procent scrolla, konwertowali 4,1 razy lepiej niż ci, którzy klikali w pierwszych 20 procentach artykułu. Po trzecie, artykuły z has_video = true miały niższy CR od tekstowych, co było totalnym zaskoczeniem i zmieniło priorytety produkcji contentu.

Konsekwencje biznesowe: klient przesunął budżet z produkcji wideo do rozbudowy artykułów typu buying-guide, dodał sekcję „polecane produkty” na 60 procent długości każdego artykułu i w kwartał osiągnął wzrost transakcji z bloga o 38 procent przy stałym ruchu. Bez custom dimensions żadnej z tych hipotez nie dałoby się potwierdzić lub obalić — raport Engagement w GA4 pokazywałby tylko, że blog ma „dobry engagement rate”, co nie mówi absolutnie nic o pieniądzach.

Ile kosztuje wdrożenie custom dimensions i kto powinien to robić?

To pytanie pada na każdym warsztacie. Odpowiedź zależy od skali. Dla małego bloga (do 50 URL-i) wdrożenie 10 wymiarów zajmuje jedną osobo-dniówkę — analityk albo dev rozumiejący GTM, godzina na ustawienie naming convention, dwie godziny na dataLayer push w motywie, dwie godziny na konfigurację GTM, godzina na rejestrację w GA4 i dwie godziny na pierwszy raport w Looker Studio. To jest koszt 1500-2500 złotych netto w cenach rynkowych 2026 roku za kompletne wdrożenie, jeśli zlecasz agencji.

Dla średniego portalu (500-2000 URL-i) wdrożenie to zazwyczaj 3-5 osobo-dni, bo dochodzi praca nad automatyzacją po stronie CMS (custom fields, meta boxes, hooki, export/import klasyfikacji), testy regresyjne i dokumentacja dla redakcji. Koszt: 6000-12000 złotych za pełen pakiet z raportami w Looker Studio. Dla dużego e-commerce (5000+ URL-i z dynamicznymi kategoriami) projekt rozciąga się na 2-3 sprinty, bo trzeba zadbać o konsystencję między produktami, kategoriami, blogiem i koszykiem — koszt zazwyczaj 20-40 tysięcy złotych z projektem analitycznym.

Kto to powinien robić po stronie klienta? Najlepiej trio: analityk (definiuje wymiary i raporty), developer front-end (wdraża dataLayer) i content manager (pilnuje konsystencji klasyfikacji w CMS). Jeśli tego trio nie ma, najsłabszym ogniwem zawsze jest content manager — analityk zrobi specyfikację, dev ją wdroży, ale jeśli redakcja wrzuca „pillar” do 40 procent artykułów, bo tak jest łatwiej, system przestaje działać już po dwóch tygodniach. Inwestycja w proces po stronie redakcji jest ważniejsza niż sama techniczna konfiguracja.

Jak custom dimensions wspierają AIO (AI Overviews) i LLM traffic?

W 2026 roku ruch z AI Overviews i cytowań w ChatGPT, Perplexity czy Gemini stał się osobną kategorią — i GA4 domyślnie nie umie go rozpoznać. Trafia pod „Google / organic” albo „Direct / none”, zależnie od tego, jak user trafił na stronę. Custom dimension aio_referrer rozwiązuje ten problem — w dataLayer sprawdzasz User-Agenta i URL referera, i jeśli zawiera znaczniki generatywnych interfejsów (Google AI Overview, Gemini, ChatGPT z plugin search, Perplexity), ustawiasz wartość parametru na odpowiedni identyfikator.

Wdrożenie jest proste: krótki skrypt w head odczytuje document.referrer, porównuje z listą wzorców (np. /^https://www.google.com/aio/, /chat.openai.com/, /perplexity.ai/, /gemini.google.com/) i wypycha odpowiednią wartość. Druga warstwa to parametry URL — coraz więcej interfejsów AI dołącza UTM-y typu utm_source=chatgpt, które wystarczy odczytać i zmapować. Po 30 dniach zbierania danych możesz zobaczyć, ile realnie ruchu dostajesz z AIO — i czy warto inwestować w audyt pod AIO dla kolejnych pillarów.

W raportach łączysz aio_referrer z content_type i search_intent — okazuje się, że AIO najczęściej cytuje odpowiedzi typu how-to z pillarów, a prawie nigdy nie cytuje listicle. To bardzo silny sygnał do redakcji, że format pillara wspiera pojawianie się w AIO, a listicle wspiera wyłącznie klasyczne SERP.

Co dalej — operacjonalizacja pomiaru

Jeśli doczytałeś do tego miejsca, masz już komplet wiedzy, żeby wdrożyć własny system custom dimensions w GA4. Kolejny krok to operacjonalizacja — czyli zrobienie z tego powtarzalnego procesu, a nie jednorazowego projektu. W praktyce oznacza to trzy rzeczy. Po pierwsze, dodaj do swojego briefu dla autorów pole „content_type” i „topic_cluster” — niech redakcja wie, jak klasyfikuje tekst, zanim trafi on do CMS. Po drugie, zbuduj w WordPressie custom fields (najprościej przez ACF albo wbudowane meta), które zasilają dataLayer automatycznie z danymi posta. Po trzecie, podepnij audyt custom dimensions do comiesięcznego retro zespołu SEO — przeglądajcie 3 najczęściej używane wymiary i sprawdzajcie, czy na ich podstawie podejmujecie decyzje.

W 2026 roku wygrywają zespoły, które traktują GA4 jak platformę analityczną, a nie jak dashboard. Custom dimensions to fundament tej zmiany — pozwalają zadawać pytania typu „jak długość pillara wpływa na konwersję z AIO ruchu w cluster analityka” i w ciągu 5 minut dostać odpowiedź. Dashboardy takich odpowiedzi nie dają. I właśnie dlatego następnym razem, gdy będziesz otwierać GA4 z pustym raportem, zapytaj siebie: czy ja tu rzeczywiście widzę swój biznes, czy tylko domyślne wymiary Google? Jeśli to drugie, masz dokładnie 4 tygodnie roboty, żeby to zmienić — i ten artykuł jest mapą na te cztery tygodnie.