Odesłania z banków i pośredników płatności w Google Analytics - rozwiązanie

Odesłania z banków i pośredników płatności w Google Analytics pojawiają się wtedy, gdy użytkownik przechodzi ze strony do zewnętrznej bramki płatności, a potem wraca do serwisu po opłaceniu zamówienia lub rezerwacji. GA4 może wtedy potraktować domenę płatności jako źródło ruchu. W efekcie transakcja nie wygląda, jakby pochodziła z kampanii, SEO, newslettera czy partnera, tylko np. z PayU, Przelewy24, banku albo PayPala.

Problem dotyczy przede wszystkim e-commerce, ale nie tylko. Może występować wszędzie tam, gdzie płatność lub rezerwacja odbywa się przez zewnętrzny system: kursy online, bilety, subskrypcje, donacje, marketplace’y, systemy bookingowe i usługi lokalne z płatnością online.

W skrócie

• Bramka płatności może przejąć atrybucję transakcji w raportach GA4.
• Objawem są źródła typu payu.com / referral, przelewy24.pl / referral, paypal.com / referral albo domeny banków.
• Rozwiązaniem jest lista unwanted referrals w GA4 oraz poprawne cross-domain measurement tam, gdzie jest potrzebne.
• Zmiana nie naprawia danych historycznych — działa na przyszłe sesje.
• Nie należy usuwać wszystkich referrali na ślepo, bo część może być realnym ruchem partnerskim.
• Po wdrożeniu trzeba porównać GA4 z backendem sklepu lub systemem płatności.

Słowniczek pojęć

• Referral — wejście z innej domeny.
• Unwanted referral — domena, której nie chce się traktować jako źródła pozyskania.
• Bramka płatności — pośrednik płatności, np. PayU, Przelewy24, Stripe, PayPal.
• BNPL — płatność odroczona typu buy now, pay later.
• Self-referral — własna domena lub subdomena pojawiająca się jako źródło ruchu.
• Cross-domain measurement — pomiar użytkownika i sesji między różnymi domenami.
• _gl — parametr używany przez GA4 przy pomiarze między domenami.

Skąd bierze się problem

Typowa ścieżka wygląda tak:

1. Użytkownik wchodzi do sklepu z Google Ads, SEO, newslettera albo Meta Ads.
2. Dodaje produkt do koszyka i przechodzi do płatności.
3. Zostaje przekierowany na zewnętrzną domenę płatności.
4. Po opłaceniu wraca na stronę potwierdzenia.
5. GA4 widzi powrót z domeny płatności jako referral.

Jeśli konfiguracja nie jest poprawna, raporty mogą przypisać transakcję do bramki płatności, a nie do pierwotnego źródła. To utrudnia ocenę kanałów, kampanii i budżetu.

Jak sprawdzić, czy problem występuje

W GA4 warto przejrzeć:

• raport pozyskania ruchu według source/medium,
• źródła zawierające domeny płatności, banków i operatorów BNPL,
• strony typu /thank-you, /payment-success, /order-confirmation,
• różnice między transakcjami w GA4 i platformie sklepowej,
• ścieżkę testowego zamówienia w DebugView i Tag Assistant.

Podejrzane źródła to m.in. domeny z nazwami operatorów płatności, banków, checkoutów i systemów pośredniczących.

Jak naprawić odesłania z bramek płatności w GA4

Krok 1 — zebrać realne domeny z raportów

Nie warto zaczynać od przypadkowej listy 100 banków. Lepiej najpierw sprawdzić, które domeny faktycznie pojawiają się w raportach GA4 jako referral i mają udział w transakcjach.

Krok 2 — dodać je do unwanted referrals

W GA4 ścieżka konfiguracji może się zmieniać, ale logika jest taka:

1. Wejść w Admin.
2. Otworzyć Data streams.
3. Wybrać strumień web.
4. Wejść w Configure tag settings.
5. Otworzyć List unwanted referrals.
6. Dodać domeny pośredników płatności.

Krok 3 — sprawdzić cross-domain measurement

Jeśli checkout, koszyk, panel klienta albo płatność działa na osobnej domenie lub subdomenie kontrolowanej przez firmę, samo unwanted referrals może nie wystarczyć. Trzeba sprawdzić cross-domain measurement i zachowanie parametru _gl.

Krok 4 — wykonać testową płatność

Po zmianie należy wykonać testową transakcję i sprawdzić, czy zakup jest przypisany poprawniej, czy purchase nadal działa oraz czy dane zgadzają się z backendem.

Krok 5 — monitorować przez kilka dni

GA4 nie zmieni historii. Efekt należy oceniać dopiero na nowych danych, najlepiej po kilku dniach lub tygodniu, zależnie od wolumenu transakcji.

Przykłady domen do sprawdzenia

Poniższa lista jest punktem wyjścia, nie gotowym zestawem do bezrefleksyjnego wklejenia:

payu.com
secure.payu.com
przelewy24.pl
secure.przelewy24.pl
tpay.com
paynow.pl
stripe.com
checkout.stripe.com
paypal.com
checkout.paypal.com
blik.com
paypo.pl
twisto.pl

Do tego mogą dochodzić domeny banków, operatorów kart, systemów rat, marketplace’ów i własnych subdomen technicznych. Każdą domenę warto sprawdzić w danych, zanim trafi na listę.

Kiedy nie dodawać domeny do unwanted referrals

Nie każda domena finansowa powinna być wykluczona. Jeśli bank, fintech, partner albo marketplace faktycznie wysyła ruch do serwisu jako partner marketingowy, wykluczenie może ukryć realne źródło.

W takim przypadku lepiej:

• tagować linki partnerskie UTM-ami,
• rozdzielić domeny płatności od domen contentowych partnera,
• sprawdzić ścieżki użytkowników,
• opisać regułę w dokumentacji analityki.

Według typu biznesu

Sklep internetowy

Najważniejsze jest poprawne przypisanie transakcji do pierwotnego źródła i zgodność purchase z platformą sklepową. Trzeba sprawdzić bramki, banki, BNPL, PayPal, Stripe, systemy rat i domeny zwrotu.

Kursy, webinary i bilety

Płatność często przechodzi przez operatora zewnętrznego. Warto sprawdzić nie tylko zakup, ale też rejestrację, potwierdzenie udziału i maile transakcyjne.

SaaS i subskrypcje

Stripe, PayPal lub operator billingowy mogą występować w ścieżce płatności. Należy sprawdzić, czy rejestracja, trial, upgrade i płatność zachowują spójną sesję.

Usługi lokalne

Przy płatnościach za rezerwację lub zaliczkę problem może być mniejszy wolumenowo, ale nadal wpływa na ocenę kanałów pozyskania.

Najczęstsze błędy

Najczęstsze pytania

Czy unwanted referrals usuwa transakcje?

Nie. To ustawienie wpływa na sposób traktowania źródła ruchu, nie powinno usuwać zdarzenia purchase. Po zmianie i tak trzeba przetestować ścieżkę zakupu.

Czy wykluczenia działają wstecz?

Nie. Dane historyczne zostają takie, jakie były. Zmiana wpływa na przyszłe sesje i przyszłe raportowanie.

Czy trzeba dodać wszystkie banki?

Nie zawsze. Najpierw warto sprawdzić, które domeny faktycznie pojawiają się w raportach i przejmują atrybucję. Lista powinna wynikać z danych, a nie z samej teorii.

Co zrobić z własną subdomeną płatności?

Jeśli płatność, koszyk lub konto działa na własnej subdomenie, trzeba sprawdzić cross-domain measurement i cookie domain. Samo dodanie subdomeny do unwanted referrals może być tylko obejściem.

Czy to rozwiązuje różnice między GA4 i Google Ads?

Nie w pełni. Unwanted referrals porządkuje część atrybucji w GA4. Różnice między GA4, Google Ads i backendem mogą nadal wynikać z modeli atrybucji, zgód, okien konwersji i opóźnień.

Najważniejsze

• Bramki płatności mogą przejmować atrybucję transakcji w GA4.
• Rozwiązaniem jest lista unwanted referrals oraz poprawne cross-domain measurement.
• Nie należy wklejać list domen bez sprawdzenia danych.
• Zmiana działa na przyszłość, nie na historię.
• Po wdrożeniu trzeba wykonać testową płatność i porównać dane z backendem.

Źródła

• Google — Identify unwanted referrals
• Google — Cross-domain measurement
• Google — Campaign URL Builder
• Google — GA4 ecommerce measurement

Dalsza lektura

• Jak rozwiązać problem źródeł googleads.g.doubleclick.net w Google Analytics
• Czym jest UTM i jak wygenerować URL z UTM do Google Analytics
• Czym jest audyt Google Analytics i czy warto go wykonać
• Czym jest analityka e-commerce i dlaczego jest tak ważna