- A BigQuery-export nyers, sorszintű adatot ad, amiben nincs mintavételezés és nincs (other) gyűjtősor.
- A GA4 felületén az eseményszintű adatmegőrzés korlátos, a BigQuery-be kiírt adat addig marad meg, ameddig te tárolod.
- A napi export naponta egyszer, teljes és javított adatot ír ki, a folyamatos export perceken belül, de külön költséggel.
- A költség két tételből áll: a tárolt adatmennyiségből és a lekérdezések által beolvasott bájtokból, ezért a szűrt, oszlopszelektív lekérdezés a legfontosabb szokás.
- Az export visszamenőleg nem tölthető fel, ezért érdemes lehet bekapcsolni akkor is, ha ma még nem elemzel belőle.
A GA4 felülete a gyakori kérdésekre ad gyors választ. Amint saját logika szerinti tölcsért rajzolnál, két évvel korábbi hetet vetnél össze a mostanival, vagy a látogatói viselkedést a számlázási adatokkal kötnéd egybe, falba ütközöl. A BigQuery-export ezt a falat bontja le: a Google eseményszinten, nyersen kiírja ugyanazt az adatot egy adatbázisba, amit onnantól te kérdezel le SQL-lel.
Mit ad a nyers eseményexport, amit a GA4 felülete nem?
Röviden: mintavételezés nélküli, sorszintű adatot, korlátlan visszatekintést, tetszőleges logikájú tölcséreket, és a lehetőséget, hogy a saját üzleti adataiddal egy táblában nézd a viselkedést.
Tovább a témában: GA4 adatmegőrzési idő · CRM összekötése a weboldallal
Négy különbség számít a mindennapokban:
- Mintavételezés nélküli elemzés. A GA4 szabványos jelentései nem mintavételezettek, az Elemzések (Explorations) viszont igen, ha az adathalmaz nagy. A BigQuery-ben minden sor ott van, becslés nélkül. Hivatalosan igazolt (Google Analytics Súgó).
- Korlátlan visszatekintés. A GA4 eseményszintű adatmegőrzése a felületen korlátos (szabvány property-n legfeljebb 14 hónap), a BigQuery-be kiírt adat viszont addig marad meg, ameddig te tárolod. Hivatalosan igazolt.
- Egyedi tölcsérek. A felület tölcsérei kötött szabályok szerint működnek. SQL-ben te döntöd el, mi számít lépésnek, mennyi idő telhet el két lépés között, és mi történik, ha valaki visszalép egyet.
- Adategyesítés. A viselkedési adat mellé beemelheted a CRM ajánlati státuszát vagy a számlázás valós árbevételét, és nem a GA4 bevételi eseményéből becsülsz.
Van egy ötödik, amit ritkán említenek. A felület a sok különböző értéket felvevő dimenzióknál (URL-ek, keresőkifejezések, cikkszámok) egy gyűjtősorba tolja a ritka értékeket, és onnantól azok külön nem láthatók. A BigQuery-ben ilyen nincs, minden érték a saját sorában marad. Saját tapasztalat: hosszú termékkatalógusnál gyakran pont ez az első pont, ahol a felület használhatatlanná válik a részletes elemzéshez.
Mit nem old meg a BigQuery-export?
Röviden: nem javítja a mérésed minőségét, és a számai nem lesznek azonosak a felület számaival.
Ha a méréskód rosszul van bekötve, a nyers adat is rossz lesz, csak részletesebben. Az export a beérkezett eseményeket írja ki, a felületen látható modellezett kiegészítéseket (például a hozzájárulási módhoz kapcsolódó modellezést) nem tartalmazza, ezért a két felület számai eltérhetnek. Hivatalosan igazolt. A munkamenet és az attribúció fogalmát is neked kell újraépítened SQL-ben, mert a nyers táblában eseménysorok vannak, nem kész munkamenetek. Szakmai feltételezés: a legtöbb csapatnál nem az SQL írása a szűk keresztmetszet, hanem az, hogy senki nem definiálta pontosan, mit is akarnak mérni.
Hogyan kapcsolod be az exportot lépésről lépésre?
Röviden: egy Google Cloud projekt, egy összekötés a GA4 adminban, és néhány beállítási döntés.
- Hozz létre (vagy válassz ki) egy Google Cloud projektet, és kapcsold be rajta a számlázást. Számlázás nélküli, próba jellegű projekt idővel lejár, és viheti magával az adatot.
- Engedélyezd a projektben a BigQuery API-t.
- A GA4-ben legyen szerkesztői jogosultságod a property-n, a Cloud projektben pedig legalább szerkesztői szintű hozzáférésed.
- GA4 Adminisztráció, Termékösszekapcsolások, BigQuery-összekapcsolások, majd Összekapcsolás.
- Válaszd ki a projektet és az adattárolás helyét (régió). Ezt később nem tudod megváltoztatni, ezért érdemes az EU-t választani, ha az ügyfél vagy a belső szabályzat ezt várja el.
- Válaszd ki az adatfolyamokat. Ha van webes és alkalmazás adatfolyamod is, döntsd el, mindkettő kell-e.
- Állítsd be az export gyakoriságát: napi, folyamatos, vagy mindkettő.
- Szükség esetén zárj ki eseményeket az exportból (például zajos, nagy tömegű technikai eseményeket). Ez érdemben csökkenti a tárolt sorok számát.
Az adat egy analytics_<property_id> nevű adatkészletbe kerül, benne napi bontású events_YYYYMMDD táblákkal. Az első tábla jellemzően a bekapcsolást követő napon jelenik meg.
Mi a különbség a napi és a folyamatos export között?
Röviden: a napi export naponta egyszer ír ki teljes, rendezett adatot, a folyamatos export perceken belül nyers eseményeket, de külön költséggel.
- Napi export: naponta egyszer készül el az előző nap teljes
events_táblája. Ez a végleges adat, benne a késve beérkezett eseményekkel is. Szabvány property-n napi eseményszám-korlát vonatkozik rá, és ha ezt tartósan túllépi a mérés, az export leállhat. Hivatalosan igazolt. - Folyamatos (streaming) export: az események percek alatt megjelennek egy
events_intraday_táblában. Ez a napon belüli monitorozáshoz jó: kampányindítás, akciónap, hibakeresés élesítés után. Külön díjazott, viszont nem esik a napi eseményszám-korlát alá.
Az intraday tábla nem végleges: amikor elkészül az adott nap napi táblája, az intraday tartalom helyét az veszi át. Emiatt a kettőt sosem szabad összeadni. Saját tapasztalat: a legtöbb kis- és középvállalati mérésnél a napi export bőven elég, a folyamatos export akkor éri meg, ha valaki tényleg ránéz az aznapi adatra, és tud is dönteni belőle.
Mitől függ a tárolási és a lekérdezési költség?
Röviden: a tárolás a kiírt adat mennyiségétől, a lekérdezés a beolvasott bájtok mennyiségétől függ, és mindkettő erősen befolyásolható.
Konkrét számot nem érdemes ígérni, mert a Google árazása és az ingyenes keret is változhat, a te adatmennyiséged pedig a forgalmadtól és az események számától függ. Amit érdemes tudni:
- A tárolás ára a tárolt adat méretével arányos. A méretet nem a látogatószám hajtja, hanem az események és a hozzájuk csatolt paraméterek száma. Egy bőbeszédű mérés sokszorosába kerülhet egy visszafogottnak.
- A hosszabb ideje nem módosított táblák olcsóbb tárolási kategóriába kerülnek, tehát a régi adat megtartása jellemzően nem a fő tétel.
- A lekérdezés ára a beolvasott bájtok mennyiségétől függ. A
SELECT *a legdrágább szokás, mert a BigQuery oszlopalapú: ha csak három oszlopot kérsz, csak hármat olvas be. - A dátumszűrés (
_TABLE_SUFFIXvagy partícióoszlop) drasztikusan csökkenti a beolvasott adatot. Szűrés nélküli, teljes időtávra futó lekérdezés a leggyakoribb költségforrás. - A visszatérő riportokhoz érdemes napi összesítő táblát építeni, és a vizualizációt (Looker Studio, Excel) arra kötni, nem a nyers eseménytáblára.
- A Cloud Console-ban állíts be költségriasztást és lekérdezési korlátot. Ez néhány perc, és megelőzi a kellemetlen meglepetést.
Szakmai feltételezés: egy átlagos hazai kis- és középvállalati weboldal adatmennyisége bőven belefér abba a nagyságrendbe, ahol a havi költség inkább kerekítési hiba, mint tétel, feltéve, hogy a lekérdezéseket nem futtatja senki naponta százszor szűrés nélkül.
Hogyan néz ki egy egyedi tölcsér a gyakorlatban?
Egy egyszerű, munkamenet-szintű lépcsőszámlálás így indul:
WITH lepesek AS (SELECT user_pseudo_id, (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id, event_name FROM `projekt.analytics_123456789.events_*` WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260831' AND event_name IN ('view_item','add_to_cart','begin_checkout','purchase')) SELECT event_name, COUNT(DISTINCT CONCAT(user_pseudo_id, CAST(session_id AS STRING))) AS munkamenetek FROM lepesek GROUP BY event_name
Két dolog látszik ebből. Az egyik, hogy a paraméterek beágyazott szerkezetben vannak, ezért UNNEST kell hozzájuk. A másik, hogy a munkamenetet a ga_session_id és a felhasználói azonosító együtteséből kell összeraknod, mert kész munkamenet-oszlop nincs a táblában.
Hogyan kötöd össze a CRM- és a számlázási adatokkal?
Röviden: a GA4 user_id mezőjén keresztül, ha a méréskódban tényleg átadod ezt az azonosítót.
Ez a lépés adja a legtöbb üzleti értéket, és ez marad el a leggyakrabban. Ha bejelentkezés vagy megrendelés után átadod a saját ügyfélazonosítót a GA4-nek, akkor a BigQuery-ben össze tudod kapcsolni a látogatási előzményt a valós, kiszámlázott árbevétellel. Onnantól nem azt nézed, melyik forrás hozott több űrlapkitöltést, hanem azt, melyik hozott fizető ügyfelet, és mekkora értékben. Fontos, hogy azonosítóként soha ne e-mail-címet vagy más személyes adatot adj át, hanem álnevesített kulcsot, és a folyamatot a saját adatkezelési tájékoztatód is fedje le.
Mikor felesleges bekapcsolni?
Röviden: akkor, ha nincs se adat, se kérdés, se ember, aki lekérdezze.
- Havi néhány száz látogatás mellett a felület jelentései minden érdemi kérdésre válaszolnak, mintavételezés pedig fel sem merül.
- Ha a méréskód hibás vagy hiányos, előbb azt kell rendbe tenni. A nyers export a rossz adatot is hűen kiírja.
- Ha nincs a csapatban SQL-t értő ember, és külső segítségre sincs keret, az adat évekig érintetlen marad.
- Ha az egyetlen igény egy havi látogatószám-riport, ehhez a felület vagy egy Looker Studio jelentés is elég.
- Ha a szervezet adatvédelmi szabályzata nem engedi az adat felhőbe másolását, előbb ezt kell tisztázni, nem utólag.
- Ha nincs stabil Google Cloud projekt és számlázás mögötte, a beállítás félbemarad, és a kiírás csendben leáll.
Ez a lista nem arról szól, hogy az export rossz, hanem arról, hogy a bekapcsolása önmagában nem hoz eredményt.
Miért érdemes bekapcsolni akkor is, ha ma még nem elemzel belőle?
Ez a saját nézőpontom, és nyíltan jelzem: részben szakmai feltételezés. A BigQuery-export nem tölthető fel visszamenőleg. Ami a bekapcsolás előtt történt, az soha nem kerül be a táblákba. Ez alapvetően más helyzet, mint egy elemzési eszköz, amit bármikor beköthetsz, és az első naptól kezdve hasznos.
Ezért a beállítás inkább biztosítás, mint elemzési projekt. Kis forgalmú oldalnál a tárolt adat mennyisége szerény, a bekapcsolás fél óra, és cserébe másfél-két év múlva lesz mihez nyúlni, amikor tényleg megjön az igény: átalakul a webshop, jön egy nagy kampány, vagy valaki megkérdezi, mi történt tavaly ugyanebben az időszakban. Aki akkor kapcsolja be, amikor szüksége lenne rá, éppen a hasonlítási alapot veszíti el. Saját tapasztalat: a leggyakoribb visszajelzés nem az, hogy felesleges volt, hanem az, hogy bár korábban kapcsoltuk volna be.
Mit ellenőrizz az első héten?
- Megjelent-e az
analytics_adatkészlet, és született-e benne napi tábla. - Stimmel-e nagyságrendileg a napi eseményszám a GA4 felületén látottal (kis eltérés normális).
- Jó régióban van-e az adatkészlet, mert utólag nem módosítható.
- Be van-e állítva költségriasztás a Cloud projektben.
- Ki van-e zárva az exportból az a néhány esemény, ami csak zajt termel.
- Átadódik-e a
user_id, ha később üzleti adattal akarsz összekötni.
Ez a hat pont nagyjából egy óra munka, és az esetek nagy részében megelőzi azt, hogy hónapok múlva derüljön ki: az export két hét után csendben leállt.
Források és további olvasnivalók
- Google Analytics Súgó: BigQuery Export (beállítás, korlátok, gyakoriság)
- Google Analytics Súgó: BigQuery Export séma
- Google Analytics Súgó: Adatmegőrzés és mintavételezés
- Google Cloud dokumentáció: BigQuery (partícionálás, lekérdezés-optimalizálás)
- Google Cloud: BigQuery árazás és költségkeret-beállítások
- Google Analytics fejlesztői dokumentáció: gtag.js és user_id
- Google Search Central dokumentáció
Gyakori kérdések
Visszamenőleg is megkapom az adatot, ha most kapcsolom be?
Nem. A BigQuery-export csak a bekapcsolás utáni adatot írja ki, a korábbi időszak nem tölthető fel utólag. Ez a legfőbb érv amellett, hogy a beállítást ne halaszd addig, amíg tényleg szükséged lesz rá.
Miért nem egyezik a BigQuery adata a GA4 felületén látottal?
Több oka lehet: a felület modellezett kiegészítéseket is mutathat, más az attribúciós logika, és a munkamenetet a nyers adatban neked kell felépítened. Kisebb eltérés normális, a nagyságrendnek viszont stimmelnie kell.
Napi vagy folyamatos exportot érdemes választani?
A napi export naponta egyszer ír ki teljes, végleges adatot, és a legtöbb esetben ez elég. A folyamatos export perceken belül elérhetővé teszi az eseményeket, de külön költséggel jár, ezért akkor indokolt, ha valaki tényleg ránéz az aznapi adatra.
Kell hozzá Google Cloud számlázás?
Igen, stabil működéshez számlázással rendelkező projekt kell. A próba jellegű, számlázás nélküli környezet idővel lejár, és ezzel az adat is elveszhet.
Mennyibe kerül havonta?
Ez a tárolt adatmennyiségtől és a lekérdezéseid méretétől függ, ezért felelősen nem lehet előre számot mondani. A költség jó eséllyel kordában tartható, ha az exportból kizárod a zajos eseményeket, dátumra szűrsz, és nem futtatsz szűrés nélküli teljes lekérdezéseket.
SQL-tudás nélkül van értelme bekapcsolni?
Elemzésre önmagában nincs, mert a nyers táblákhoz lekérdezés kell. Adatmegőrzési okból viszont lehet értelme, mert a kiírt adat később is felhasználható, amikor lesz mögötte szakértelem vagy erőforrás.
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.