Śledzenie międzydomenowe w GA4: jak skonfigurować i kiedy tego nie robić

Klient ma stronę wizytówkową na jednej domenie i sklep na drugiej. Albo prowadzi blog pod marka.pl, a sprzedaż obsługuje sklep-marka.com. Użytkownik klika z artykułu do koszyka, a w GA4 pojawiają się dwa osobne konta: jedno z sesją z kampanii, drugie z odsyłaczem z własnej domeny. Sprzedaż trafia do źródła marka.pl / referral, a kampania, która faktycznie przyprowadziła klienta, wygląda na nierentowną.

Przyczyną nie jest błąd w tagu ani zgubione zdarzenie. Tak działa pomiar oparty na ciasteczkach pierwszej strony: identyfikator klienta zapisany na jednej domenie nie jest dostępny dla drugiej. GA4 rozwiązuje to parametrem _gl, który przenosi identyfikator razem z linkiem, ale tylko wtedy, gdy wskażesz mu, które domeny mają wymieniać się danymi.

Co się psuje, gdy tego nie ustawisz

Bez pomiaru międzydomenowego każda wizyta na drugiej domenie startuje jako nowy użytkownik i nowa sesja. Trzy rzeczy idą za tym w tej samej kolejności:

• Zawyżona liczba użytkowników i sesji. Jedna osoba liczy się dwa razy, a wskaźniki zaangażowania rozjeżdżają się na dwa wiersze.
• Złamane przypisanie. Źródłem staje się własna domena, więc kampania płatna oddaje zasługę odsyłaczowi z tego samego serwisu.
• Znikająca ścieżka. Nie zobaczysz, który artykuł albo która podstrona przekonała klienta przed zakupem.

W raportach wygląda to jak zwykły ruch odsyłający, więc problem długo pozostaje niewidoczny. Sygnał, który powinien zapalić lampkę, to Twoja własna domena w raporcie pozyskiwania ruchu. Jeśli widzisz ją jako źródło, przyczyna jest zwykle ta sama.

Subdomeny to inny przypadek

GA4 rozpoznaje subdomeny jednej domeny głównej automatycznie. Przejście z blog.sklep.pl na www.sklep.pl jest obsługiwane bez dodatkowej konfiguracji i nie wymaga pomiaru międzydomenowego. Wyjątkiem jest sytuacja, w której kod pomiarowy ustawia różne domeny ciasteczek dla poszczególnych subdomen. Wtedy odsyłacz z własnego serwisu pojawi się mimo wszystko, a naprawa polega na ujednoliceniu ustawienia domeny ciasteczka, nie na dopisywaniu subdomen do listy domen.

Kiedy lepiej zostawić dwie osobne usługi

Sklejenie domen nie jest dobrym rozwiązaniem w każdym przypadku. Jeśli dane muszą pozostać rozdzielone, na przykład agencja obsługuje sklep, a klient nie powinien widzieć ruchu z bloga, wspólna usługa tego nie załatwi. Filtry raportów nie dają twardego rozdzielenia dostępu, bo dane siedzą w jednej bazie. Podobnie, gdy dwie domeny mają innych odbiorców i inne cele biznesowe, wspólne sesje zaciemnią obraz zamiast go wyostrzyć.

Konfiguracja w interfejsie GA4

Ustawienie znajdziesz w Administracja, w sekcji Zbieranie i modyfikowanie danych, w pozycji Strumienie danych. Wybierz strumień internetowy, zejdź na dół do konfiguracji ustawień tagu i otwórz sekcję Konfiguracja domen.

• Obie domeny muszą mieć ten sam tag Google Analytics, czyli ten sam identyfikator G-, pochodzący z tego samego strumienia danych.
• Potrzebujesz roli Edytora lub wyższej w usłudze.
• Lista przyjmuje maksymalnie 100 warunków, a warunki łączą się logiką OR.
• Domeny korzystające z tego samego tagu Google pojawiają się automatycznie w sekcji rekomendacji, więc wystarczy je zatwierdzić.

Po zapisaniu GA4 sam pilnuje odsyłaczy z Twoich domen. Nie musisz dopisywać ich do listy niechcianych odsyłaczy, bo odsyłacz z własnego serwisu jest pomijany, gdy w adresie obecny jest parametr _gl. Pamiętaj tylko, że domeny z listy przestają być traktowane jako wyjścia w pomiarze rozszerzonym. Ma to sens, bo użytkownik nie opuszcza wtedy Twojego serwisu.

Czego wbudowane ustawienie nie obejmuje

Mechanizm działa przez nasłuch zdarzenia kliknięcia na poziomie dokumentu. GA4 dopisuje _gl do adresu w momencie, gdy użytkownik klika standardowy link. Poza tym zakresem zostają:

• Formularze obsługiwane przez JavaScript oraz żądania wysyłane metodą POST. Proste formularze Google potrafi udekorować, ale gdy wysyłkę przejmuje skrypt, parametr zwykle nie dochodzi do adresu docelowego.
• Przyciski i elementy, które uruchamiają nawigację JavaScriptem, a nie zwykłym odnośnikiem.
• Przekierowania po stronie serwera. Jeśli serwer nie zachowa parametrów zapytania, _gl ginie w drodze, zwykle za szybko, żeby zobaczyć to okiem.
• Skrypty, które zatrzymują propagację zdarzenia, na przykład wywołaniem zatrzymania bąbelkowania. Kliknięcie nie dochodzi wtedy do dokumentu i parametr nie zostanie dodany.
• Wejścia bez kliknięcia w link, na przykład z zakładki albo z wpisanego adresu. Takie przejście nie ma czego przenieść i sesja pozostanie rozbita.

Dla tych przypadków zostaje konfiguracja ręczna przez API gtag. Odczytujesz identyfikator klienta i identyfikator sesji na domenie źródłowej, przekazujesz je w adresie, a na domenie docelowej ustawiasz je w konfiguracji. To zadanie dla programisty, nie przełącznik w panelu.

Bramka płatności, czyli domena, której nie kontrolujesz

Klasyczny scenariusz z polskiego e-commerce: koszyk, przejście do bramki płatności, powrót na stronę podziękowania. Na domenie bramki nie ma Twojego tagu i nie będzie, więc nie skleisz tej sesji. Wracający użytkownik dostanie nową sesję, a jeśli nic nie zrobisz, źródłem zostanie domena bramki, na przykład Przelewy24 albo PayU.

Co da się zrobić bez dostępu do cudzej domeny: dopisz adres bramki do listy niechcianych odsyłaczy. GA4 oznaczy pasujące zdarzenia do pominięcia odsyłacza, więc bramka nie zostanie pokazana jako źródło, a konwersja wróci do pierwotnego kanału. Na strumień danych możesz dodać maksymalnie 50 takich warunków. Pamiętaj, że sesja i tak pęknie. Lista porządkuje przypisanie, nie odtwarza ciągłości.

Jeśli potrzebujesz pełnego obrazu zakupu, jedyna droga prowadzi przez pomiar po stronie serwera albo Measurement Protocol. Zdarzenie zakupu wysyłasz z backendu, z identyfikatorem, który sam nadajesz przy zapisie zamówienia. Wtedy kolejność koszyk, bramka, zakup da się złożyć w całość.

Zgody, RODO i identyfikator w adresie

Parametr _gl to identyfikator klienta umieszczony w adresie strony. Zostaje w logach serwera, w historii przeglądarki, w każdej wtyczce, która czyta adres, i w schowku, gdy użytkownik skopiuje link. Przekazywanie identyfikatora między Twoimi domenami powinno mieć odzwierciedlenie w polityce prywatności. Sama konfiguracja w GA4 tego nie zastąpi.

Drugi praktyczny problem to zgody. Gdy zgoda na przechowywanie analityczne jest odmówiona, GA4 pracuje bez ciasteczek. Nie ma wtedy identyfikatora, który można przenieść, więc ciągłość między domenami siada. Jeśli na jednej domenie działa pełny baner, a na drugiej zgody są przyznane domyślnie, zobaczysz dokładnie ten efekt: konfiguracja wygląda poprawnie, a sesje i tak się rozjeżdżają.

Jedna uwaga do diagnostyki. Samo pojawienie się parametru _gl nie dowodzi, że ustawienie działa. Parametr potrafi wystąpić także w trybie bezciasteczkowym, gdy zgody są odmówione i identyfikatory nie są zapisywane. Dowodem jest zgodność identyfikatora klienta po obu stronach, nie obecność napisu w adresie.

Jak sprawdzić, czy działa

1. Otwórz stronę z linkiem do drugiej domeny i kliknij go. W adresie docelowym powinien pojawić się parametr _gl.
2. Włącz DebugView i porównaj identyfikator klienta w metadanych zdarzeń z obu domen. Musi być identyczny.
3. Alternatywnie zestaw wartość ciasteczka _ga na obu domenach. Ta sama wartość oznacza, że identyfikator przechodzi.
4. Sprawdź, czy po przejściu nie powstaje nowa sesja ze źródłem odsyłającym z Twojej własnej domeny.
5. Przejrzyj reguły przekierowań po stronie serwera pod kątem gubienia parametrów zapytania.

Najpierw ustal, czy obie domeny tworzą jedną ścieżkę zakupową. Jeśli tak, konfiguracja w panelu zajmuje kilka minut i zwykle wystarcza. Jeśli nie, osobne usługi dadzą czystsze dane niż wymuszone sklejanie. W obu przypadkach zostaje ten sam problem do rozwiązania: bramka płatności i formularze poza zasięgiem wbudowanego mechanizmu. Tam decyduje już nie przełącznik, a architektura pomiaru.