- A fizetési oldalról visszaérkező vásárlót a GA4 hivatkozó forgalomnak látja, ezért a bevétel egy része a fizetési szolgáltatóhoz kerül a valódi csatorna helyett.
- A nem kívánt hivatkozások listáját a webes adatfolyam címkebeállításaiban találod, és domain szintű feltételekkel dolgozik.
- A beállítás csak az utána gyűjtött adatokra hat, a múltbeli riportok változatlanok maradnak.
- Az ellenőrzéshez a DebugView-ban az ignore_referrer paramétert, néhány nap múlva pedig a forrás szerinti bevételt érdemes megnézni.
- A levelezőrendszerből érkező forgalmat UTM paraméterrel érdemes rendezni, a kizárási lista erre rossz eszköz.
Megnyitod a GA4 forgalomszerzési riportját, és a bevételt hozó források között ott áll a SimplePay, a Barion vagy a PayPal. Hirdetést nem futtatsz náluk, linket sem kaptál tőlük, mégis úgy tűnik, mintha ők hoznák a vásárlóid egy részét. Ez mérési mellékhatás, amely szinte minden olyan webshopot érint, ahol a fizetés külső oldalon történik. A jó hír, hogy néhány perc alatt rendezhető. A rossz hír, hogy a már begyűjtött adatokon nem segít.
Miért jelenik meg a SimplePay, a Barion vagy a PayPal forrásként a GA4-ben?
Azért, mert a vásárló a fizetés idejére elhagyja a webshopodat, majd egy másik domainről tér vissza a köszönőoldalra, és a GA4 ezt a visszatérést hivatkozó forgalomként rögzíti.
A folyamat a böngésző szemszögéből így néz ki. A látogató például egy Google-hirdetésről megérkezik, kosárba tesz, kitölti a pénztárat, majd a fizetés gombra kattint. Ekkor átkerül a fizetési szolgáltató oldalára, sok esetben onnan még a kártyakibocsátó bank azonosító felületére is. A sikeres fizetés után a szolgáltató visszairányítja a webshopod köszönőoldalára. Ennél az oldalbetöltésnél a böngésző hivatkozóként a fizetési oldal címét adja át, a GA4 címkéje pedig ezt olvassa ki, és eltárolja az esemény page_referrer paraméterében.
A purchase esemény jellemzően éppen ezen a köszönőoldalon sül el. A legértékesebb eseményed tehát olyan pillanatban keletkezik, amikor a GA4 szerint a látogató éppen a fizetési szolgáltatótól érkezett.
Hivatalosan igazolt: a Google Analytics súgója a nem kívánt hivatkozások tipikus példájaként említi a külső fizetésfeldolgozókat, és erre az esetre ajánlja a kizárási listát. A saját domainedről érkező önhivatkozást a GA4 alapból figyelmen kívül hagyja, a külső fizetési oldalt viszont magától nem ismeri fel.
Hogyan torzítja ez a csatornák teljesítményét?
Úgy, hogy a bevétel és a vásárlások egy része a fizetési szolgáltató neve alá kerül, miközben a hirdetés, a hírlevél vagy az organikus keresés gyengébbnek látszik a valóságosnál.
A torzítás két úton jön létre. Az első a munkameneten belüli eset. A GA4 a munkamenet közben érkező új forrás miatt nem indít új munkamenetet, a kulcsesemények hozzárendelésénél azonban az utolsó nem közvetlen érintés számít. Ha a vásárlás előtti utolsó ismert forrás a fizetési oldal, a modell neki ad elismerést vagy annak egy részét.
A második út az új munkamenet. Az alapértelmezett munkamenet-időkorlát 30 perc. Ha a vásárló közben előkeresi a kártyáját, megvárja a banki megerősítő kódot, vagy a mobilbank alkalmazásban hagy jóvá, könnyen kifut ebből az időből. A visszatéréskor új munkamenet indul, amelynek a forrása már teljes egészében a fizetési szolgáltató.
A következmény a riportokban több helyen látszik.
- A forgalomszerzési riportban a Referral csatorna aránytalanul magas vásárlási aránnyal szerepel, hiszen oda szinte csak fizető látogatók kerülnek.
- A fizetett csatornák megtérülése alacsonyabbnak tűnik, mert a rájuk eső bevétel egy része máshol jelenik meg.
- Ha a GA4 kulcseseményeit importálod a Google Adsbe, a kampányok kevesebb konverziót kapnak, és az automatikus ajánlattétel hiányos jelekből tanul.
- A csatornák közti költségvetési döntések hibás alapra épülnek.
Saját tapasztalat: kis és közepes webshopoknál a rendezetlen fiókokban rendszeresen látjuk, hogy a fizetési szolgáltató a bevétel szerinti első öt forrás között áll. A torzítás mértéke erősen függ attól, mennyien fizetnek kártyával, és mennyi időt töltenek a fizetési oldalon, ezért általános arányt nem lehet mondani.
Honnan tudod, hogy nálad is fennáll a probléma?
Onnan, hogy a forgalomszerzési riportban a munkamenet forrása szerint szűrve megtalálod a fizetési szolgáltató domainjét, és mellette vásárlás vagy bevétel áll.
- Nyisd meg a Jelentések menüben a Forgalomszerzés riportot.
- Az elsődleges dimenziót állítsd át munkamenet forrása és médiuma nézetre.
- A keresőmezőbe írd be egymás után a nálad használt szolgáltatók nevét, például simplepay, barion, paypal, stripe.
- Nézd meg a kulcsesemények és a teljes bevétel oszlopát ezeknél a soroknál.
- Keress rá a saját bankod vagy a kártyaelfogadó bank nevére is, mert a kártyás azonosító oldal külön domainen futhat.
Érdemes a tényleges domaineket is felírni, mert a kizárásnál ezekre lesz szükséged. A fizetési oldalak gyakran aldomainről futnak, a szolgáltató neve előtt például egy secure vagy checkout előtag áll. A legbiztosabb forrás a saját próbavásárlásod, amelynél a böngésző címsorából lépésenként kiírod, milyen domaineken haladtál át.
Hogyan állítod be a nem kívánt hivatkozások listáját a GA4-ben?
A webes adatfolyam címkebeállításaiban, a nem kívánt hivatkozások listázása pontnál adod meg azokat a domaineket, amelyeket a GA4-nek nem szabad forrásként kezelnie.
A beállításhoz szerkesztői jogosultság kell a tulajdonban. A menüpontok neve a felület nyelvétől és a Google aktuális elrendezésétől függően kissé eltérhet, a lépések sorrendje viszont évek óta ugyanaz.
- Lépj be az Adminisztrálás felületre, és az adatgyűjtésnél nyisd meg az Adatfolyamok pontot.
- Kattints a webshopod webes adatfolyamára.
- Az oldal alján válaszd a címkebeállítások konfigurálását.
- A Beállítások blokkban kattints az összes megjelenítésére, mert a keresett pont alapból rejtve van.
- Nyisd meg a nem kívánt hivatkozások listázását.
- Az egyezés típusánál válaszd azt, hogy a hivatkozó domain tartalmazza a megadott szöveget, a mezőbe pedig írd be a domaint, például
simplepay.hu. - Új feltétel hozzáadásával vedd fel a többi szolgáltatót is, például
barion.coméspaypal.com. - Mentsd el a beállítást.
Ha sok domaint kell kezelned, a reguláris kifejezéses egyezéssel egy sorba is rendezheted őket.
simplepay\.hu|barion\.com|paypal\.com|stripe\.com
Hivatalosan igazolt: a feltétel a hivatkozó domainre vonatkozik, a teljes URL-re vagy útvonalra nem lehet szűrni. Ha a hivatkozó egyezik valamelyik feltétellel, a Google-címke az eseményhez hozzáfűzi az ignore_referrer=true paramétert, és az Analytics ebből tudja, hogy a hivatkozót nem kell forrásként figyelembe vennie. A súgó adatfolyamonként korlátozott számú feltételt enged, ezért a banki oldalakat érdemes kifejezésekkel összevonni.
Fontos részlet, hogy a beállítás a Google-címkén keresztül érkező eseményekre hat. Ha a vásárlást szerveroldalról vagy a Measurement Protocol segítségével küldöd be, ott a forráskezelést külön kell átgondolnod.
Mit nem javít a beállítás visszamenőleg?
A korábban begyűjtött adatokat egyáltalán nem módosítja, a kizárás kizárólag a mentés után érkező eseményekre érvényes.
Ez több dolgot jelent a gyakorlatban.
- A múlt havi és a tavalyi riportokban a fizetési szolgáltató ugyanúgy forrásként szerepel majd, mint eddig.
- Az időszakok összehasonlításánál törés keletkezik. A beállítás utáni hetekben a hirdetési és organikus csatornák bevétele megugorhat anélkül, hogy a valós teljesítmény változott volna.
- A Google Adsbe már beimportált konverziók nem íródnak át.
- A kizárás nem pótolja azokat a vásárlásokat, amelyeknél a vevő a fizetés után bezárta a böngészőt, és a köszönőoldal be sem töltődött. Az külön mérési hiány, amelyet szerveroldali eseményküldéssel lehet csökkenteni.
Saját tapasztalat: a beállítás napját érdemes feljegyezni a riportjaid mellé. Fél évvel később senki nem fog emlékezni arra, miért lett hirtelen jobb a fizetett kampányok megtérülése, és a jegyzet megóv a téves következtetéstől. A régi időszakok becsléséhez a webshop saját rendelési adatait és a hirdetési fiókok konverzióit érdemes egymás mellé tenni, tudva, hogy ez közelítés.
Hogyan ellenőrzöd pár nap alatt, hogy működik a kizárás?
Két lépésben, azonnal a DebugView-ban egy próbavásárlással, majd néhány nap elteltével a forrás szerinti bevétel napi bontásával.
Azonnali ellenőrzés próbavásárlással
- Kapcsold be a hibakereső módot a Tag Assistant segítségével, vagy a böngészőbővítménnyel.
- Érkezz az oldalra egy saját, felismerhető UTM paraméteres linkről, például
?utm_source=teszt&utm_medium=ellenorzes. - Vásárolj végig valódi vagy tesztfizetéssel, a külső fizetési oldalon keresztül.
- A GA4 Adminisztrálás menüjében nyisd meg a DebugView-t, és keresd meg a köszönőoldal
page_viewéspurchaseeseményét. - Az esemény paraméterei között keresd az
ignore_referrerértéket. Ha ott van és igaz, a kizárás él.
A page_referrer paraméterben ettől még látszani fog a fizetési oldal címe. Ez rendben van, a GA4 megtartja az információt, csak forrásként nem használja.
Ellenőrzés a riportokban
Hivatalosan igazolt: a normál riportok adatainak feldolgozása 24 és 48 óra közötti időt vehet igénybe, ezért az első napon a riportokból még nem érdemes következtetni.
Három-öt nap után készíts egy szabad formátumú felfedezést. A sorokba tedd a dátumot, az oszlopokba vagy szűrőként a munkamenet forrását, értéknek pedig a vásárlások számát és a bevételt. A fizetési szolgáltató sorában a beállítás napjától nullához közeli értékeket kell látnod. Ha néhány vásárlás még megjelenik, azok jó eséllyel a mentés előtt indult munkamenetekhez tartoznak, vagy egy olyan domainről érkeztek, amely kimaradt a listából.
Hasznos kontroll a webshop adminjában látható rendelésszám is. A GA4 összes vásárlásának nem kell változnia a beállítástól, csak a források közti megoszlásnak. Ha az összesített szám is elmozdul, ott más mérési változás is történt.
Mely egyéb hivatkozók okoznak hasonló torzítást?
Minden olyan külső oldal, amelyen a látogató az útja közben áthalad, de amely valójában nem forrása a látogatásnak, tipikusan a levelezőrendszer, a belépési oldal és a saját, külön domainen futó rendszereid.
Ez a rész a mi nézőpontunk, a kategóriák szerint jelölve.
- Levelezőrendszerek (saját tapasztalat). Ha a hírleveled linkjein nincs UTM paraméter, a webes levelezőből kattintó olvasó a levelező domainjével, hivatkozó forgalomként érkezik, az asztali vagy mobilos levelezőprogramból kattintó pedig közvetlen forgalomként. Az e-mail csatorna így szinte láthatatlan marad. Itt a megoldás a következetes UTM jelölés. A levelező domainjét a kizárási listára tenni rossz irány, mert a forgalom ettől közvetlenné válna, és ugyanúgy elveszne a csatorna.
- Belépési és azonosító oldalak (saját tapasztalat). A közösségi fiókkal történő bejelentkezésnél a látogató átmegy a Google, a Facebook vagy az Apple azonosító oldalára, majd visszatér. Hasonlóan viselkedik az ügyfélkapus vagy banki azonosítás, illetve a jelszó-visszaállító e-mailből nyitott oldal. Az azonosító szolgáltatók domainje jó jelölt a kizárásra.
- Saját, külön domainen futó rendszerek (hivatalosan igazolt megoldással). Időpontfoglaló, jegyértékesítő, külön domainen futó pénztár vagy ügyfélportál esetén a domainek közötti mérés beállítása a helyes út, ha a másik oldalon is a te GA4 címkéd fut. Az így megadott domaineket a GA4 nem kezeli hivatkozóként.
- Külső űrlapok, számlázó és futárkövető oldalak (szakmai feltételezés). Ha a rendelés-visszaigazoló vagy a csomagkövető oldalról vissza lehet kattintani a webshopba, a visszatérő vevők ezek neve alatt jelennek meg. Ez valódi visszatérő forgalom, ezért inkább külön csoportként érdemes kezelni, mint kizárni. Hogy melyik a jobb döntés, az attól függ, mire használod a riportot.
Mit ne tegyél a kizárási listára?
Semmit, ami valódi forgalmi forrás, még akkor sem, ha zavarónak találod a riportban.
A kizárt hivatkozóról érkező látogató forrása eltűnik, és ha nincs korábbi ismert forrása, közvetlen forgalomként jelenik meg. Ezért ne zárd ki a partneroldalakat, az árösszehasonlítókat, a közösségi oldalakat és az AI-asszisztenseket sem. A ChatGPT, a Perplexity vagy a Copilot felől érkező látogatás éppen az a jel, amelyből látod, hogy a tartalmadat idézik a válaszmotorok. A levélszemét jellegű hivatkozókat se itt kezeld, azokra a riportszűrő való.
Milyen ellenőrzőlistán érdemes végigmenni?
Egy rövid, hat pontból álló lista elég ahhoz, hogy a beállítás ne maradjon félkész.
- Felírtad egy próbavásárlásból a fizetési folyamat összes domainjét, a banki azonosító oldalt is.
- Minden domain szerepel a nem kívánt hivatkozások listáján, lehetőleg tartalmazás alapú feltétellel.
- A DebugView-ban láttad az
ignore_referrerparamétert a vásárlásnál. - Feljegyezted a beállítás dátumát a riportjaid mellé.
- A hírlevelek és az automatikus e-mailek linkjein van UTM paraméter.
- Új fizetési mód bevezetésekor újra lefuttatod a próbavásárlást.
A helyes forráskezelés nem garantál jobb eredményt, viszont jó eséllyel közelebb visz ahhoz, hogy a döntéseid a valós csatornateljesítményre épüljenek.
Források és további olvasnivalók
- Google Analytics Súgó, a nem kívánt hivatkozások azonosítása
- Google Analytics Súgó, domainek közötti mérés beállítása
- Google Analytics Súgó, adatfrissesség és feldolgozási idő
- Google Analytics Súgó, forgalmi források és hozzárendelés a GA4-ben
- Google Tag Platform dokumentáció, a Google-címke beállításai
- Google Ads Súgó, Analytics-kulcsesemények importálása
- W3C, Referrer Policy ajánlás
Gyakori kérdések
Miért látom a SimplePay-t vagy a Bariont forrásként a GA4 vásárlási adatainál?
Mert a vásárló a fizetés idejére átmegy a szolgáltató oldalára, és onnan tér vissza a köszönőoldalra. A böngésző ilyenkor a fizetési oldalt adja át hivatkozóként, a GA4 pedig ezt forrásként rögzíti, amíg a domaint fel nem veszed a nem kívánt hivatkozások listájára.
Átírja a GA4 a korábbi adatokat, ha beállítom a nem kívánt hivatkozások listáját?
Nem. A beállítás csak a mentés után gyűjtött eseményekre érvényes, a múltbeli riportokban a fizetési szolgáltató továbbra is forrásként szerepel. Érdemes feljegyezni a beállítás napját, hogy később érthető legyen a riportokban látható törés.
Mennyi idő után látszik a változás a riportokban?
A DebugView-ban egy próbavásárlásnál azonnal ellenőrizhető az ignore_referrer paraméter. A normál riportokban a feldolgozás 24 és 48 óra közötti időt vehet igénybe, ezért a forrás szerinti bevételt három-öt nap után érdemes napi bontásban megnézni.
Elég a szolgáltató fő domainjét megadni, vagy az aldomaineket is fel kell venni?
Ha a tartalmazás alapú egyezést választod, a fő domain megadása az aldomaineket is lefedi. A banki kártyaazonosító oldal viszont gyakran teljesen más domainen fut, ezt egy próbavásárlással tudod biztosan kideríteni.
A levelezőrendszert is érdemes felvenni a kizárási listára?
Nem ajánlott. A kizárástól a hírlevélből érkező forgalom közvetlenné válna, és ugyanúgy nem látnád az e-mail csatornát. A helyes megoldás az, hogy minden levélben lévő linket UTM paraméterrel jelölsz.
Csökkenhet a mért vásárlások száma a beállítás után?
A kizárás a források közti megoszlást változtatja meg, a vásárlások összesített számát nem. Ha az összesített szám is elmozdul, akkor jó eséllyel más mérési változás is történt, amit a webshop saját rendelési adataival érdemes összevetni.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.