A magyar PPC ügynökségek jelentős része havonta átlagosan 12-18 munkaórát pazarol el olyan Looker Studio dashboardok foltozgatására, amelyeket az ügyfelek meg sem nyitnak, vagy ha mégis, a hibás GA4-kvóták és a platformok közötti adateltérések miatt téves következtetéseket vonnak le belőlük. Miközben az ügynökség senior elemzője – akinek az óradíja piaci alapon 22 000 és 35 000 HUF + ÁFA között mozog – manuálisan frissítgeti a Google Sheets-be behúzott Meta Ads adatokat, az ügyfél egyetlen kérdésre várja a választ: pontosan hány forint tiszta profitot termelt a marketing az elmúlt harminc napban. Ez a szakadék a technikai riportálás és az üzleti döntéshozatal között rendszeresen feszültséget szül, amely végső soron az ügynökségi ügyfélmegtartási ráta (churn rate) romlásához vezet. A megoldás nem a még több diagram ábrázolásában, hanem egy olyan háromszintű, BigQuery-alapú riporting-architektúra felépítésében rejlik, amely kiküszöböli a technikai hibákat és közvetlenül az üzleti eredményességre fókuszál.
Miért fontos ez most
A hazai e-commerce és PPC piac gyökeres változásokon megy keresztül, ahol a korábbi, kizárólag a platformok által jelentett ROAS-ra épülő optimalizálás teljesen elveszítette a hitelességét. A Meta és a Google Ads CPC (kattintásonkénti költség) árai a kompetitív hazai szektorokban – mint például a lakberendezés (110–180 HUF), a divat (40–85 HUF) vagy a pénzügyi szolgáltatások (450–1200 HUF) – az elmúlt két évben átlagosan 28%-kal emelkedtek. Ebben a környezetben egy 150 000 és 500 000 HUF közötti havi fix díjon dolgozó ügynökség nem engedheti meg magának azt a luxust, hogy értékes munkaerőt pazaroljon manuális adatmásolásra vagy a folyamatosan széteső API-konnektorok hibaelhárítására.
Ezzel párhuzamosan a Google Analytics 4 (GA4) API-kvótakorlátai, amelyeket a Google rendszeresen szigorít, gyakorlatilag használhatatlanná teszik a közvetlen GA4–Looker Studio összeköttetést a nagyobb látogatottságú (havi 100 000+ munkamenet) webáruházak esetében. A "Quota Error" hibaüzenet megjelenése a kliens előtt nemcsak amatőr hatást kelt, hanem teljesen blokkolja a napi szintű döntéshozatalt is. Ráadásul a külső konnektorok (mint a Supermetrics, Porter Metrics vagy Power My Analytics) licencdíjai drasztikusan megdrágultak: egy 25 ügyfelet kiszolgáló ügynökség havi szinten könnyen szembesülhet 120 000–180 000 HUF közötti szoftverköltséggel csak azért, hogy az adatok eljussanak a felületre. A technológiai és gazdasági nyomás miatt elengedhetetlenné vált a riporting folyamatok automatizálása és olcsóbb, stabilabb alapokra helyezése.
A háromszintű dashboard-architektúra felépítése
A sikeres ügynökségi riportálás alapja a megfelelő szintű információ eljuttatása a megfelelő döntéshozóhoz. Nem szabad ugyanazt a dashboardot mutatni a webshop tulajdonosának, mint amit a PPC kampánymenedzser használ a mindennapi optimalizáláshoz.
1. szint: A C-Level stratégiai nézet (A 10 másodperces teszt)
A cégvezetőknek és marketingvezetőknek szóló felületnek mindössze egyetlen oldalból kell állnia, amely azonnal választ ad a vállalkozás pénzügyi egészségére. Itt nincsen helye kampányszintű kattintási aránynak (CTR) vagy minőségi pontszámoknak. A fókusz a globális üzleti mutatókon van:
- Marketing Efficiency Ratio (MER): Az összes marketingköltség és az összes nettó árbevétel aránya. (Képlet: `Összes PPC Költség / Nettó Árbevétel`). Ha ez a mutató 15% felett van egy tipikus 200M–500M HUF árbevételű magyar webshopnál, a profitabilitás veszélybe kerülhet.
- Profit on Ad Spend (POAS): A bruttó árrés és a hirdetési költség aránya. Ez a mutató közvetlenül az ERP rendszerekből (pl. Billingo, Számlázz.hu API-kon keresztül vagy Google Sheets importtal) származó termékszintű árréssel számol, nem a kosárértékkel.
- Blended CAC (Ügyfélszerzési költség): Az összes hirdetési kiadás osztva az új vásárlók számával.
A vizualizáció során kizárólag scorecardokat (mutatókártyákat) és egyszerű, idősoros trendvonalakat használunk, amelyek megmutatják az előző év azonos időszakához (YoY) mért változásokat.
2. szint: Az operatív PPC dashboard (A kampánymenedzser fegyvere)
Ez a felület az ügynökségi szakember belső munkaeszköze, amelyet az ügyfélnek nem is kell látnia, vagy csak "read-only" módban, ha kifejezetten igényli a transzparenciát. Ez a lap tartalmazza a csatornaspecifikus mélyfúrásokat:
- Google Ads teljesítmény: PMax kampányok eszközcsoportjainak megoszlása, kulcsszavak keresési kifejezés jelentései, és a költségkeret miatti megjelenítés-veszteség (Search Lost IS budget).
- Meta Ads kreatív tesztelés: Hirdetésenkénti videómegtekintési arányok (3-second video view rate), kimenő kattintási arány (Outbound CTR) és az adset szintű frekvencia figyelése a célzási fáradás elkerülésére.
- Csatornák közötti átfedések: Annak ábrázolása, hogy a Google Search és a Meta remarketing kampányok milyen arányban támogatják egymást a konverziós útvonalon.
3. szint: Kohorsz és LTV dashboard (A növekedési fázis)
Amikor egy hazai e-commerce szereplő átlépi az éves 300M HUF árbevételt, a növekedés motorjává a visszatérő vásárlók válnak. Ez a dashboard az első vásárlás időpontja alapján csoportosítja a vevőket, és megmutatja a Customer Lifetime Value (LTV) alakulását 30, 60 és 90 napos távlatban.
A Looker Studio-ban ez a kohorsz-táblázatok segítségével ábrázolható, ahol a sorok a bázishónapot, az oszlopok pedig az azóta eltelt hónapokat mutatják. Ezzel az ügynökség bizonyítani tudja, hogy a megszerzett vásárlók hosszú távon is profitot termelnek, így legitimálható a magasabb kezdeti CPA (akvizíciós költség) elfogadása is a hirdetéseknél.
| Kohorsz Hónap | Vásárlók Száma | Hónap 0 (HUF) | Hónap 1 (HUF) | Hónap 2 (HUF) | LTV Változás (%) |
| :--- | :--- | :--- | :--- | :--- | :--- |
| 2025. Január | 1,240 | 14,200 | 2,800 | 1,900 | +33.1% |
| 2025. Február | 1,450 | 13,800 | 3,100 | 2,100 | +37.6% |
| 2025. Március| 1,180 | 14,500 | 2,900 | 1,850 | +32.7% |
A GA4-BigQuery híd építése a kvótahibák ellen
A közvetlen GA4 konnektor használata Looker Studio-ban ma már technológiai öngyilkosság egy komolyabb ügynökség számára. Amikor egy dashboardon több mint 5-6 diagram található, és a felhasználó szűri a dátumtartományt vagy a kampánytípusokat, a Google API-tokeneket fogyaszt. Ha a napi limitet (ami standard fiókoknál rendkívül alacsony) túllépjük, a grafikonok helyén szürke hibaüzenetek jelennek meg.
A megoldás a Google Cloud Platform (GCP) által kínált ingyenes GA4-BigQuery export aktiválása. A BigQuery-be érkező adatok strukturált SQL táblákban tárolódnak. A Looker Studio közvetlenül, villámgyorsan és kvótakorlátok nélkül képes lekérdezni a BigQuery adatbázisokat.
A folyamat lépései a következők:
- A Google Cloud Console-ban létre kell hozni egy projektet, majd a GA4 admin felületén összekapcsolni a BigQuery-vel (napi egyszeri export ingyenes).
- A BigQuery-ben futtatni kell egy ütemezett lekérdezést (Scheduled Query), amely összesíti a napi szintű munkameneteket, tranzakciókat és bevételeket egy külön, optimalizált táblába. Ezáltal nem a több gigabájtos nyers eseménytáblát kérdezzük le minden megnyitáskor, így a GCP költségek havi 500 HUF alatt tarthatók.
- A Looker Studio-ban a natív BigQuery konnektort választjuk ki a GA4 helyett. Az eredmény: azonnali betöltődés, nulla hibaüzenet, és tetszőlegesen komplex kalkulált mezők használata.
Esettanulmány: Hogyan mentett meg egy 250M HUF-os lakberendezési webshopot a POAS-alapú riporting?
Egy hazai, egyedi bútorokat és kiegészítőket értékesítő, Unas platformon futó webáruház havi 2,8 millió HUF hirdetési költségvetéssel dolgozott (1,8 millió Google Ads, 1,0 millió Meta Ads). Az ügynökség korábbi dashboardja a platformok saját pixeljeire hagyatkozott.

A kiinduló helyzet és a platformok torzítása
A Meta Ads Manager 6,2-es ROAS-t mutatott (6,2 millió HUF jelentett konverziós érték), míg a Google Ads Performance Max kampányai 5,8-as ROAS-t jeleztek (10,44 millió HUF jelentett érték). A két hirdetési fiók összesen 16,64 millió HUF bevételt tulajdonított magának.
Ezzel szemben a webáruház valós, számlázott havi nettó árbevétele az adott időszakban mindössze 11,2 millió HUF volt. Az eltérést két tényező okozta:
- Attribúciós átfedés: A vásárlók 42%-a mindkét hirdetéssel találkozott az 5 napos konverziós ablakban, így mindkét rendszer teljes értéken könyvelte el a vásárlást.
- Lemondások és visszáruk: A bútor szegmensben a kosárértékek magasak (átlagosan 85 000 HUF), de a megrendelések 14%-át a vásárlók törölték a szállítás előtt, vagy éltek a 14 napos elállási joggal. A Meta és Google pixelek ezt a kiesést soha nem tudták meg, így "szellembevételekre" optimalizáltak.
Az új mérési modell és a Looker Studio megoldás
Az ügynökség lecserélte a hagyományos dashboardot egy olyan egyedi felületre, amely a következő integrációt használta:
- A hirdetési költségeket API-n keresztül gyűjtöttük össze egy Google Sheets táblázatba (napi bontásban csatornánként).
- Az Unas-ból a ténylegesen kiszállított és kifizetett rendeléseket (státuszkód alapján szűrve) óránként szinkronizáltuk egy másik táblába a Billingo számlázási adatokkal összevetve.
- A két adatforrást a Looker Studio-ban a `Tranzakció ID` alapján kötöttük össze, a termékek valós beszerzési árait is beépítve a kalkulációba.
```
[Unas / Billingo (Valós, kifizetett megrendelések)] ──┐
├─> [Google BigQuery] ─> [Looker Studio POAS Dashboard]
[Google & Meta API (Valós hirdetési költségek)] ─────┘
```
Az eredmények számokban
Az új dashboard azonnal rávilágított a rideg valóságra: a platformok által vizionált 5,9-es átlagos ROAS helyett a valódi, üzleti profitra vetített POAS mindössze 1,12 volt. Ez azt jelentette, hogy a hirdetések éppen csak kitermelték a saját költségüket és a termék önköltségét, de a cég fix működési kiadásaira (raktár, ügyfélszolgálat, logisztika) már nem maradt fedezet.
Az ügynökség a dashboard adatai alapján azonnal beavatkozott:
- Lekapcsolták azokat a PMax kampányokat, amelyek alacsony árrésű (20% alatti) tömegtermékeket értékesítettek, hiába mutattak magas ROAS-t a Google felületén.
- A hirdetési büdzsét átcsoportosították a magas árrésű (55%+), saját gyártású termékekre.
- A Meta Ads-nél a konverziós ablakot 7 napos kattintásról 1 napos kattintásra szűkítették, hogy csökkentsák a Google-lal való átfedést.
Bár a havi hirdetési költés 2,8 millió HUF-ról 2,1 millió HUF-ra csökkent, a webáruház havi nettó üzleti eredménye (adózott profitja) -250 000 HUF veszteségből +1 450 000 HUF tiszta nyereségbe fordult át három hónapon belül. Az ügynökség pedig bebizonyította, hogy nemcsak "kattintásokat terel", hanem a cég pénzügyi túlélését és növekedését biztosítja.
Kritikus hibák, amiket a magyar ügynökségek elkövetnek
A dashboard-építés során elkövetett hibák többsége nem dizájn-, hanem módszertani és matematikai jellegű. Ezek a hibák közvetlenül torzítják a döntéshozatalt.
1. Bruttó és nettó adatok keverése
A leggyakoribb hiba, amikor a Looker Studio-ban a hirdetési rendszerek nettó költségeit (mivel a Google és Meta számlák áfa-mentesek az EU-s adószám miatt) közvetlenül vetítik össze a webshopok bruttó (27%-os magyar áfával növelt) bevételeivel. Ez a hiba azonnal 27%-os torzítást visz a rendszerbe, mesterségesen felfújva a látszólagos hatékonyságot. A dashboardon minden bevételi forrást kötelezően nettósítani kell a következő kalkulált mező segítségével:
`Nettó Bevétel = Bruttó Bevétel / 1.27`
2. Valutaváltási és deviza-anomáliák
Sok magyar vállalkozás euróban fizeti a Meta hirdetéseket, míg a bevételei forintban keletkeznek. Ha a Looker Studio dashboardon egy fix, statikus átváltási árfolyammal számolunk (például 390 HUF/EUR), az komoly pontatlanságokhoz vezet az árfolyam-ingadozások idején.
Ha egy ügynökség havi 15 000 EUR-t költ el Meta hirdetésekre, egy 15 forintos árfolyam-elmozdulás már 225 000 HUF mérési hibát eredményez. Megoldásként egy olyan dinamikus Google Sheets táblát kell segédadatforrásként bevonni, amely napi szinten frissíti az MNB hivatalos középárfolyamát, és ezt használja a hirdetési költségek forintra váltásához a blended táblázatokban.
3. A "Karácsonyfa-effektus" (Data Vomit)
A marketingesek hajlamosak azt hinni, hogy a bonyolult, 50-féle grafikont tartalmazó, villogó piros és zöld KPI-kártyákkal teleszórt dashboard professzionalizmust sugároz. A valóságban ez csak frusztrációt okoz az ügyfélben. Ha a dashboard betöltése 20 másodpercnél tovább tart az adatforrások rossz strukturáltsága miatt, a felhasználó be fogja zárni.
Minden felesleges diagramot (például az eszközök szerinti megoszlást kördiagramon ábrázolva, miközben a mobil aránya mindenhol 90% feletti) kíméletlenül el kell távolítani. Ha egy adat nem vezet közvetlen üzleti döntéshez vagy kampánymódosításhoz, annak nincs helye a képernyőn.
Akcióterv: Így építsd fel a sablonodat a következő 14 napban
Az alábbi lépések végrehajtásával egy olyan robusztus, skálázható és hibatűrő riporting rendszert hozhatsz létre, amelyet bármelyik új ügyfelednél 60 percen belül üzembe helyezhetsz.
- Auditáld a jelenlegi konnektor-költségeidet: Írd össze, hány dollárt fizet az ügynökség havonta a harmadik felektől származó konnektorokra. Határozd meg a célul ezek kiváltását ingyenes GCP/BigQuery alapú megoldásokkal, amivel azonnal havi 50 000–150 000 HUF-ot takaríthatsz meg az ügynökségi büdzsében.
- Kapcsold be a GA4-BigQuery exportot: Minden meglévő és új ügyfélnél az első napon aktiváld a Google Cloud kapcsolatot. Az adatok gyűjtését azonnal meg kell kezdeni, mert a BigQuery nem visszamenőleges hatályú.
- Hozd létre a standardizált Google Sheets sémát a "nem API" adatoknak: Készíts egy sablon táblázatot, ahová az ügyfelek vagy a fiókkezelők beírhatják a havi szintű egyéb kiadásokat (ügynökségi díj, fotózási költségek, influencer kampányok díjai, tárhelydíjak). Ez szükséges a valódi MER és ROI számításához.
- Építsd meg az "Arany Sablont" Looker Studio-ban: Hozz létre egy master dashboardot, amely 3 különálló lapból áll (C-Level, Operatív PPC, Kohorszelemzés). Használj neutrális színeket (pl. sötétszürke és kék árnyalatok), hogy az ügyfelek logói ne ütközzenek a dizájnnal.
- Implementáld a nettó-bruttó korrekciót és a devizaváltó formulát: Építsd be a kalkulált mezőket a master sablonba, hogy a forintosítás és az áfalevonás automatikusan megtörténjen az adatforrások összekapcsolásakor.
- Optimalizáld a betöltési sebességet adatkinyeréssel (Extract Data): A lassú lekérdezések elkerülése érdekében a nem valós idejű adatokat igénylő grafikonoknál használd a Looker Studio saját "Extract Data" (Adatkinyerés) konnektorát. Ez napi egyszer frissíti a gyorsítótárat, így a dashboard 2 másodpercen belül be fog tölteni.
- Vezesd be a havi 15 perces "Dashboard-Audit" rutint: Ahelyett, hogy órákat töltenél PDF riportok írásával, minden hónap elején küldj egy 3 mondatos kísérő videót (Loom vagy Vidyard segítségével) az ügyfélnek, ahol a Looker Studio dashboard C-szintű nézetét mutatod be, kiemelve a MER és a POAS változását, valamint a következő hónap 3 legfontosabb operatív feladatát.
---
SEO Cím: Looker Studio Dashboard Sablonok PPC Ügynökségeknek: Profit-Alapú Riporting GA4 és BigQuery Alapon
Meta leírás: Ismerd meg, hogyan építhetsz olyan Looker Studio dashboard sablont magyar PPC ügynökségként, amely kiküszöböli a GA4 kvótahibákat, kezeli a valutaváltási anomáliákat, és valódi üzleti profitot (POAS) mutat az ügyfeleidnek. Konkrét hazai esettanulmánnyal és SQL-alapú tippekkel.




