Martech stack: B2B rétegek, példastackek és audit

A martech stack azoknak az eszközöknek az összessége, amelyeket egy marketingcsapat adatgyűjtésre, a vásárlók elérésére, a weboldal működtetésére és az eredmények mérésére használ. A „marketingtechnológiai stack” kifejezés azt sugallja, hogy megtervezték. A legtöbb B2B cégnél azonban felhalmozódott: egy az értékesítés által választott CRM, egy egykori marketingvezető által választott automatizációs eszköz, és három analitikai eszköz, amelyekben senki sem bízik teljesen.

A kínálat óriási. Scott Brinker éves Marketing Technology Landscape felmérése 2026-ban 15 505 martech terméket számolt (chiefmartec, 2026), szemben az előző évi 15 384-gyel, amit Brinker gyakorlatilag stagnálásnak nevez. Közben a csapatok által már megvásárolt eszközök kihasználatlanok: a Gartner 405 marketingvezető körében végzett felmérése szerint a martech stack képességeinek átlagos kihasználtsága 2023-ban 33%-ra esett a 2022-es 42%-ról (Gartner, 2023). A probléma ritkán egy hiányzó eszköz. Sokkal inkább a tisztázatlan rétegek, a tisztázatlan felelősök és a nem áramló adatok.

Alább: a B2B martech stack rétegei, példastackek három cégszakaszban, hogyan mozogjanak az adatok közöttük, hol a helye a weboldal-személyre szabásnak, és egy hatlépéses audit, amelyet a következő megújítás előtt lefuttathatsz.

A B2B martech stack kilenc rétege

Rétegekben gondolkodj, ne logókban. Minden rétegnek egy feladata van. Ha két eszköz ugyanazt a feladatot végzi, átfedésed van; ha egy feladatot egyik sem végez, hiányod.

Két megjegyzés. Először: sok termék több réteget is lefed: a HubSpot a CRM-et, az automatizációt és némi analitikát; az Apollo az adatbővítést és a sales engagementet. Ez rendben van, ha eldöntöd, melyik termék a gazdája az egyes feladatoknak. Másodszor: a hozzájárulás a táblázat alján van, de az adatfolyam tetején. Ha a hozzájárulás hibás, minden további réteg örökli a problémát.

Példa stackek három cégfázisban

A megfelelő stack kevésbé függ a létszámtól, mint attól, hány csatornát aktiválsz, és van-e valaki, aki karbantartja az adatokat. Ezek példák arra, hogyan épülnek egymásra a rétegek, nem bevásárlólisták vagy felmérési eredmények.

Véleményünk: a növekedési szakaszban a leggyakoribb hiba a nagyvállalati rétegek túl korai megvásárlása, különösen egy CDP-é. Egy CDP akkor hozza vissza az árát, ha több aktivációs csatornád van, amelyeknek mind ugyanarra az egységes profilra van szükségük, és van valaki, akinek a feladata az identitásszabályok karbantartása. Addig egy tiszta CRM és közvetlen integrációk kevesebb mozgó alkatrésszel elvégzik a feladatot.

Hogyan áramoljanak az adatok a rétegek között

A legtöbb stackprobléma valójában adatfolyam-probléma. Minden fontos adatobjektumnál írd le, hol jön létre, hol tárolódik és hol használják. Egy egyszerű táblázat elég.

Két szabály teszi ezt kezelhetővé. Egy: minden objektumnak pontosan egy elsődleges nyilvántartó rendszere van, és minden más abból olvas. Kettő: az eszközöket a központhoz (CRM vagy adattárház) kösd, ne egymáshoz. Egy olyan lánc, ahol az A eszköz a Zapieren keresztül elindítja a B-t, amely frissíti a C-t, amely visszaír az A-ba, éppen az a felállás, amely csendben elromlik, és csak hetekkel később veszik észre, amikor egy riport furcsán néz ki. Kifejezetten a CRM-oldalról lásd a weboldal-személyre szabási adatok CRM-hez kapcsolásáról szóló útmutatónkat.

Hol illeszkedik a weboldal-perszonalizáció

A személyre szabás egy aktivációs réteg. Nem sok új adatot hoz létre; az azonosításból, a CRM-ből, a kampányparaméterekből és a viselkedésből származó adatokat használja fel, és megváltoztatja, mit lát a látogató. Ennek két következménye van.

• A minőségét az alatta lévő rétegek korlátozzák. Ha a CRM iparág mezője a fiókok felénél üres, az iparági személyre szabás a fiókok felénél kudarcot vall. Előbb javítsd ki a mezőt, és csak utána vedd meg az eszközt.
• Vissza kell írnia. Hogy a látogató melyik szegmensben volt, és melyik variánst látta, az az analitikába, fiókszinten pedig a CRM-be tartozik, hogy az értékesítés és az attribúció is használhassa. A személyre szabott weboldalak attribúciójáról szóló cikkünk elmagyarázza, miért.

A hasznos B2B weboldal-személyre szabás minimális bemenetei: cégazonosítás (lásd a weboldal-látogató-azonosító szoftverekről szóló összefoglalónkat), következetes kampánycímkézés és olvasási hozzáférés néhány CRM-mezőhöz, például a fiók szintjéhez és az ügylet szakaszához.

Hogyan auditáld a martech stackedet hat lépésben

Ezt évente egyszer futtasd le, vagy minden új vásárlás előtt. Egy közös táblázatban csináld, eszközönként egy sorral, így az alábbi oszlopok adják az audit eredményét.

1. Leltár. Írd össze az összes eszközt, amelyhez van belépés vagy amelynek van tagje az oldalon, beleértve az ingyeneseket és a céges kártyáról fizetetteket is. Nézd át a tag managert és a böngésző hálózati fülét a kezdőlapon: olyan tageket is találsz majd, amelyek hozzáadására senki sem emlékszik.
2. Felelős. Minden eszközhöz rendelj egy megnevezett felelőst. Egy felelős nélküli eszközt senki sem tart karban, és általában éppen az szivárogtat adatot vagy pénzt.
3. Költség. Rögzítsd az éves költséget, a szerződés lejárati dátumát és a felmondási időt. A megújítási dátumokat tedd be egy naptárba.
4. Használat. Minden eszköznél jegyezd fel, mely funkciókat használod ténylegesen, és hány licenc volt aktív az elmúlt 30 napban. Sok szállító megmutatja az utolsó bejelentkezés adatait az adminbeállításokban; ha nem, kérdezd meg az ügyfélmenedzsert a megújítás előtt.
5. Átfedés. Rendeld hozzá az egyes eszközöket a fenti kilenc réteghez. Minden réteg, ahol két vagy több eszköz végzi ugyanazt a feladatot, összevonási jelölt. A klasszikus eset a leadpontozás három helyen.
6. Integráció. Minden eszköznél rögzítsd, honnan olvas és hová ír. Jelöld meg a kézi CSV-exportokat és a hibás szinkronokat. Ezek a legnagyobb értékű javításaid.

Példa (szemléltető auditeredmény egy hipotetikus, 60 fős szoftvercégre):

Ebben a példában két eszköz megszüntetése évi 6000 € megtakarítást hoz, amiből finanszírozható a 6. lépésben jelzett integrációs munka. Ha azt szeretnéd megítélni, hogy egy új eszköz megtérülne-e, a demó előtt – ne utána – futtasd le a számokat egy marketing ROI kalkulátoron.

Mennyit költs martechre?

Nincs helyes szám. Viszonyításként: a Gartner 2025-ös CMO Spend Survey felmérése szerint a marketingköltségvetések átlagosan a cég bevételének 7,7%-át tették ki (Gartner, 2025). A Gartner szerint a 402 válaszadó túlnyomó többsége 1 milliárd USD feletti éves bevételről számolt be, ezért ne használd célként egy startupnál. A hasznosabb belső ellenőrzés a kihasználtság: ha nem tudod megnevezni, mely funkciókat használod egy eszközben, akkor azokért is fizetsz, amelyeket nem.

Gyakori hibák

• Eszközburjánzás: minden csapat megveszi a saját célmegoldását. A megoldás egy egyszerű szabály: nincs új eszköz anélkül, hogy megneveznéd, melyik réteghez tartozik, és melyik eszközt váltja ki, vagy milyen hiányt tölt be.
• Nincs adatgazda. A CRM-ben tizenkét „iparág” legördülő érték van, és ebből három ugyanazt jelenti. Valakinek gazdája kell legyen a meződefinícióknak az eszközökön át.
• Következetlen definíciók. A „cégméret” a CRM-ben létszámot, az adatgazdagító eszközben árbevételt, a hirdetési platformon pedig egy tartományt jelent. Mezőnként válassz egyetlen kanonikus definíciót.
• Funkciók alapján vásárolni az integrációk helyett. Egy eszközt, amely tíz dolgot tud, de csak CSV-n keresztül szinkronizál, egyetlen dologra fognak használni.
• A hozzájárulás mint utólagos gondolat. A hozzájárulás előtt aktiválódó tagek jogi és adatminőségi problémát jelentenek. Minden taget a hozzájáruláskezelő platformon és a tagkezelőn keresztül futtass.
• Kaotikus kampánycímkézés. Következetes UTM-ek nélkül az analitika, az attribúció és a personalizációs szabályok is elromlanak. Egy közös elnevezési konvenció és egy UTM-generátor olcsón megoldja.

Ha a weboldal csak egy része egy szélesebb újjáépítésnek, a GTM technológiai stack kiválasztásáról szóló írás ugyanennek a döntésnek a sales és operációs oldalát tárgyalja. Kifejezetten a weboldal rétegre a Markettailor a cégszintű látogatóazonosítást szegmensalapú personalizációval kombinálja, ami a növekedési szakaszban két külön eszközt válthat ki. Mikor ne vonj össze: ha az adatbővítő szolgáltatód már be van kötve a CRM-be, és a sales támaszkodik rá, tartsd meg, és csak a weboldal réteget add hozzá.

Gyakran ismételt kérdések

Mi az a martech stack?

A martech stack azoknak a szoftvereknek az összessége, amelyekkel egy marketingcsapat ügyféladatokat gyűjt, kampányokat futtat, a weboldalt kezeli és az eredményeket méri. A B2B-ben jellemzően tartalmaz CRM-et, marketingautomatizációt, analitikát, adatbővítő és azonosító eszközöket, hirdetési platformokat, tesztelésre vagy personalizációra képes CMS-t, sales engagement és hozzájáruláskezelő eszközöket. Egy jó stackben minden feladatnak egy gazdája és egy nyilvántartó rendszere van.

Mi legyen egy B2B martech stackben?

Minimum: egy CRM mint elsődleges nyilvántartó rendszer, e-mail-küldési és űrlapgyűjtési lehetőség, webanalitika, hozzájáruláskezelés és a hirdetési platformjaid. Ahogy nősz, add hozzá az adatgazdagítást és a látogatóazonosítást, egy kísérletezési vagy személyre szabási eszközt, egy sales engagement szoftvert, végül pedig egy adattárházat. Akkor adj hozzá új réteget, ha egy konkrét feladat nincs elvégezve, nem azért, mert létezik egy kategória.

Szükségük van a B2B cégeknek CDP-re?

A korai szakaszban általában nem. Egy ügyféladat-platform (CDP) akkor térül meg, ha több aktiválási csatornának ugyanarra az egységes profilra van szüksége, és van, aki karbantartja az identitásfeloldási szabályokat. A legtöbb seed és korai növekedési fázisban lévő cégnek egy tiszta CRM közvetlen integrációkkal jobban megfelel. Sok későbbi fázisú csapat csomagolt CDP helyett az adattárházát és reverse ETL-eszközöket használ.

Milyen gyakran érdemes auditálni a martech stacket?

Évente egyszer teljes auditként, plusz egy gyors ellenőrzés minden új vásárlás és minden megújítás előtt. A teljes audit kiterjed a leltárra, a felelősre, a költségre, a használatra, az átfedésekre és az integrációkra. A megújítási dátumokat és a felmondási időket egy közös naptárban tartsd, mert egy eszköz megszüntetésének vagy újratárgyalásának legolcsóbb időpontja a felmondási idő kezdete előtti hónap.