Looker Studio riportálás magyar PPC ügynökségeknek: Sablonok, GA4 API trükkök és ügyfélbarát dashboardok

A magyar PPC ügynökségek többsége komoly csapdában vergődik: miközben havi 250 000 és 800 000 HUF közötti fix díjat (retainert) számláznak ki az ügyfeleknek stratégiai tanácsadásért, a transzparenciát biztosítani hivatott Looker Studio (korábban Data Studio) riportjaik használhatatlanok. A tipikus ügynökségi dashboard egy vizuális zajhalmaz, ahol a GA4 adatok közvetlen API-kapcsolaton keresztül próbálnak betölteni, de a Google szigorú kvótakorlátai (Quota Limits) miatt naponta többször hibaüzenettel összeomlanak. Az ügyfél nem érti a 12 oldalas, tizedesjegyekkel telezsúfolt táblázatokat, az ügynökségi PPC specialista pedig havonta 4-6 órát pazarol el az elromlott diagramok manuális javítgatására és a hiányzó Árukereső költségek kézi másolgatására. Ideje lenne végre tiszta vizet önteni a pohárba: a sablonos, lassan betöltő és kizárólag hiúsági mutatókat (vanity metrics) ábrázoló dashboardok nemcsak az ügynökség professzionalizmusát rombolják le, de közvetlenül hozzájárulnak az ügyfelek lemorzsolódásához (churn) is.

A hazai e-commerce és PPC piac eljutott arra a pontra, ahol a vakon optimalizált hirdetések kora végleg lejárt. A Consent Mode v2 bevezetése utáni adatvesztések, a harmadik féltől származó cookie-k kivezetése és az adósságokkal küzdő hazai lakossági fogyasztás miatt a magyar webshopok (különösen az 50 és 500 millió HUF közötti éves árbevételű KKV szegmens) minden elköltött forint sorsát pontosan látni akarják.

A Google Ads CPC (kattintásonkénti költség) árak egyes szektorokban – például a pénzügyi vagy biztosítási szférában – már rég átlépték a 600–1200 HUF közötti tartományt, de még a telített lakberendezési és divat fókuszú piacokon is mindennapos a 120–250 HUF közötti CPC. Ilyen akvizíciós költségek mellett egyetlen ügynökség sem engedheti meg magának, hogy olyan jelentéseket mutasson be, amelyekből hiányzik a valós üzleti eredmény.

A hazai ügynökségi piacon jelenleg az alábbi három tényező teszi elkerülhetetlenné a Looker Studio dashboardok alapjaiból történő újjáépítését:

• A GA4 API kvótakorlátai: A Google által bevezetett token-alapú korlátozás miatt a közvetlen GA4-Looker Studio összeköttetés nagyobb látogatottságú (havi 50 000+ munkamenet feletti) oldalaknál egyszerűen használhatatlan. Ha az ügyfél marketingese és az ügynökségi account manager egyszerre nyitja meg a riportot, az azonnal lehal a "Quota Error 10003" kóddal.
• A 27%-os magyar ÁFA-csapda: Sok külföldi sablon nem kezeli a nettó-bruttó eltéréseket. Ha a Google Ads és Meta hirdetési költségek nettó módon jelennek meg, miközben a webshop bevételei (például Shoprenter vagy UNAS rendszerekből) bruttó módon futnak be a GA4-be, a dashboardon látható ROAS (hirdetési kiadások megtérülése) 27%-kal torzítani fog felfelé – ami katasztrofális üzleti döntésekhez vezet.
• A lokális csatornák integrációja: A külföldről letöltött, előre gyártott Looker Studio sablonok nem tartalmaznak modulokat az Árukereső, az Olcsóbbat, a Heureka vagy a helyi hirdetési hálózatok számára. Márpedig egy magyar e-commerce szereplőnél az Árukereső gyakran a teljes hirdetési büdzsé 15-25%-át teszi ki, amelynek manuális importálása felesleges adminisztrációs terhet ró a csapatra.

---

Aki 2026-ban még közvetlenül köti össze a Google Analyticset a Looker Studióval, az az ügynöksége működését veszélyezteti. A modern, skálázható jelentéskészítés alapja egy köztes adattárház, amely jelen esetben a Google BigQuery.

Amikor a Looker Studio közvetlenül kérdez le adatokat a GA4-ből, minden egyes diagram, szűrőmódosítás vagy dátumtartomány-váltás API tokeneket fogyaszt. Ha a tokenkeret elfogy, a dashboard összeomlik. Ez különösen igaz az olyan összetett szűrésekre, mint a regex alapú kampánycsoportosítások vagy az egyedi dimenziók (custom dimensions) kezelése.

A GA4 ingyenes BigQuery exportját használva az adatok naponta egyszer (vagy akár folyamatosan, streaming módon) átkerülnek egy felhőalapú SQL adatbázisba. A Looker Studio nem a GA4 API-t fogja terhelni, hanem a BigQuery-t kérdezi le.

• Költséghatékony: A BigQuery ingyenes kerete (Sandbox) havi 10 GB tárhelyet és 1 TB lefutatott lekérdezést biztosít. Egy átlagos, évi 100–300 millió HUF árbevételű magyar webáruház adatmennyisége ennek a töredékét sem éri el, így az adattárolás és lekérdezés havi költsége gyakorlatilag 0 HUF.
• Sebesség: A közvetlen GA4 csatlakozóval terhelt dashboardok betöltési ideje gyakran meghaladja a 15-20 másodpercet. A megfelelően particionált BigQuery táblákra épülő riportok viszont 2-3 másodperc alatt betöltenek, drasztikusan javítva az ügyfélélményt.
• Adatbiztonság: A GA4-ben az adatok megőrzési ideje alapértelmezetten 2 vagy 14 hónap. A BigQuery-ben az adatok korlátlan ideig megőrizhetők, így akár 3-4 évre visszamenőleges (YoY) szezonalitási elemzéseket is végezhetünk.

---

Egyetlen sablon nem tud kiszolgálni minden igényt. Az ügynökségek legnagyobb hibája, hogy ugyanazt a riportot küldik el a napi szinten optimalizáló PPC-snek és a cégtulajdonosnak. Három különálló, mégis konzisztens dashboard szintet kell kialakítani.

Ez a riport maximum 1-2 oldalból állhat. A tulajdonost vagy a marketingigazgatót nem érdekli a Meta hirdetések CTR-je (átkattintási arány) vagy a Google Ads Quality Score-ja. Ők a pénzügyi hatékonyságot akarják látni.

A legfontosabb mérőszámok, amelyeket itt meg kell jeleníteni:

• Blended MER (Marketing Efficiency Ratio): `Összes Bevétel (HUF) / Összes Marketing Költség (HUF)`. Ez mutatja meg a marketing valós hatékonyságát, függetlenül az attribúciós modellek bizonytalanságaitól.
• POAS (Profit on Ad Spend): A ROAS ideje lejárt, mivel nem veszi figyelembe az árrést (margin). Ha egy 10 000 HUF értékű termék eladásához 2 000 HUF hirdetési költség társul, a ROAS 5x-ös (500%). De ha a termék beszerzési ára 8 000 HUF, akkor az ügynökség valójában veszteséget termel. A POAS kiszámításához integrálni kell a termékszintű árrést a jelentésbe.
• Új vs. Visszatérő vásárlók aránya (LTV fókusz): Különösen fontos a magyar piacon, ahol az új vásárlók akvizíciója sokszor nullszaldós vagy veszteséges az első tranzakció alkalmával.

```

+------------------------------------------------------------+

| C-LEVEL VEZETŐI DASHBOARD |

+------------------------------------------------------------+

| [ Összes Bevétel ] [ Blended MER ] [ POAS ] |

| 12 450 000 HUF 5.2x 1.8x |

+------------------------------------------------------------+

| [ Összes Ad Spend ] [ Új Vásárlók ] [ CAC ] |

| 2 394 000 HUF 62% 3 850 HUF |

+------------------------------------------------------------+

```

Ez a PPC specialista és az account manager munkaeszköze. Itt már helye van a technikai részleteknek, de szigorúan strukturálva, csatornák szerinti lebontásban.

• Költségkeret-kihasználtság (Pacing): Egy dinamikus sávdiagram, amely mutatja az adott hónapból eltelt idő arányát a tervezett vs. ténylegesen elköltött büdzsével (pl. ha a hónap 50%-ánál járunk, a 600 000 HUF-os Google Ads keretből pontosan 300 000 HUF körül kellene állnunk).
• Ad Fatigue (Hirdetés elfáradás) figyelmeztető: Meta kampányoknál a frekvencia és a CTR változásának korrelációját bemutató grafikon. Ha a frekvencia átlépi a 3.5-ös értéket, és a CTR 1.2% alá esik, a dashboard piros jelzéssel mutatja a kreatívcsere szükségességét.
• Kulcsszó- és Keresési kifejezés elemző: Google Ads esetén a nem konvertáló, de magas költségű kifejezések automatikus kigyűjtése, amely azonnali kizárási lehetőséget biztosít a PPC-s számára.

Mivel az Árukereső.hu nem rendelkezik gyári Looker Studio csatlakozóval, a magyar ügynökségek gyakran kihagyják a jelentésekből, vagy csak egy statikus táblázatba írják be az adatokat hó végén. Ez óriási hiba.

A megoldás: egy dedikált Google Sheets sablon, amelybe a PPC-s vagy egy automatizált script (pl. Supermetrics vagy Make.com) naponta beolvassa az Árukereső Admin felületéről letöltött CSV-t.

• Ajánlattételi hatékonyság: Mely termékeknél vagy kategóriáknál vagyunk túllicitálva, és hol költünk el feleslegesen kattintási díjat (magas átkattintás konverzió nélkül).
• CSS partner teljesítmény: Ha az ügynökség saját CSS partnert (pl. Producthero, Sklik) használ a Google Shopping kampányokhoz, ennek a 20%-os CPC kedvezménynek a realizálódását külön ki kell mutatni a dashboardon.

---

Az alábbi valós esettanulmány egy budapesti székhelyű, egyedi tervezésű ruhákat értékesítő webáruház (a továbbiakban: "Ügyfél") és egy 15 fős digitális ügynökség együttműködését mutatja be.

Az Ügyfél havi marketingbüdzséje 2.2 millió HUF volt, megosztva a Google Ads (Shopping fókusz), Meta Ads (DPA és imázs kampányok) és az Árukereső között. Az ügynökség korábban egy standard, harmadik féltől származó (fizetős) csatlakozókat használó Looker Studio sablont alkalmazott.

Az ügynökség az alábbi problémákkal szembesült minden hónap elején:

• A Supermetrics és egyéb csatlakozók licencei havi 150 000 HUF (kb. 380 EUR) extra költséget jelentettek az ügynökségnek, amit nem tudtak teljes egészében áthárítani az Ügyfélre.
• A GA4 API token limitjei miatt a riportok hétfő délelőttönként (amikor az Ügyfél vezetői elemezték a hétvégi eladásokat) 70%-ban nem töltődtek be.
• Az Árukereső költségeit a PPC specialista manuálisan, minden hétfőn másolta át egy Google Táblázatba, ami havonta 4 munkaórát vett igénybe.
• Az Ügyfél ERP rendszeréből (Billingo és egyedi raktárkezelő) származó valós visszaküldési arányok (amik a divat szektorban elérik a 18-22%-ot) egyáltalán nem jelentek meg a riportban. Így az ügynökség által büszkén prezentált 6.5x-ös ROAS a valóságban, a visszaküldések és az ÁFA levonása után mindössze 3.8x-os valós megtérülést jelentett.

Az ügynökség úgy döntött, hogy megszünteti az összes közvetlen fizetős csatlakozót, és átáll egy BigQuery-alapú, egyedi fejlesztésű Looker Studio hibrid architektúrára.

• GA4 BigQuery Export aktiválása: Beállításra került a napi ingyenes adatexport a Google Cloud Platformon belül.
• Költségadatok konszolidációja (BigQuery-be történő csatornázás):

* A Google Ads költségek közvetlenül és ingyenesen átkerültek a BigQuery-be a Google Data Transfer Service segítségével.

* A Meta Ads adatokat egy napi szinten futó, ingyenes Google Apps Script segítségével importálták egy Google Sheetbe, majd onnan a BigQuery-be.

* Az Árukereső napi költéseit és kattintásszámait egy Make.com (korábban Integromat) forgatókönyv segítségével automatizálták: a script minden éjjel lekérte az Árukereső API-ból az adatokat, és beírta a megfelelő BigQuery táblába.

• Pénzügyi korrekciós képletek bevezetése SQL szinten:

* A GA4 tranzakciós bevételekből leosztották a 27%-os magyar ÁFA-t: `revenue_net = purchase_value / 1.27`.

* Integrálták a Billingo API-ból származó sztornó és módosító számlák adatait, így a törölt vagy visszaküldött rendelések értéke levonásra került a napi riportokból.

| Mutató | Átállás előtt | Átállás után (3 hónappal) | Változás (%) / Megtakarítás |

| :--- | :---: | :---: | :---: |

| Havi szoftverköltség (csatlakozók) | 150 000 HUF | 0 HUF (BigQuery Free Tier) | -100% (150 000 HUF/hó megtakarítás) |

| Manuális riportálási idő (PPC-s) | 12 óra / hó | 0.5 óra / hó | -95.8% (11.5 munkaóra megtakarítás) |

| Riport betöltési idő (másodperc) | 18.4 mp | 1.8 mp | -90.2% gyorsulás |

| Adateltérés (Riport vs. Valóság) | +29% (túlzó ROAS) | < 1.5% (valós profit) | Kritikus pontosság-növekedés |

Az ügynökség a felszabadult havi 11.5 órát nem adminisztrációval, hanem a Meta kreatívok A/B tesztelésével töltötte. Ennek eredményeképpen az Ügyfél valós (visszaküldésekkel tisztított) profitja 14%-kal növekedett a negyedév végére, miközben az ügynökségi díj fix részét 20%-kal meg tudták emelni a bizonyítottan pontos, üzleti szemléletű riportálásnak köszönhetően.

---

Mit NE csinálj: A 5 leggyakoribb hiba a hazai ügynökségi Looker Studio jelentéseknél

Az elmúlt években több tucat hazai ügynökség dashboard-auditját végeztük el. Íme az a 5 leggyakoribb és legfájdalmasabb hiba, amit azonnal meg kell szüntetni.

Ez a legelterjedtebb hiba a hazai e-commerce riportálásban. A webáruház motorok (Shoprenter, UNAS, Shoptet, WooCommerce) a GA4 felé a bruttó (27%-os ÁFA-val növelt) árat küldik el tranzakciós értékként. Ezzel szemben a Google Ads és Meta Ads rendszerek a nettó hirdetési költségeket jelenítik meg.

Ha a Looker Studióban egyszerűen elosztjuk a GA4 bevételt a hirdetési költséggel, egy hamis, mesterségesen felduzzasztott ROAS-t kapunk.

A javítás: Mindig hozzunk létre egy számított mezőt (Calculated Field) a Looker Studióban vagy SQL szinten, amely korrigálja a bevételt: `Nettó ROAS = (GA4 Bevétel / 1.27) / Összes Hirdetési Költség`.

Egyes ügynökségek úgy gondolják, hogy a riport értéke egyenesen arányos annak hosszával. Olyan dashboardokat adnak át az ügyfeleknek, amelyek 50-60 oszlopos táblázatokat tartalmaznak, ahol a kulcsszavak, kampánynevek, hirdetéscsoportok és demográfiai adatok ömlesztve jelennek meg. Az ügyfél ettől kognitív túlterhelést kap, és soha többet nem nyitja meg a linket.

A dashboard nem adatbázis, hanem egy döntéstámogató eszköz. Ha egy vizualizáció nem válaszol meg azonnal egy üzleti kérdést, akkor nincs helye a kijelzőn.

Összehasonlítani a Meta Ads Managerben látható konverziós értéket a GA4-ben látható Meta/Organic konverziókkal ugyanazon a diagramon szakmai dilettantizmus. A Meta alapértelmezetten 7 napos kattintás- és 1 napos megtekintés-alapú (7-day click, 1-day view) attribúciót használ, míg a GA4 adatközpontú (Data-Driven) modellt alkalmaz.

Ha ezeket az adatokat egymás mellé tesszük magyarázat nélkül, az ügyfél azt fogja látni, hogy a Meta szerint generáltunk 5 millió HUF bevételt, míg a GA4 szerint csak 1.2 milliót.

Szakmai ajánlás: A dashboardon egyértelműen különítsük el az "Ad-Network Reported" (rendszerszintű) és a "GA4 Attributed" (összevont, független) eredményeket. Magyarázzuk el az ügyfélnek a két mérési módszer közötti különbséget.

A fejlesztők, a marketingesek és maga az ügyfél is végez tesztvásárlásokat a webshopban – különösen a SimplePay vagy Barion fizetési kapuk integrációjakor. Ha ezek a 100 Ft-os vagy éppen 0 Ft-os tesztek nincsenek kiszűrve a GA4-ben, vagy a nagy értékű, de végül ki nem fizetett rendelések benne maradnak a Looker Studióban, az teljesen eltorzítja a statisztikákat.

A dashboardon mindig alkalmazzunk olyan globális szűrőket, amelyek kizárják az ügynökségi és ügyféli IP-címeket, valamint a "test" vagy "teszt" tartalmú kuponkódokat vagy tranzakció-azonosítókat.

Gyakori hiba, hogy a jelentésekben csak az aktuális hónap adatait mutatják be, az előző hónaphoz (MoM) viszonyítva. Az e-commerce azonban szezonalitás-vezérelt. Egy kerti bútorokat árusító webshop áprilisi eredményeit a márciusihoz hasonlítani teljesen értelmetlen, hiszen a szezonális keresletrobbanás miatt mindenképpen növekedést fogunk látni.

A dashboardokon az elsődleges összehasonlítási alapnak mindig az előző év azonos időszakának (YoY - Year-over-Year) kell lennie.

---

Ha szeretnéd, hogy az ügynökséged szintet lépjen, és a riportálás ne nyűg, hanem az ügyfélmegtartás (LTV) eszköze legyen, hajtsd végre az alábbi lépéseket a következő 30 napban.

• Mérd fel az összes aktív ügyfeled jelenlegi Looker Studio dashboardját.
• Készíts egy Excel táblázatot az ügyfelek havi látogatottságáról és a felhasznált adatcsatlakozókról.
• Jelöld ki azokat az ügyfeleket (havi 50 000+ munkamenet felett), akiket kötelezően át kell állítani BigQuery alapokra a kvótahibák elkerülése érdekében.

• Hozz létre egy központi Google Cloud Projectet az ügynökségednek (vagy ügyfelenként egyet-egyet az ügyfél saját tulajdonában lévő GCP fiókjában – ez a tisztább jogilag).
• Kapcsold össze az ügyfelek GA4 fiókjait a BigQuery-vel. Válaszd a napi egyszeri exportot (Daily export) és szükség esetén a folyamatos (Streaming) exportot.
• Aktiváld a Google Ads Data Transfer Service-t a hirdetési költségek automatikus betöltéséhez.

• Hozz létre egy központi sablonfájlt Google Sheets-ben az Árukereső napi költségeinek fogadására.
• Állíts be egy Make.com forgatókönyvet, amely az Árukereső Partner Portál API-ból naponta lekéri a költség- és kattintási adatokat, és beírja azokat a Google Sheets táblázatba.
• Kapcsold össze ezt a táblázatot a BigQuery-vel külső táblaként (External Table), vagy húzd be közvetlenül a Looker Studióba másodlagos adatforrásként.

• Építsd meg a három bemutatott dashboard típust (Vezetői, Operatív, Csatorna-specifikus) Looker Studióban, de még ne élesítsd.
• Alkalmazz egységes, professzionális színvilágot (lehetőleg sötét módban tervezett dashboardokat, mert kevésbé fárasztják a szemet, és prémium érzetet keltenek).
• Állítsd be az automatikus pénzügyi korrekciókat (27%-os ÁFA levonás, visszaküldési ráták integrálása).

• Futtass le párhuzamosan méréseket a régi és az új dashboarddal 3 napig.
• Ellenőrizd a betöltési sebességet (cél: < 3 másodperc).
• Hasonlítsd össze az adatokat a GA4 és a webáruház adminisztrációs felületével (pl. Shoprenter statisztikák). Az adateltérés nem haladhatja meg a 2%-ot.

• Küldj egy személyre szabott videót (Loom vagy Youtube link) az ügyfeleknek, amelyben elmagyarázod az új dashboard működését, különös tekintettel a valós üzleti mutatókra (MER, POAS).
• Kérd meg őket, hogy töröljék a régi könyvjelzőiket, és kizárólag az új, szupergyors verziót használják.
• Határozz meg egy havi fix időpontot (pl. minden hónap 5. munkanapja), amikor az új dashboard alapján tartotok egy 15 perces stratégiai egyeztetést az ügyféllel.

Ezzel a strukturált átállással az ügynökséged nemcsak rengeteg értékes munkaórát szabadít fel, de olyan megkérdőjelezhetetlen szakmai autoritást épít fel a hazai piacon, amellyel könnyedén maga mögé utasítja a sablonokkal és elromló riportokkal bajlódó versenytársakat.