Élő chat és Messenger-widget beszélgetésindításának mérése konverzióként

Scheo · 2026-10-14 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Az oldalba ágyazott chatablakban indított beszélgetés alapból nem jelenik meg a GA4-ben, mert a widget a legtöbbször külön keretben, a szolgáltató szerveréről fut, a Google Analytics automatikus mérése pedig nem ismer chat-eseményt. Mérni úgy tudod, ha a widget saját JavaScript-eseményeit a dataLayerbe továbbítod, és három külön eseményt küldesz belőlük. A megnyitás, az első üzenet és az elérhetőség megadása más-más szándékot jelez, ezért külön érdemes kezelni őket.

A cikk végigmegy azon, mi okozza a vakfoltot, hogyan épül fel a mérés lépésről lépésre, melyik esemény legyen kulcsesemény, és hogyan követhető vissza, hogy a beszélgetésből valódi ajánlatkérés lett-e. Az állításoknál jelöljük, mi hivatalosan igazolt, mi saját tapasztalat, és mi szakmai feltételezés.

Miért nem látszik a chatben indított beszélgetés a GA4-ben?

Azért nem látszik, mert a GA4 csak azt méri, amit a saját címkéje vagy a Tag Manager elküld neki, a chat-widget pedig jellemzően egy másik domainről betöltött iframe-ben él, amelybe a szülőoldal szkriptjei nem látnak bele.

Hivatalosan igazolt. A GA4 bővített mérése (enhanced measurement) a Google Analytics súgója szerint az oldalmegtekintést, a görgetést, a kimenő kattintást, a belső keresést, a videós aktivitást, a fájlletöltést és az űrlap-interakciót gyűjti automatikusan. Chat-esemény nincs a listán. A böngészők azonos eredetre vonatkozó szabálya (same-origin policy) miatt a szülőoldal nem olvashatja egy eltérő eredetű iframe tartalmát, így a Tag Manager kattintás- és űrlapfigyelői sem sülnek el arra, ami a kereten belül történik.

Saját tapasztalat. A leggyakoribb helyzet az, hogy a chat hónapok óta fut az oldalon, a kollégák naponta válaszolnak benne, a riportban viszont nulla konverzió áll mellette. Ilyenkor a hirdetési rendszer sem tanul belőle, hiszen a beszélgetésről semmilyen jelzést nem kap. Előfordul a fordítottja is, amikor a chatbuborékra tett kattintásfigyelő minden megnyitást konverziónak számol, és a számok látványosan felfújódnak. Mindkét esetben rossz adatra épül a döntés arról, melyik kampány hoz érdeklődőt.

Milyen megoldások vannak a chat-események mérésére?

Három járható út van. A legjobb a widget saját JavaScript API-ja, a második az iframe-ből küldött postMessage üzenet elkapása, a harmadik a chatszolgáltató beépített GA4-integrációja. A buborékra tett sima kattintásfigyelő csak végső tartalék, mert a megnyitáson túl semmit nem lát.

A widget saját eseményei

A legtöbb élő chat eszköz (például a Tawk.to, a LiveChat, az Intercom, a Tidio vagy a Crisp) dokumentált JavaScript API-t ad. Ebben visszahívó függvények jelzik, ha a látogató megnyitja az ablakot, elküldi az első üzenetét, vagy kitölti a beszélgetés előtti űrlapot. A Tawk.to esetében ilyen az onChatMaximized, az onChatStarted és az onPrechatSubmit. A pontos neveket mindig az adott eszköz aktuális dokumentációjából vedd, mert szolgáltatónként eltérnek, és időnként változnak.

dataLayer push a visszahívásból

A visszahívó függvényben egyetlen dolgod van, az eseményt a dataLayerbe tolni. A Tag Managerben erre egyéni esemény típusú aktiválót állítasz be, és arra kötöd a GA4-esemény címkét. Egy Tawk.to-ra írt, munkamenetenként egyszer elsülő minta így néz ki.

window.dataLayer = window.dataLayer || [];

var Tawk_API = Tawk_API || {};

function chatEsemeny(nev) { if (sessionStorage.getItem(nev)) { return; } sessionStorage.setItem(nev, '1'); window.dataLayer.push({ event: nev, lead_source: 'chat' }); }

Tawk_API.onChatMaximized = function () { chatEsemeny('chat_open'); };

Tawk_API.onChatStarted = function () { chatEsemeny('chat_first_message'); };

Tawk_API.onPrechatSubmit = function () { chatEsemeny('generate_lead'); };

Más eszköznél a szerkezet ugyanez, csak a visszahívások neve más. Élesítés előtt teszteld, hogy az első üzenetet jelző visszahívás tényleg a látogató üzenetére sül-e el, vagy az operátor által kezdett beszélgetésre is.

Az iframe-korlát és a postMessage

Ha a widget nem ad API-t, de a keretből üzenetet küld a szülőoldalnak, azt a message eseményre feliratkozva el tudod kapni. Az eredetet (origin) minden esetben ellenőrizd, különben bármelyik beágyazott tartalom hamis eseményt küldhet.

window.addEventListener('message', function (e) { if (e.origin !== 'https://widget.pelda.hu') { return; } if (e.data.type === 'chat_started') { chatEsemeny('chat_first_message'); } });

Szakmai feltételezés. A nem dokumentált postMessage üzenetekre épített mérés törékeny. Egy widget-frissítés szó nélkül átnevezheti az üzenettípust, és a mérés csendben leáll. Ha ilyen megoldásra kényszerülsz, állíts be mellé egyéni értesítést a GA4-ben arra az esetre, ha az esemény száma hirtelen nullára esik.

Mi a helyzet a Messengerrel?

A Meta fejlesztői dokumentációja szerint a weboldalba ágyazható hivatalos Chat Plugin 2024 májusában megszűnt. Azóta a „Messenger-widget” a gyakorlatban vagy egy m.me hivatkozásra mutató gomb, vagy egy külső szolgáltató ablaka. A gombnál a beszélgetés a Messengerben, az oldaladon kívül zajlik, ezért a weboldalon csak a kattintást tudod mérni. Az első üzenetet és az elérhetőséget ilyenkor a Meta üzenetkezelő felületén vagy a CRM-ben kell követned, a GA4-ben ez a két lépés nem lesz ott.

Hogyan különíthető el a megnyitás, az első üzenet és az elérhetőség megadása?

Úgy, hogy három külön eseménynevet használsz, mindegyiket más widget-jelzésre kötöd, és munkamenetenként csak egyszer engeded elsülni őket.

• chat_open akkor megy el, amikor a látogató maga nyitja meg az ablakot. Érdeklődést jelez, szándékot még alig.
• chat_first_message akkor megy el, amikor a látogató elküldi az első saját üzenetét. Ez már kérdés, tehát valódi interakció.
• generate_lead (lead_source paraméterrel, chat értékkel) akkor megy el, amikor a látogató megadja az e-mail-címét vagy a telefonszámát a beszélgetés előtti űrlapon, az offline üzenet űrlapján vagy a chatbot kérdésére.

Hivatalosan igazolt. A generate_lead a Google ajánlott eseményei között szerepel, a lead-generálási eseménykészletben pedig ott van mellette a qualify_lead és a close_convert_lead is. Az ajánlott nevek használata azért praktikus, mert a GA4 riportjai és a hirdetési integrációk ezekre vannak felkészítve. A chat_open és a chat_first_message egyéni név, ezeket szabadon választhatod meg, csak maradj következetes.

A beállítás menete a következő.

1. Nézd meg a widget dokumentációjában, melyik visszahívás jelzi a megnyitást, az első látogatói üzenetet és az űrlap elküldését.
2. Írd meg a három dataLayer push-t, és mindegyikhez tegyél sessionStorage-jelzőt, hogy egy munkameneten belül ne ismétlődjön.
3. A Tag Managerben hozz létre három egyéni esemény aktiválót és három GA4-esemény címkét, a lead_source paramétert pedig vedd fel adatréteg-változóként.
4. Az előnézeti módban és a GA4 DebugView nézetében játszd végig mindhárom lépést asztali gépen és mobilon is.
5. A GA4 adminfelületén regisztráld a lead_source paramétert egyéni dimenzióként, majd jelöld kulcseseménynek azt az eseményt, amelyik mellett döntöttél.
6. Ha hozzájárulás-kezelőt használsz, ellenőrizd, hogy a chat és a mérés milyen hozzájárulás mellett tölt be, mert az elutasító látogató beszélgetése nem fog látszani a riportban.

Saját tapasztalat. A legtöbb hamis adat három helyről jön. Az első a proaktív üdvözlés, amikor a widget magától kinyílik, és a megnyitás esemény a látogató szándéka nélkül is elmegy. A második a chatbot nyitóüzenete, amelyet egyes eszközök első üzenetként jelentenek. A harmadik a visszatérő látogató, akinél a korábbi, nyitva maradt beszélgetés oldalbetöltéskor újra megjelenik. Mindháromra az a megoldás, hogy csak a látogató által kiváltott jelzésre küldesz eseményt.

Hivatalosan igazolt. A Google Analytics szabályzata tiltja a személyazonosításra alkalmas adat beküldését. Az e-mail-cím, a telefonszám és az üzenet szövege ezért ne kerüljön a dataLayerből GA4-paraméterbe, elég az a tény, hogy az elérhetőség megérkezett.

Melyik esemény legyen kulcsesemény?

A legtöbb esetben az elérhetőség megadása legyen a kulcsesemény, mert ez az a pont, ahonnan vissza tudod hívni vagy meg tudod írni az érdeklődőt. Az első üzenet másodlagos jelzésként hasznos, a megnyitás pedig túl zajos ahhoz, hogy konverzióként számoljon.

A döntéshez négy szempontot érdemes végignézni.

• Hogyan működik nálad a chat? Ha az operátor azonnal válaszol, és a beszélgetésben nem kértek elérhetőséget, akkor az első üzenet a legmélyebb mérhető pont, és az lesz a kulcsesemény.
• Mennyi jel érkezik? Ha chatből csak ritkán jön elérhetőség, a hirdetési rendszer automatikus ajánlattétele kevés adatból dolgozik. Ilyenkor megfontolható az első üzenet bevonása is.
• Van-e duplázódás? Ha a látogató a chat után az ajánlatkérő űrlapot is kitölti, ugyanaz az ember kétszer jelenhet meg leadként. A lead_source paraméter segít szétválasztani a két forrást.
• Mennyire tiszta a jelzés? A megnyitás mögött gyakran kíváncsiság vagy véletlen koppintás áll, ezért kulcseseményként torzítja a kampányok megítélését.

Hivatalosan igazolt. A kulcsesemény a GA4 korábbi „konverzió” fogalmának új neve, a Google 2024 márciusában nevezte át. Eseményenként kapcsolható be, egy normál tulajdonban legfeljebb 30 lehet belőle, és a Google Ads konverzióként importálható.

Szakmai feltételezés. Kis forgalmú fiókban az első üzenet kulcseseménnyé tétele jó eséllyel több tanulójelet ad az ajánlattételnek, cserébe gyengébb minőségű jelet. Hogy ez megéri-e, az csak a beszélgetések utólagos minősítéséből derül ki, eredményt önmagában nem garantál.

Mit mutat a három esemény egymáshoz viszonyítva?

A három esemény együtt egy kis tölcsért ad, amelyből kiolvasható, hol akad el a látogató. A GA4 Felfedezések részében tölcsérelemzésként is felépíthető.

Ha sok a megnyitás és kevés az első üzenet, a nyitóképernyő nem ad elég okot a kérdezésre, vagy a látogató az ablakban nem találja, hová írhat. Ha sok az első üzenet és kevés az elérhetőség, akkor vagy a válasz késik, vagy senki nem kéri el az adatot. Ha a beszélgetés előtti űrlap kötelező, a megnyitás és az űrlapkitöltés közötti lemorzsolódás mutatja meg, mennyi érdeklődőt veszítesz az űrlap miatt. Ezek az arányok oldalanként és forgalmi forrásonként is eltérnek, ezért érdemes a landing oldal és a forrás szerinti bontást is megnézni.

Hogyan mérhető vissza, hogy a chatből valódi ajánlatkérés lett-e?

Úgy, hogy a beszélgetéshez már az indulásakor azonosítót rendelsz, a beszélgetés sorsát a chat-eszközben vagy a CRM-ben megjelölöd, a minősített állapotot pedig visszaküldöd a GA4-be vagy a hirdetési rendszerbe.

A mi nézőpontunk szerint a webes esemény csak annyit bizonyít, hogy valaki írt. Hogy árajánlatot kért, a nyitvatartásra kérdezett rá, egy meglévő rendelését kereste vagy állásra jelentkezett, az a GA4-ből nem derül ki. Ezt csak az tudja megmondani, aki a beszélgetést olvasta. A visszamérés három szinten építhető fel, és mindegyik az előzőre épül.

1. Kézi címkézés. Az operátor a beszélgetés végén címkét ad neki (ajánlatkérés, ügyfélszolgálat, egyéb). Havonta összeveted a címkék számát a GA4 generate_lead eseményeinek számával, és megkapod, a mért leadek mekkora része valódi érdeklődő.
2. Azonosító átadása. A widget egyéni attribútumaként átadod a beszélgetésnek a GA4 client_id értékét, a landing oldalt, az UTM-paramétereket és a hirdetési kattintásazonosítót (gclid), ha van. Így a CRM-ben minden beszélgetés mellett ott áll, honnan érkezett a látogató.
3. Visszaküldés. Amikor a kolléga ajánlatkérésnek minősíti a beszélgetést, a CRM vagy egy automatizáció a Measurement Protocolon keresztül qualify_lead eseményt küld a GA4-be ugyanazzal a client_id értékkel. A Google Ads felé ugyanezt az offline konverzióimportálás vagy a leadekhez készült bővített konverziók oldják meg.

Hivatalosan igazolt. A Measurement Protocol szerveroldalról fogad eseményt, a client_id megadása kötelező, az esemény időbélyege pedig legfeljebb 72 órával dátumozható vissza. Ha a minősítés ennél tovább tart, az esemény a beküldés napjára kerül, és ezt a riport olvasásakor figyelembe kell venned.

Saját tapasztalat. Kisebb cégnél már az első szint is elég a döntéshez. A címkézés gyakran megmutatja, hogy a chatbeszélgetések számottevő része meglévő ügyféltől érkezik, vagyis ügyfélszolgálati forgalom. Ha ezt a rendszer leadként számolja, a kampányok jobbnak látszanak a valóságnál.

Szakmai feltételezés. A minősített lead visszaküldése jó eséllyel javítja az automatikus ajánlattétel jelminőségét, kis mennyiségnél viszont a hatás nehezen mutatható ki, és jobb eredményt nem garantál.

Mit ellenőrizz élesítés előtt?

Élesítés előtt azt kell igazolnod, hogy mindhárom esemény pontosan egyszer, a megfelelő pillanatban és személyes adat nélkül érkezik meg.

• A megnyitás esemény nem megy el, ha a widget magától nyílik ki.
• Az első üzenet esemény a látogató üzenetére megy el, a bot üdvözlésére nem.
• Az elérhetőség esemény az offline űrlapnál is elsül, amikor nincs elérhető operátor.
• Oldalváltás és újratöltés után egyik esemény sem ismétlődik ugyanabban a munkamenetben.
• Mobilon is végigjátszottad, mert a widget ott gyakran teljes képernyős, és máshogy viselkedik.
• A paraméterek között nincs e-mail-cím, telefonszám vagy üzenetszöveg.
• A DebugView mutatja mindhárom eseményt, a kulcsesemény jelölés pedig a megfelelő eseményen van.
• A chatből érkező és az űrlapos lead a lead_source alapján szétválasztható a riportban.

Források és további olvasnivalók

• Google Analytics súgó (bővített mérés, ajánlott események, kulcsesemények)
• Google for Developers, Measurement Protocol (GA4) dokumentáció
• Google Tag Manager súgó (adatréteg, egyéni esemény aktiváló)
• Google Ads súgó (offline konverzióimportálás, bővített konverziók leadekhez)
• MDN Web Docs (same-origin policy, Window.postMessage)
• Meta for Developers (a Chat Plugin kivezetéséről szóló közlemény)
• A használt chat-eszköz hivatalos JavaScript API dokumentációja