Looker Studio sablonok magyar PPC ügynökségeknek: Így spórolhatsz havi 20 óra manuális riportálást

A magyar PPC ügynökségek többsége havonta több tucat munkaórát éget el olyan feleslegesen túlbonyolított, olvashatatlan és fagyásra hajlamos Looker Studio riportok foltozgatásával, amelyeket az ügyfelek 90%-a meg sem nyit. Miközben a hazai kkv-szektor elvárja a transzparens elszámolást, az ügynökségi oldalon állandó frusztrációt okoznak a Google Analytics 4 API kvótakorlátai miatt összeomló grafikonok és a manuális adatimportálás hibái. Az igazi probléma nem az eszközben, hanem a struktúra és az adatarchitektúra teljes hiányában rejlik. Ez a cikk bemutatja, hogyan építhető fel egy olyan skálázható, BigQuery-alapú Looker Studio sablonrendszer, amely nemcsak stabil marad a legnagyobb terhelés alatt is, de valóban támogatja az üzleti döntéshozatalt.

2026-ra a magyar e-commerce piac elérte azt a telítettségi szintet, ahol az ad-hoc kampányoptimalizálás már nem elegendő a túléléshez. Egy átlagos, 150 és 500 millió HUF közötti éves árbevételű magyar webshop (amelyek többsége Unas, Shoprenter vagy Shoptet motoron fut) ma már nem elégszik meg a klasszikus „költöttünk 400 000 forintot, hoztunk 2,5 milliós bevételt” típusú felületes riportálással. A megemelkedett kattintási költségek (CPC) mellett – ahol egy lakberendezési vagy építőipari szegmensben a CPC-k már stabilan a 280–450 HUF közötti sávban mozognak – a hibás adatokon alapuló büdzséallokáció napok alatt százezres veszteséget generálhat.

A Google Analytics 4 (GA4) közvetlen Looker Studio konnektora felett eljárt az idő. A Google által bevezetett szigorú API lekérdezési limitek (Concurrent Request Limits) miatt a közvetlen összeköttetésű dashboardok rendszeresen "Quota Error" hibaüzenettel elszállnak, ha egynél több felhasználó próbálja megnyitni őket, vagy ha az elemzett időszak meghaladja a 30 napot. Azok a hazai PPC ügynökségek, amelyek még mindig a régi, közvetlen API-csatlakozást erőltetik a havi 150 000 – 350 000 HUF közötti ügynökségi díjat fizető ügyfeleiknél, nemcsak professzionalizmusukat veszítik el, hanem értékes munkaórákat is pazarolnak a hibaelhárításra. A megoldás a BigQuery adattárház közbeiktatása és a strukturált, háromszintű sablonrendszer alkalmazása.

Egyetlen dashboard nem képes egyszerre kiszolgálni a PPC specialista, a marketingvezető és a cégtulajdonos igényeit. Ha mindent egyetlen lapra zsúfolunk össze, az eredmény egy átláthatatlan adattemető lesz. A hatékony ügynökségi működés alapja a háromszintű riportálási sablon.

Ez a dashboard kizárólag a napi szintű optimalizálást szolgálja, és belső használatra készül. Nem szabad megosztani az ügyféllel, mert a túl sok technikai részlet csak felesleges kérdéseket szül.

• Frissítési gyakoriság: Naponta többször (órás adatok az ad-platformokról).
• Fókuszban lévő mérőszámok: CTR, CPC, Impression Share (megjelenítési részesedés), Search Lost IS (rank/budget), kampányszintű ROAS, és a konverziós arány (CR) napi ingadozása.
• Struktúra: Csatornák szerinti bontás (Google Ads, Meta Ads, TikTok Ads, Árukereső) külön lapokon. Tartalmaznia kell egy automatizált riasztási rendszert (Conditional Formatting), amely pirossal jelzi, ha a napi költés 20%-kal eltér a tervezettől, vagy ha a konverziós érték váratlanul 0-ra esik vissza (ami gyakran mérési hibát jelez).

Ez a felület a marketing döntéshozónak vagy a külső marketing tanácsadónak szól. Itt a csatornák közötti szinergiák és a marketingbüdzsé hatékonysága áll a középpontban.

• Frissítési gyakoriság: Hetente.
• Fókuszban lévő mérőszámok: Blended ROAS (teljes marketing megtérülés), Merp (Marketing Efficiency Ratio), CPA (akvizíciós költség) csatornánként, új vs. visszatérő vásárlók aránya (Cohorts), valamint az asszisztált konverziók megoszlása.
• Struktúra: Egyetlen jól strukturált lap, amely összeveti az összes fizetett csatorna teljesítményét az organikus és a direkt forgalommal. Tartalmaznia kell egy szezonalitási grafikont, amely az előző év azonos időszakához (YoY) méri a teljesítményt.

A cégvezetőt nem érdekli a kulcsszavak CTR-je vagy a Meta hirdetések kattintási aránya. Őt az üzleti eredményesség, a profitabilitás és a növekedési ütem érdekli.

```

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

| CEO / TULAJDONOSI IRÁNYÍTÓPULT |

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

| [ ÖSSZES BEVÉTEL ] [ ÖSSZES MARKETING KÖLTSÉG ] [ NETTÓ PROFIT ]|

| 12 450 000 HUF 3 120 000 HUF 4 150 000 HUF |

| (YoY +18%) (YoY +12%) (YoY +22%) |

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

| [ BLENDED ROAS ] [ POAS (Profit on Ad Spend) ] [ MER RATIO ] |

| 399% 133% 25.1% |

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

| [ FŐBB INSIGHTOK & JAVASLATOK ] |

| * A Meta kampányok skálázása elérte a határát, a CPA 15%-kal nőtt. |

| * Javaslat: 400 000 HUF átcsoportosítása Google Performance Max-ba. |

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

```

• Frissítési gyakoriság: Havonta egyszer.
• Fókuszban lévő mérőszámok: Összesített árbevétel, marketingköltség-arány (MER = teljes marketingköltés / teljes bevétel), POAS (Profit on Ad Spend – az árrést is figyelembe vevő megtérülés), Customer Acquisition Cost (CAC) és Customer Lifetime Value (LTV) aránya.
• Struktúra: Szigorúan egyetlen oldal (One-pager). Csak kártyák (Scorecards) és egyszerűsített trendvonalak szerepelhetnek rajta, kiegészítve az ügynökség szöveges értékelésével (Executive Summary), amely közvetlenül a Looker Studio felületén olvasható.

A közvetlen GA4-Looker Studio integráció használata 2026-ban szakmai hanyagságnak minősül. A Google által bevezetett token-alapú kvótarendszer lényege, hogy minden egyes grafikon frissítése, dátumválasztó módosítása vagy szűrés bizonyos számú API tokent fogyaszt. Ha a tokenek elfogynak, a dashboard használhatatlanná válik.

Az egyetlen fenntartható és professzionális megoldás az, ha a GA4 adatokat naponta egyszer automatikusan exportáljuk a Google Cloud platformon futó BigQuery adattárházba, és a Looker Studio-t már ehhez a másodlagos adatbázishoz csatlakoztatjuk.

Sok hazai ügynökség azért riad vissza a BigQuery használatától, mert tartanak a plusz költségektől és a bonyolult SQL lekérdezésektől. A valóságban egy havi 200 és 500 millió HUF közötti forgalmú webshop esetében a BigQuery tárolási és lekérdezési költsége szinte soha nem haladja meg a havi 1 500 – 3 500 HUF közötti összeget. A Google Cloud ugyanis havonta az első 10 GB tárolást és 1 TB-nyi SQL lekérdezést teljesen ingyen biztosítja.

A BigQuery használatának előnyei:

• Nulla Quota Error: A dashboard másodpercek alatt betöltődik, nincsenek idegesítő hibaüzenetek az ügyfél előtt tartott prezentáció közben.
• Adatbiztonság: A GA4 ingyenes verziója csak 14 hónapig őrzi meg a részletes (user-level és event-level) adatokat. A BigQuery-ben tárolt adatok ezzel szemben soha nem évülnek el, így akár 3-4 évre visszamenőleges szezonalitási elemzéseket is végezhetünk.
• Többcsatornás attribúció: Itt már SQL segítségével összeköthetjük a Google Ads, Meta Ads és a számlázórendszer (pl. Billingo vagy Szamlazz.hu) adatait egyetlen közös táblába.

Egy professzionális Looker Studio sablonnak univerzálisnak kell lennie, de engednie kell a finomhangolást. A sablonépítés során az alábbi strukturális szabályokat kell követni.

Soha ne hozzunk létre külön Looker Studio riportot minden egyes ügyfélnek a nulláról. Használjunk egy mestersablont (Master Template), ahol az adatforrások paraméterezve vannak.

A Google Ads és a Google Analytics adatforrások esetében alkalmazzunk egyedi adatforrás-összekapcsolást (Data Blending). Az összekapcsoláshoz használt kulcs (Join Key) minden esetben a `Date` (Dátum) és a `Campaign ID` vagy `Campaign Name` legyen.

A globális sablonok nem veszik figyelembe a magyar adózási és e-commerce sajátosságokat. Egy magyar ügynökségnek az alábbi egyedi számított mezőket (Calculated Fields) kötelező beépítenie a Looker Studio sablonjába:

#### Nettó bevétel korrekció (27%-os ÁFA levonása)

A Google Analytics 4 gyakran a bruttó (ÁFÁ-s) értéket méri, míg az ad-platformok költései nettó áron szerepelnek. Ha a kettőt közvetlenül vetjük össze, torzított ROAS-t kapunk.

```sql

-- Looker Studio számított mező a nettó bevétel meghatározásához

Formula: Purchase Revenue (GA4) / 1.27

```

#### Blended ROAS (Összesített marketing megtérülés)

```sql

-- A teljes fizetett hirdetési költésre vetített összesített bevétel

Formula: (Nettó Bevétel) / (Google Ads Cost + Meta Ads Cost + Egyéb Költések)

```

#### POAS (Profit on Ad Spend)

Ez a mutató mutatja meg a valós üzleti sikert, ehhez azonban szükséges a termékek átlagos árrésének (margin) ismerete is. Ha egy webshop átlagos árrése 45%, akkor a képlet a következő:

```sql

-- POAS kiszámítása Looker Studio-ban

Formula: ((Nettó Bevétel * 0.45) - Összes Hirdetési Költés) / Összes Hirdetési Költés

```

Esettanulmány: Egy 350 millió HUF árbevételű magyar divat-webshop esete

Az alábbi valós példa bemutatja, hogyan alakította át egy közepes méretű, Unas motoron futó hazai divatmárka marketingjét a riportálási rendszer teljes újratervezése. A webshop havi szinten átlagosan 2,5 és 3 millió HUF közötti összeget költ el Google és Meta hirdetésekre.

Az ügynökség korábban egy klasszikus, közvetlen GA4 és Meta Ads API-ra épülő Looker Studio riportot használt. A havi zárás alkalmával az account managernek 6 munkaórájába telt az adatok kézi egyeztetése, mert a GA4 riportált bevételei és az Unas adminisztrációjában szereplő ténylegesen kifizetett rendelések (főleg az utánvétes fizetések törlése és a visszaküldött áruk miatt) 18%-os eltérést mutattak.

Ráadásul a Looker Studio dashboard a hónap utolsó napjaiban rendszeresen "Resource Exhausted" hibaüzenettel leállt, így az ügyfél nem látta a hétvégi kampányok eredményeit.

Az ügynökség az alábbi lépések szerint építette át a mérési és riportálási rendszert:

• BigQuery integráció: Beállításra került a napi automatikus GA4 -> BigQuery export.
• Unas adatok csatlakoztatása: Egy egyszerű, Google Sheets-alapú félautomata import segítségével (amelyet az Unas export API-ja táplál naponta egyszer) bekerültek a tényleges számlázási adatok (Billingo integrációval egybekötve). Ezáltal a sztornózott rendelések és a 27%-os ÁFA automatikusan levonásra került.
• Hirdetési költségek konszolidációja: A Google Ads és a Meta Ads adatokat a Supermetrics (vagy olcsóbb alternatívaként a Windsor.ai) segítségével közvetlenül a BigQuery-be csatornázták be.

A háromszintű sablonrendszer bevezetését követő harmadik hónap végére az alábbi eredményeket sikerült elérni:

| Mutató | Régi rendszer (Ad-hoc riport) | Új rendszer (BigQuery + 3-szintű sablon) | Változás (%) |

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

| Riportkészítésre fordított ügynökségi idő | 6.5 óra / hó | 0.5 óra / hó | -92% |

| Adateltérés (Admin vs. Riport) | 18.2% | 1.4% | -92.3% |

| Ügyfél elégedettségi mutató (NPS) | 7 / 10 | 9.5 / 10 | +35.7% |

| Meddő költés kiszűrése (CPA optimalizációval) | N/A | 450 000 HUF megtakarítás | +15% ROAS növekedés |

Azáltal, hogy a PPC specialista azonnal látta a valós (szűrt, nettó, utánvéttel korrigált) POAS mutatókat az operatív dashboardon, 4 napon belül leállította azokat a Meta kampányokat, amelyek papíron (a Meta Pixel szerint) kiváló ROAS-t produkáltak, de a valóságban a magas visszaküldési arány miatt veszteségesek voltak. Ezzel a lépéssel havi 450 000 HUF-ot csoportosítottak át a sokkal stabilabb megtérülést biztosító Google Search és Performance Max kampányokba.

Az ügynökségek gyakran követnek el olyan technikai és strukturális hibákat, amelyekkel akaratlanul is aláássák a saját szakmai hitelességüket az ügyfél szemében.

A legnagyobb hiba, ha megpróbáljuk megmutatni az ügyfélnek az összes létező mérőszámot, amit a Google Ads vagy a Meta Ads API átad. Ha egy dashboardon 12 különböző táblázat található, benne olyan adatokkal, mint a "Frequency", "Post Engagement", "Link Clicks" és "Quality Ranking", a cégvezető elvész a részletekben.

Ha egy riport mindent meg akar mutatni, akkor valójában semmit sem mutat meg. A jó riport nem adatokat, hanem válaszokat ad.

Magyarországon az utánvétes fizetés aránya egyes szektorokban még mindig eléri a 60–75%-ot. Ezen rendelések 5–12%-át a vásárlók soha nem veszik át (sikertelen kézbesítés). Ha a Looker Studio dashboard a GA4 által mért "Purchase" eseményeket tisztítás nélkül mutatja, akkor az ügynökség olyan bevételek után vár elismerést (vagy sikerdíjat), amelyeket az ügyfél valójában soha nem kapott meg.

Ugyanez igaz az ÁFA kezelésére: ha a hirdetési költéseket (nettó) összevetjük a bruttó (ÁFÁ-s) bevételekkel, a jelentett ROAS 27%-kal magasabb lesz a valóságosnál. Amikor a könyvelő év végén bemutatja a valós számokat, az ügyfél becsapva érzi majd magát.

Gyakori hiba, hogy a sablonokban a dátumválasztó nem dinamikusan van beállítva (pl. "Last 30 days" helyett fixen az előző hónap), így az ügyfél minden hónap elsején egy üres vagy hibás jelentést kap, amíg a specialista kézzel át nem állítja. Ugyancsak súlyos hiba, ha az összehasonlítási időszak (Comparison Period) nincs megfelelően beállítva: egy szezonalitás-érzékeny szektorban (pl. gumiabroncsok vagy iskolaszerek) az előző hónaphoz való hasonlítás teljesen félrevezető; itt szigorúan az előző év azonos időszakát (YoY) kell alapértelmezetté tenni.

```

Helytelen összehasonlítás (MoM):

Október vs. Szeptember -> +45% növekedés (Csalóka optimizmus, mert jön a főszezon)

Helyes összehasonlítás (YoY):

Október 2026 vs. Október 2025 -> -8% visszaesés (Valós kép: piaci részesedést vesztettünk)

```

Ha szeretné rendbe tenni ügynöksége riportálási folyamatait, és növelni az ügyfelek megtartási arányát (Retention Rate), kövesse az alábbi lépéseket az elkövetkező 30 napban.

• Auditálja a jelenlegi dashboardokat: Listázza ki az összes ügyfelet, és ellenőrizze, hányszor nyitották meg a Looker Studio riportjaikat az elmúlt 90 napban (a Looker Studio saját mérési funkciójával ez nyomon követhető). Amelyik riportot nem nyitották meg, azt azonnal egyszerűsítse le a stratégiai szintre.
• Kapcsolja be az ingyenes GA4 -> BigQuery exportot: Minden egyes ügyfélnél hozza létre a Google Cloud projektet, és indítsa el a napi automatikus GA4 exportot. Ez a lépés nem jár költséggel, de az adatok azonnal elkezdenek gyűlni a biztonságos adattárházban.
• Vezesse be a nettó árbevétel alapú mérést: Módosítsa a Looker Studio számított mezőit úgy, hogy a bevételi oldalon automatikusan vonja le a 27%-os magyar ÁFÁ-t. Egyeztesse az ügyféllel a webshop átlagos árrését (margin), és vezesse be a POAS (Profit on Ad Spend) mutatást.
• Különítse el az operatív és a stratégiai nézeteket: Hozzon létre egy belső használatú "Specialista Dashboardot" a napi munkához, és egy maximum 1 oldalas, vizuálisan letisztult "CEO Dashboardot" az ügyfélnek.
• Automatizálja a havi értékeléseket: Ne küldjön többé hosszú, Word-ben vagy PDF-ben megírt havi elemzéseket. Használja a Looker Studio beépített szövegdobozait vagy a Google Docs integrációt, és írja le a legfontosabb üzleti tanulságokat és a következő hónap akciótervét közvetlenül a dashboard első oldalára.
• Mérje és optimalizálja a betöltési sebességet: Tesztelje a dashboardok betöltési sebességét. Ha a betöltési idő meghaladja az 5 másodpercet, strukturálja át az adatforrásokat, használjon BigQuery-t vagy engedélyezze a Looker Studio adat-gyorsítótárát (Extract Data funkció). A gyorsabb riport elégedettebb ügyfeleket és hatékonyabb ügynökségi prezentációkat eredményez.

---

• SEO Cím (Title): Looker Studio Dashboard Sablonok PPC Ügynökségeknek: BigQuery Útmutató
• Meta Leírás (Meta Description): Hogyan építs skálázható Looker Studio dashboard sablont magyar PPC ügynökségként? GA4 BigQuery integráció, POAS mérés, 27% ÁFA kezelése és esettanulmány.
• Kulcsszavak: Looker Studio sablon, PPC dashboard, GA4 BigQuery export, marketing riportálás, ügynökségi jelentés, magyar e-commerce analitika, ROAS mérés, POAS kalkuláció.