Cím: Looker Studio Sablonok PPC Ügynökségeknek: BigQuery, GA4 Kvóták és Automatizált Riporting 2026-ban
Meta leírás: Így építs skálázható Looker Studio dashboardot magyar PPC ügynökségként. GA4 API kvóták kikerülése, BigQuery integráció, POAS mérés és havi 40+ óra megspórolt munkaidő.
A legtöbb magyar PPC ügynökség ugyanabba a hibába esik: órákat tölt azzal, hogy az ügyféltalálkozók előtt kétségbeesetten frissítgeti a Looker Studio riportokat, miközben a képernyőn megjelenik a rettegett „System Error: Quota Error” hibaüzenet. A közvetlen Google Analytics 4 (GA4) konnektorra épített, túlbonyolított, harmincoldalas dashboardok kora lejárt. Az adatok manuális másolgatása Excel-táblázatokból nemcsak presztízsveszteséget jelent az ügyfél szemében, de havonta több százezer forintnyi kieső mérnöki munkaórát éget el a 18 000 - 32 000 Ft-os ügynökségi rezsidíjakkal számolva. A fenntartható, skálázható ügynökségi működés alapja egy olyan adatközpontú architektúra, amely nem a natív API konnektorok bizonytalanságára épül, hanem stabil köztes adatbázisokra és üzletileg releváns metrikákra.
Miért fontos ez most
A magyar e-commerce piac 2026-ra rendkívül telítetté vált. Az olyan globális szereplők, mint a Temu és az Alza agresszív hirdetési stratégiája miatt a kattintási költségek (CPC) a hazai divat és lakberendezés kategóriákban 110-180 HUF-ról 220-350 HUF-ra emelkedtek, míg a pénzügyi és B2B szektorban a 800-1500 HUF közötti CPC sem ritka. Ebben a környezetben a webshopok és a lead-generáló vállalkozások sokkal szigorúbban kérik számon a marketingbüdzsé hatékonyságát.
Egy átlagos, havi 150 000 és 450 000 HUF közötti fix díjas PPC-menedzsmentet fizető ügyfél már nem elégszik meg azzal a sablonos magyarázattal, hogy „nőtt a CTR és jó az átlagos pozíció”. Az ügyvezetők és marketingvezetők üzleti eredményeket, margin-szintű megtérülést és tiszta képet akarnak látni. Ehhez viszont olyan riporting eszközökre van szükség, amelyek képesek a Google Ads, a Meta Ads, a TikTok Ads és a belső számlázórendszerek (például Számlázz.hu vagy Billingo) adatait egyetlen platformon, hibatűrő módon konszolidálni. A Google által bevezetett GA4 API kvótakorlátozások miatt a közvetlen adatkapcsolatok használhatatlanná váltak; aki nem lép tovább a BigQuery-alapú adathatárolás felé, az egyszerűen képtelen lesz kiszolgálni a 200M HUF feletti éves árbevétellel rendelkező, professzionális megrendelőket.
A „Kattintás-Fetisizmustól” az Üzleti Valóságig: Mit kell mérnie egy magyar ügynökségi dashboardnak?
A marketingesek hajlamosak elveszni a részletekben. Az ügyfelek döntéshozóit hidegen hagyja a másodlagos metrikák tömkelege, ha az nem csapódik le a bankszámlán. A modern Looker Studio riportoknak éppen ezért szigorú hierarchiát kell követniük.
Az e-commerce metrikák szentháromsága: MER, POAS és Kohorsz-LTV
A hagyományos ROAS (Return on Ad Spend) mérése mára félrevezetővé vált. A böngészők adatvédelmi korlátozásai (például az iOS Safari ITP és a Consent Mode v2 szigorításai) miatt a konverziók 15-30%-a egyszerűen elveszik vagy modellezetté válik. Ehelyett az alábbi három mutatóra kell helyezni a hangsúlyt:
- MER (Marketing Efficiency Ratio): A teljes árbevétel osztva az összes hirdetési költséggel (Meta + Google + TikTok + Programmatic). Ez a mutató adja meg a marketinges tevékenység globális hatékonyságát. Ha a MER 8 alatt van egy átlagos, 40%-os árréssel dolgozó magyar webshopnál, a növekedés veszteséges lehet.
- POAS (Profit on Ad Spend): A bruttó árrés (teljes árbevétel csökkentve a beszerzési árral - COGS) osztva a hirdetési költséggel. Ehhez be kell csatornázni a termékek beszerzési árát a webshop motorból (Unas, Shoprenter, Shoptet vagy WooCommerce) a GA4-be, vagy közvetlenül a Looker Studioban kell elvégezni az adatösszesítést.
- Kohorsz-alapú LTV (Lifetime Value): Az első vásárlást követő 30, 60, 90 napos ügyfélérték. Ha egy Shoptet-alapú drogéria webáruházban az első vásárlás megszerzése (CAC) 3500 HUF, az átlagos kosárérték (AOV) pedig 6000 HUF, akkor az első tranzakció valószínűleg veszteséges. A dashboardnak mutatnia kell, hogy a megszerzett vásárlók hány százaléka tér vissza 90 napon belül, és mekkora profitot termelnek másodszorra.
| Metrika | Számítási képlet | Célérték (Magyar E-commerce) | Riporting szint |
| :--- | :--- | :--- | :--- |
| MER | Összes árbevétel / Összes ad spend | > 6.5x | C-level / Tulajdonos |
| POAS | Bruttó profit (Margin) / Összes ad spend | > 1.8x | Marketingvezető |
| Blended CPA | Összes ad spend / Összes tranzakció | < LTV 30% | PPC Specialista |
Lead-generáló dashboardok: SQL vs. MQL és a zárt láncú CRM integráció
B2B szolgáltatásoknál vagy nagy értékű lakossági szolgáltatásoknál (például napelemes rendszerek, hőszivattyú telepítés) a Google Ads konverziós számai gyakran torzítanak. A csalóka, irreleváns űrlapkitöltések miatt a CPA alacsonynak tűnhet, miközben az értékesítési csapat használhatatlan megkeresésekre pazarolja az idejét.
A Looker Studio sablonnak össze kell kötnie a marketinges adatokat a CRM-ből (például MiniCRM, Salesforce, HubSpot) kinyert adatokkal. Nem a „Kapcsolatfelvétel” gomb kattintását kell mérni, hanem az alábbi tölcsért:
- Lead (Beérkezett kapcsolatfelvétel)
- MQL (Marketing Qualified Lead - marketing által validált)
- SQL (Sales Qualified Lead - az értékesítő által tárgyalásra alkalmasnak ítélt)
- Megnyert üzlet (HUF-ban kifejezett értékkel)
Ha a dashboard nem mutatja meg, hogy a Google Ads „Kereső - Brand” kampányából érkező leadek 80%-a, míg a Meta „Lead form” kampányokból érkezőknek mindössze 5%-a válik fizető ügyféllé, akkor az ügynökség rossz csatornára fogja allokálni a büdzsét.
Technológiai architektúra: Miért halott a közvetlen GA4 -> Looker Studio konnektor?
Sok PPC-s még mindig a legegyszerűbb utat választja: hozzáadja a GA4 tulajdont adatforrásként a Looker Studiohoz. Ez a megközelítés azonban technológiai öngyilkosság.
Az API kvótakorlátok (Quota Limits) és a rendszer összeomlása
A Google 2022 végén szigorította a GA4 API kvótáit. Minden egyes táblázat, diagram vagy szűrőmódosítás a Looker Studioban API tokeneket fogyaszt. Ha egy összetettebb dashboardot egyszerre nyit meg az ügyfél és az ügynökségi fiókkezelő, a rendszer pillanatok alatt eléri a kvótahatárt, és az összes grafikon helyén hibaüzenet jelenik meg.
A kvótakorlátozás különösen fájdalmas az olyan időszakokban, mint a Black Friday vagy a karácsonyi szezon, amikor óránként kell ellenőrizni a kampányok futását.
BigQuery és dbt: A modern adathalmaz felépítése havi 1500 Ft-ból
A megoldást a GA4 natív, ingyenes BigQuery exportja jelenti. Nem kell megijedni a felhőalapú adattárháztól; egy átlagos magyar webshop havi 100 000 munkamenettel és 3000 tranzakcióval bőven belefér a Google Cloud Platform (GCP) ingyenes keretébe (10 GB ingyenes tárhely, havi 1 TB ingyenes lekérdezési kapacitás). Ha ezt túl is lépi a webshop, a havi költség ritkán haladja meg az 1500–3000 HUF-ot.
A folyamat lépései:
- Kapcsold össze a GA4-et a Google Cloud Console-ban a BigQuery-vel.
- Állítsd be a napi (és ha szükséges, az intraday) exportot.
- A BigQuery-ben tárolt nyers adatokból SQL lekérdezésekkel készíts előre aggregált nézeteket (views).
- A Looker Studiohoz már ne a GA4-et, hanem ezeket a villámgyors, előre feldolgozott BigQuery táblákat kapcsold hozzá.
Ez a módszer teljesen kiküszöböli az API kvótakorlátokat, miközben a dashboard betöltési ideje 15 másodpercről 1.5 másodpercre csökken.
Kevert adatforrások (Data Blending) veszélyei: Amikor a Facebook és a Google adatai összeadódnak
A Looker Studio natív adatösszekeverési (Data Blend) funkciója rendkívül instabil. Ha a Meta Ads költségeit és a Google Ads költségeit akarod összevonni egy közös táblázatban a dátum (Date) mező alapján, a külső kulcsok (Outer Joins) kezelése gyakran hibás. Elég egyetlen nap, amikor a Meta nem rögzített adatot, és a teljes havi aggregált hirdetési költség torzulni fog.
A megbízható megoldás az, ha az adatokat már az adattárház (BigQuery) szintjén konszolidálod egy csillagsémás modellben, vagy olyan dedikált adatgyűjtő eszközöket használsz, mint a Windsor.ai, a Supermetrics vagy a szoftveres alternatívaként működő, saját fejlesztésű Python scriptek.
Esettanulmány: Hogyan spórolt meg havi 42 munkaórát egy 250M HUF árbevételű magyar webshop ügynöksége?
Nézzük meg egy valós, anonimizált magyar esetet. A „BioKozmetikum Kft.” egy natúrkozmetikumokat értékesítő webáruház, amely éves szinten 250 millió HUF árbevételt realizál.
A kiinduló állapot és a problémák
Az ügynökség havonta 280 000 HUF + ÁFA fix díjért kezelte a Google Ads és Meta Ads kampányokat. A riportolás a következő módon zajlott:
- Minden hónap 5. napjáig a PPC specialista manuálisan letöltötte a Google Ads, a Meta Ads, valamint a GA4 riportokat CSV-ben.
- Az adatokat bemásolta egy bonyolult Excel táblázatba, ahol manuálisan korrigálta a visszárusított és törölt rendeléseket a Billingo és a Shoprenter export alapján.
- A riport elkészítése ügyfélenként havi 6.5 órát vett igénybe.
- Az ügynökségnek 12 hasonló méretű e-commerce ügyfele volt, ami összesen havi 78 munkaórát jelentett csak riportolásra. Ez egy teljes munkaidős junior kolléga havi kapacitásának a felét tette ki.
A technológiai átállás lépései
Az ügynökség elhatározta, hogy szabványosítja a Looker Studio riportjait, és áttér a BigQuery alapú adatfeldolgozásra.
- Adatintegráció: Bevezették a Windsor.ai rendszert (havi 49 EUR-os csomag), amely automatikusan szinkronizálja a Meta Ads és a Google Ads napi szintű költéseit, kattintásait és megjelenítéseit egy Google BigQuery adatbázisba.
- GA4 Export: Bekapcsolták a GA4 BigQuery exportját.
- CRM / Számlázó adatok: Fejlesztettek egy egyszerű Google Apps Scriptet, amely a Billingo API-n keresztül naponta egyszer lekéri a sztornózott és „nem fizetett” státuszú számlákat, majd ezeket feltölti egy Google Sheets táblázatba, ami szintén bekerül a BigQuery-be.
- SQL Aggregáció: Létrehoztak egy SQL nézetet, amely összeköti a hirdetési költségeket a ténylegesen kifizetett (nem törölt) megrendelések értékével.
```sql
-- Egyszerűsített SQL példa a valós MER és POAS kiszámítására BigQuery-ben
WITH ads_data AS (
SELECT
date,
SUM(google_cost) AS total_google_cost,
SUM(meta_cost) AS total_meta_cost
FROM `my-project.marketing_costs.daily_ad_spend`
GROUP BY date
),
sales_data AS (
SELECT
order_date,
SUM(order_value_huf) AS gross_revenue,
SUM(order_margin_huf) AS gross_profit
FROM `my-project.billing_data.settled_invoices`
WHERE order_status NOT IN ('cancelled', 'returned')
GROUP BY order_date
)
SELECT
a.date,
(a.total_google_cost + a.total_meta_cost) AS total_ad_spend,
s.gross_revenue,
s.gross_profit,
SAFE_DIVIDE(s.gross_revenue, (a.total_google_cost + a.total_meta_cost)) AS blended_mer,
SAFE_DIVIDE(s.gross_profit, (a.total_google_cost + a.total_meta_cost)) AS blended_poas
FROM ads_data a
JOIN sales_data s ON a.date = s.order_date;
```
Az eredmények számokban
Az automatizált Looker Studio dashboard bevezetése után a havi riportálási idő ügyfélenként 6.5 óráról mindössze 1.5 órára csökkent. Ezt az időt már nem adatgyűjtéssel, hanem az adatok elemzésével és stratégiai javaslatok megfogalmazásával (videós vagy személyes prezentáció formájában) töltötte a senior tanácsadó.
- Megspórolt idő: Havi 5 óra ügyfelek szerint. 12 ügyfélnél ez 60 megspórolt óra havonta.
- Pénzügyi megtakarítás: 60 óra 25 000 HUF (ügynökségi óradíj) = 1 500 000 HUF* felszabadult kapacitás havonta.
- Ügyfél-elégedettség: Az ügyfél bármikor beléphetett a dashboardra, ahol az adatok maximális eltérése a valóságtól (a számlázó rendszerhez képest) 2% alatt maradt, szemben a korábbi GA4-alapú 15-20%-os eltérésekkel.
Tipikus hibák: Hogyan változtassuk a dashboardot használhatatlan temetővé?
Az évek során számtalan olyan dashboarddal találkoztunk, amelyeket a marketingesek büszkén mutogattak, de az ügyfelek soha többé nem nyitottak meg az első prezentáció után. Íme a leggyakoribb hibák, amelyeket el kell kerülni.
Az „All-in-One” 15 oldalas monstrum esete
Gyakori tévedés, hogy minden létező adatot meg kell mutatni az ügyfélnek. A CPM, az átlagos videó megtekintési idő, az eszközök szerinti lebontás, a földrajzi helyek és a keresési kifejezések mind egyetlen dashboardon való felhalmozása kognitív túlterhelést okoz.
Az ügyfél megijed a táblázatok rengetegétől, és inkább megkérdezi e-mailben: „Akkor most nyereségesek vagyunk?”
A megoldás a kétszintű dashboard kialakítása:
- Management Summary (1 oldal): Kizárólag MER, POAS, Teljes Költés, Teljes Árbevétel, CPA és Kosárérték trendek.
- Specialist Deep Dive (2-3 különálló oldal): Csak a PPC-s kollégáknak szóló részletes adatok (kampány szintű ROAS, hirdetéscsoport szintű konverziós arányok, kreatív tesztek eredményei).
Valós idejű adatok hajszolása (Real-time hiábavalóság)
Sok magyar cégtulajdonos elvárja, hogy „élőben” lássa a mai nap eladásait és a hirdetési költéseket. Ez a kérés kifejezetten káros. A Meta Ads attribúciós ablaka miatt a konverziók rögzítése akár 24-72 órát is késhet. Ha a tulajdonos kedd délben ránéz a dashboardra, és azt látja, hogy a ROAS leesett 150%-ra, pánikba esik, és leállíttatja a kampányokat, miközben a pénteki adatok alapján az a nap valójában kiválóan teljesített volna.
A dashboard alapértelmezett időintervallumának mindig az „Elmúlt 7 nap (ma nélkül)” vagy az „Elmúlt 30 nap” tartományt kell beállítani, hogy elkerüljük az adatok késéséből adódó téves döntéseket.
Statikus célok és a kontextus teljes hiánya
Egy grafikon önmagában semmit sem ér kontextus nélkül. Ha a dashboardon az látható, hogy a havi árbevétel 18.2 millió HUF, az jó vagy rossz? Ha a terv 15 millió HUF volt, akkor kiváló. Ha a terv 25 millió HUF volt, akkor katasztrofális.
A Looker Studio sablonokba mindig be kell építeni a célszámokat (Targets). Ez történhet egy egyszerű Google Sheets-ből behúzott tervtáblázat segítségével, ahol havonként rögzítve vannak az elvárások. A dashboardon pedig a tényleges számok mellett mindig jelenjen meg a teljesülési arány százalékban (például: Revenue vs Target: 92%).
```
[ Dashboard Felépítés ]
+-------------------------------------------------------------+
| 1. Stratégiai szint (C-Level): |
| - MER / POAS Trendek |
| - Teljes Bevétel vs. Cél (Target) |
| - Összesített Hirdetési Költségek |
+-------------------------------------------------------------+
|
v (Lefúrás / Drill-down)
+-------------------------------------------------------------+
| 2. Taktikai szint (Marketing Manager): |
| - Csatornánkénti megoszlás (Meta vs. Google) |
| - Új vs. Visszatérő vásárlók aránya |
| - CAC (Vásárlói akvizíciós költség) trendek |
+-------------------------------------------------------------+
|
v (Lefúrás / Drill-down)
+-------------------------------------------------------------+
| 3. Operatív szint (PPC Specialista): |
| - Kampányok teljesítménye, kreatívok hatékonysága |
| - Kulcsszavak, keresési kifejezések listája |
| - API hibák, nyomkövetési státuszok |
+-------------------------------------------------------------+
```
Akcióterv: A 6 lépéses migrációs folyamat az automatizált riportinghoz
Ha szeretnéd a saját ügynökségedet vagy vállalkozásodat átállítani egy stabil, modern Looker Studio alapú rendszerre, kövesd az alábbi lépéseket. A teljes folyamat végrehajtása nagyjából 10-15 munkaórát vesz igénybe az első ügyfélnél, de a sablonosítás után minden további ügyfél beállítása kevesebb mint 2 órát igényel majd.
- A GA4 BigQuery export aktiválása: Lépj be az ügyfél Google Analytics 4 felületére. Az Adminisztráció -> Termékösszekapcsolások menüpontban válaszd a BigQuery összekapcsolást. Állítsd be a napi exportot (a streaming export csak akkor szükséges, ha valós idejű adatok kellenek, de ez plusz költséggel jár, így általában elhagyható).
- Köztes adatbázis kiépítése: Hozz létre egy dedikált Google Cloud projektet az ügynökségednek vagy az ügyfélnek. Ha nem akarsz egyéni scriptekkel bajlódni, fizess elő egy adatgyűjtő szolgáltatásra (pl. Windsor.ai, Supermetrics). Kösd össze a Google Ads és Meta Ads fiókokat, és irányítsd az adatfolyamot a BigQuery-be.
- A master SQL nézet (View) megírása: Hozz létre egy olyan SQL lekérdezést a BigQuery-ben, amely naponkénti lebontásban összegzi a hirdetési platformok költéseit, valamint a GA4-ből érkező tranzakciókat és bevételeket.
- Tervek és árrés-adatok integrálása: Készíts egy Google Sheets táblázatot az ügyfélnek, ahová felvezetheti a havi marketingkeretet, a tervezett árbevételt, valamint a termékkategóriák átlagos árrését (pl. Kozmetikumok: 55%, Eszközök: 30%). Ezt a táblázatot is kapcsold hozzá a BigQuery-hez vagy közvetlenül a Looker Studiohoz.
- A Looker Studio sablon felépítése:
* Használj letisztult, sötét vagy világos, de kontrasztos designt (kerüld a rikító színeket, a kék és a szürke árnyalatai professzionális hatást keltenek).
Az első oldal tetején helyezz el 4 darab kiemelt mutató kártyát (Scorecard): Összes Költés, Tényleges Árbevétel, MER és POAS*.
* Helyezz el egy vonaldiagramot, amely a MER alakulását mutatja a célként kitűzött MER-küszöbhöz képest.
* A második oldalon jelenítsd meg a csatornánkénti bontást egy táblázatban: Google Ads vs. Meta Ads költségek, konverziók és megtérülések.
- Automatikus frissítés és cache beállítása: A Looker Studio adatforrás beállításaiban állítsd be az adatfrissítési gyakoriságot napi egyszeri (4 vagy 12 órás) frissítésre. Ez megakadályozza, hogy a riport minden megnyitásnál újra és újra lekérdezze a teljes adatbázist, ami feleslegesen növelné a BigQuery költségeit és lassítaná a betöltést.
Az átállás eredményeként az ügynökség megszabadul a manuális Excel-táblázatok vezetésétől, megszünteti a GA4 API kvótahibákat, az ügyfelek pedig egy átlátható, üzleti fókuszú, professzionális felületet kapnak. Ez nemcsak a megtartási rátát (Retention Rate) fogja drasztikusan javítani, hanem lehetővé teszi, hogy az ügynökség magasabb áron, prémium szolgáltatásként értékesítse a PPC-menedzsmentet a piacon.
