TL;DR
A Search Engine Land 2026. szeptember 21-én számolt be a Google Ads multi-source conversions béta új lehetőségéről. A megoldás egy meglévő, Google taggel mért webes konverzióhoz további adatforrást – például CRM-et vagy rendelési adatbázist – kapcsol. Az online és a háttérrendszerből feltöltött eseményt azonos tranzakcióazonosító alapján egyezteti. Így pótolhatók a böngészőkorlátozások vagy hirdetésblokkolók miatt elvesző jelek, és kiegészíthetők a konverziók hiányzó ügyféladatai. A funkció ugyanakkor nem automatikus javítás: hibás azonosítók, eltérő pénznemek vagy rossz CRM-adatok túlszámolást és téves licitálást okozhatnak.
Mit jelent a multi-source conversion?
A legtöbb Google Ads-fiókban a webes konverziót a Google tag vagy a Google Tag Manager érzékeli. Ez megfelelő alap lehet, de nem minden vásárlásról vagy leadről jut el minden jel a hirdetési rendszerhez. A böngészők adatvédelmi korlátozásai, a hozzájárulás hiánya, a hirdetésblokkolók és technikai hibák hiányos mérést eredményezhetnek.
A multi-source conversions nem lecseréli a webes címkét, hanem kiegészíti. A Google hivatalos dokumentációja szerint ugyanahhoz a konverziós művelethez egy további adatforrás kapcsolható a Data Manager vagy a Data Manager API használatával. Ez a forrás lehet például CRM, rendelési adatbázis vagy más háttérrendszer.
A két eseményt a transaction ID köti össze. Egy webshopnál ez tipikusan a rendelési azonosító. Szolgáltatói leadnél stabil, egyedi eseményazonosítóra van szükség. Ha ugyanaz az azonosító pontosan szerepel a webes és az offline adatban, a rendszer képes felismerni, hogy nem két külön konverzióról van szó.
Miért üzletileg fontosabb ez, mint egy új riport?
A Google Ads automatizált licitálása abból tanul, amit konverzióként és értékként visszakap. Ha a valós vásárlások egy része hiányzik, a rendszer kevesebb adat alapján dönt. Ha a leadek üzleti értéke nem jut vissza, egy olcsó, de gyenge érdeklődő ugyanolyan értékesnek tűnhet, mint egy nyereséges ügyfél.
A háttérrendszerből érkező adatok három ponton javíthatják a döntést:
- pótolhatják a webes címke által nem rögzített konverziókat;
- kiegészíthetik a hiányzó, hozzájárulással kezelt ügyfélazonosítókat;
- pontosíthatják a konverzió értékét a végleges rendelési vagy CRM-adat alapján.
Ez különösen fontos ott, ahol a vásárlás értéke később változik. Egy rendelésből visszaküldés lehet, egy leadből pedig elveszett vagy nagy értékű szerződés. A Google fejlesztői dokumentációja szerint az eredeti transaction ID használatával a korábban rögzített érték korrigálható például végleges kosárértékkel, upsellel vagy pénzügyi módosítással.
A transaction ID a rendszer gerince
Az egyedi tranzakcióazonosító nem technikai apróság. Ez akadályozza meg, hogy a webes és az offline eseményt a rendszer két külön konverziónak számolja.
A Google diagnosztikai útmutatója szerint már a formázási eltérések is hibát okozhatnak:
- az „order-12345” és „12345” nem ugyanaz;
- az „abc-123” és „ABC-123” eltérhet;
- a „00123” és „123” nem biztos, hogy egyezik;
- a „12345” és „12345.0” különböző adattípust jelezhet;
- az „undefined” vagy „order_id” helykitöltő soha nem valódi egyedi azonosító.
Az azonosítónak minden konverziónál meg kell jelennie a tagben, majd változtatás nélkül kell bekerülnie a háttérrendszerbe és a feltöltésbe. Ha ez nincs végig megtervezve, a multi-source mérés helyett duplikált vagy értelmezhetetlen adatot kapunk.
A 14 napos próbaidőszak nem formaság
Az újonnan kapcsolt adatforrás az első offline feltöltéstől számított 14 napos próbaidőszakba kerül. A Google hivatalos súgója szerint ekkor az adatok megjelennek a riportokban és a diagnosztikában, de még nem befolyásolják az automatikus licitálást. A meglévő webes tag konverziói közben továbbra is licitálhatók.
Ez a két hét lehetőséget ad az egyezési arány, a többletkonverziók és a hibák ellenőrzésére. A próba végén azonban a rendszer az érvényes, új feltöltött adatokat automatikusan bevonja a riportolásba és a licitálásba – akkor is, ha maradt diagnosztikai figyelmeztetés.
Éppen ezért a próbaidőt éles bevezetési szakasznak tekinteném. Nem elég bekapcsolni a kapcsolatot és két hét múlva ránézni.
Milyen hibák veszélyesek a teljesítményre?
Alacsony egyezési arány
Ha a webes és az offline események kevesebb mint 10%-ánál egyezik a transaction ID, a Google túlszámlálási kockázatot jelezhet. Ilyenkor először az azonosítók formátumát és a webes tag lefedettségét kell javítani.
Eltérő konverziós érték
A hivatalos diagnosztika sürgős figyelmeztetést adhat, ha a tag és a feltöltött forrás értékei között két napon belül tízszeresnél nagyobb eltérés van. Gyakori ok a nettó–bruttó keverés, a forint–euró tévesztés vagy az, hogy az egyik rendszer forintban, a másik fillérben tárol.
Nem ugyanaz az üzleti esemény
Ha a tag a rendelés leadását, a CRM pedig a kiszállítást küldi ugyanahhoz a konverzióhoz, tisztázni kell, melyik eseményt és értéket akarjuk optimalizálni. Máskülönben a riport technikailag működhet, mégis félrevezető lesz.
Gyenge CRM-adat
Az offline forrás nem lesz attól igaz, hogy CRM-ből érkezik. Ha az értékesítők nem frissítik a státuszokat, duplikált rekordok vannak, vagy minden érdeklődő automatikusan minősített leadnek számít, a licitálás rossz üzleti jelet tanul meg.
Nem az a cél, hogy több konverziót mutassunk
A bevezetés sikere nem az, hogy a konverziószám hirtelen magasabb. A helyes kérdés az, hogy a rendszer közelebb került-e a valós üzleti eredményhez.
Én a következő mutatókat hasonlítanám össze:
- hány webes esemény kapott offline párt;
- mekkora a transaction ID egyezési aránya;
- hány valóban új konverziót pótolt az offline forrás;
- hogyan változott a konverziós érték;
- romlott vagy javult-e a minősített lead és a lezárt ügyfél költsége;
- egyezik-e a Google Ads összesített értéke a rendelési vagy pénzügyi rendszerrel;
- a próbaidőszak után hogyan változott a kampányok költése és minősége.
A mérési többlet nem feltétlenül teljesítményjavulás. Lehet, hogy eddig is megvoltak a vásárlások, csak nem láttuk őket. Az üzleti előny akkor jelenik meg, ha a pontosabb adatokból jobb költségelosztás és több nyereséges eredmény következik.
Magyar piaci relevancia
Magyar webshopoknál gyakori, hogy a webes mérés a rendelés leadásakor rögzíti a bevételt, miközben utánvét, lemondás vagy visszaküldés miatt a végleges érték később jelentősen változik. A háttérrendszerből érkező korrekció ezért valósabb ROAS-t adhat.
Szolgáltatóknál még nagyobb lehet a különbség a lead és az ügyfél között. Egy egészségügyi időpontkérés, autóipari ajánlatkérés vagy B2B érdeklődő csak később válik bevétellé. Ha a CRM-ből a minősített vagy lezárt státusz is visszakerül, a kampány nem pusztán a legtöbb űrlapot, hanem a jobb üzleti esélyt tanulhatja.
A kisebb cégeknél azonban előbb a folyamatot kell rendbe tenni. Ha nincs stabil rendelési azonosító, következetes CRM-használat és adatvédelmi dokumentáció, az API-integráció korai. Először a mérési terv, utána az automatizálás.
Gyakorlati teendőlista
- Írja le pontosan, melyik üzleti eseményt tekinti elsődleges konverziónak.
- Ellenőrizze, hogy minden webes konverzió egyedi transaction ID-t küld-e.
- Vizsgálja meg, hogy ugyanaz az azonosító változatlanul eljut-e a CRM-be vagy rendelési rendszerbe.
- Egyeztesse a pénznemet, a nettó–bruttó logikát és az érték mértékegységét.
- Tisztítsa meg a duplikált, hiányos és tesztadatokat.
- Kapcsolja az adatforrást Data Managerrel vagy Data Manager API-val.
- A 14 napos próba alatt naponta ellenőrizze a diagnosztikát.
- Mérje az egyezési arányt és a valóban pótolt konverziókat.
- A próba vége előtt javítsa a sürgős és teljesítményt érintő hibákat.
- A licitálási hatást ne csak Google Ads CPA-val, hanem CRM-es ügyfélminőséggel és fedezettel is értékelje.
Rövid GYIK
Kiváltja a multi-source conversion a Google taget?
Nem. A funkció a taggel mért webes konverziót egészíti ki egy további háttéradatforrással.
Mi alapján párosítja a Google a két eseményt?
Azonos transaction ID alapján. Ennek egyedinek és mindkét forrásban pontosan azonos formátumúnak kell lennie.
Az offline adat azonnal befolyásolja a licitálást?
Nem. Az első feltöltéstől 14 napos próbaidőszak indul, amikor az adat riportolásra és diagnosztikára használható, de még nem licitálható. Utána az érvényes új adatok automatikusan bekerülnek a licitálásba.
Minden Google Ads-fiókban elérhető?
A funkció jelenleg béta. Ha nem látható, előfordulhat, hogy az adott fiókban még nem érhető el.
Elég egy CRM-kapcsolat a jobb kampányeredményhez?
Nem. A kapcsolat csak adatot szállít. A javuláshoz pontos státuszok, helyes értékek, stabil azonosítók és olyan konverziós cél szükséges, amely valóban üzleti értéket képvisel.
Források és további olvasnivaló
Search Engine Land: Google Ads lets offline uploads fill gaps in tag-based conversions, megjelent: 2026. szeptember 21.
Google Ads Súgó: Multi-source conversions in Google Ads (beta), ellenőrizve: 2026. szeptember 23.
Google Ads Data Manager Súgó: Fix diagnostic alerts for multi-source conversions, ellenőrizve: 2026. szeptember 23.
Google for Developers: Google Ads multi-source conversions – Data Manager API, frissítve: 2026. szeptember 21., ellenőrizve: 2026. szeptember 23.