Az offline konverziók importja 2026-ban technikai kényszer és üzleti előny is egyszerre: a Google Ads áttért a Data Manager API-ra, a Meta pedig teljesen bezárta az Offline Conversions API-t a Conversions API javára. Az azonnali teendő egyszerű: gyűjtsd a GCLID-et és az fbclid-et minden leadnél, normalizáld és SHA-256 alatt hasheld a személyes azonosítókat, majd állítsd be a folyamatos, automatizált importot. A volumen nem ér semmit, ha a match rate alacsony, ezért az adatminőség előbbre való a mennyiségnél.

Röviden:

  • A match rate javításához elengedhetetlen az adatok normalizálása és az összes releváns azonosító precíz hashelése, különösen az email és telefonszám.
  • A Google 2026-tól a Data Manager API-ra migrálja az offline konverzióimportot, ezért a megfelelő API-konfiguráció, az action_source helyes megadása és a batch kezelés kritikus.
  • A Meta csak a Conversions API-n keresztül fogad el offline eseményeket, ahol kiemelten fontos a fbclid, az order_id és a helyes action_source beállítása.
  • A hashing csak az adat tisztaságával és konzisztenciájával működik jól, a hibás formátumok vagy elváltozások alacsony match rate-hez vezetnek.
  • A konverzióimport során a hibák kivizsgálása és a diagnosztikai panel folyamatos figyelése alapvető a sikeres és eredményes adatkezeléshez.
Marketing Vision Agency
Tedd mérhetőbbé hirdetéseidet
A Marketing Vision Agency közgazdasági alapokra helyezi online hirdetéskezelését, mérhető üzleti eredményekre és magasabb árrésre törekedve.

Ismerd meg az ügynökséget

Tartalomjegyzék

Mi az offline konverzióimport és miért érdemes bevezetni

Az offline konverzióimport azt jelenti, hogy a hirdetési fiókba visszatöltöd azokat az eseményeket, amelyek nem a weboldalon történtek, hanem telefonon, CRM-ben vagy boltban zárultak le.

  • Telefonos értékesítés: az ügyfél felhívja a céget a hirdetésből érkezett szám alapján, és a call center rögzíti az üzletet.
  • CRM-lezárt üzlet: egy lead hetekkel a kattintás után válik fizető ügyféllé a CRM-ben.
  • Boltban zárt vásárlás: az online hirdetés hoz be egy vásárlót, aki a fizikai üzletben vásárol.

Ez azért kritikus jelzés az algoritmusoknak, mert a Google Ads és a Meta is a beérkező konverziós adatokból tanul, kire hasonlóan érdemes hirdetni. Minél pontosabb és valósabb ez a jel, annál jobb lesz a célozhatóság és a megtérülés. Ez a hatás különösen erős B2B-nél, magas CPL-es szektorokban és hosszú értékesítési tölcsérnél, ahol a kattintás és a valódi bevétel között hetek, hónapok telnek el.

A Google 2026. június 15-től migrálta az offline konverziós adatfolyamokat a Data Manager API-ra, ami érinti a régebbi UploadClickConversions integrációkat is. A gyakorlati beállítás lépései:

  1. Hozz létre egy ConversionAction objektumot a fiókban, amely definiálja, milyen offline eseményt mérsz (pl. „lezárt üzlet”).
  2. Töltsd fel a ClickConversion objektumokat, minden eseményhez megadva a GCLID-et, ha rendelkezésre áll.
  3. Ha nincs GCLID, használd a hashelt user_identifiers mezőket (email, telefonszám) az Enhanced Conversions for Leads megközelítéssel.
  4. Adj meg job_id-t minden batchhez, hogy a diagnosztikában visszakereshető legyen, mi sikerült és mi nem.
  5. Kezeld a partial_failure választ, mert egy hibás sor nem szabad, hogy leállítsa a teljes feltöltést.

A Google Ads API dokumentációja szerint az importált konverziók a kattintás dátumához kötődnek visszafelé, nem a feltöltés napjához, ami befolyásolja az attribúciós ablakot.

Profi tipp: Ha van GCLID-ed, mindig küldd el a hashelt user_identifiers mellett is. A több azonosító kombinációja jelentősen javítja a találati esélyt, mint bármelyik egyedül.

Meta Conversions API: hogyan kezeld helyesen az offline eseményeket

A Meta 2025 májusától megszüntette az Offline Conversions API-t, az offline eseményeket kizárólag a Conversions API-n keresztül lehet beküldeni. Ez nem csak technikai átállás, hanem új szabályokat is hoz magával.

  • Az action_source paramétert kötelező helyesen megadni: physical_store fizikai boltos zárásnál, system_generated automatizált CRM-eseményeknél.
  • Gyűjtsd és tárold az fbclid-et (illetve a belőle generált _fbc cookie-t), mert ennek hiánya a migráció során visszaesést okozott az elfogadott eseményszámban.
  • Az event_time mezőt Unix timestamp formátumban add meg, ne string dátumként.
  • Használj order_id vagy egyedi deal_id mezőt a deduplikációhoz, hogy egy esemény ne számoljon duplán online és offline forrásból.

A Meta üzleti súgóközpontja szerint minden payloadhoz legalább egy customer identifier szükséges. Rossz action_source beállítás megváltoztatja az attribúciós ablakot, és torzítja, mit tanul az algoritmus a jó vásárlóról.

Milyen normalizálási hibák rontják a match rate-et

A hashing önmagában nem old meg semmit, ha az input adat inkonzisztens. Néhány mező kritikus:

  • Email: kisbetűsítve, felesleges szóközök nélkül kell hashelni.
  • Telefonszám: E.164 formátumban (országkóddal, pl. +36301234567), különben a Google és a Meta rendszere sem ismeri fel.
  • Név: ékezetek és speciális karakterek kezelése kritikus, mert egy „Kovács” és egy „Kovacs” más hash-értéket ad.
  • Cím: irányítószám és városnév normalizálása egységes formátumban.

A SHA-256 hashing implementációnál mindig UTF-8 kódolást használj hashelés előtt, és ellenőrizd, hogy a string trim (whitespace levágás) megtörtént a hashelés előtt, ne utána. Iparági adatok szerint a sikeres integrációk match rate-je jellemzően közepes vagy magas szinten mozog (https://support.google.com/google-ads/answer/11954870?hl=en); ha ez alacsony match rate esetén majdnem mindig normalizálási vagy hashing hiba áll a háttérben, nem az azonosítók hiánya.

Profi tipp: Ha a match rate hirtelen zuhanás esetén érdemes ellenőrizni, hogy nem változott-e a CRM export formátuma. A telefonszám-formátum csendes átállása (pl. +36 helyett 06) a leggyakoribb rejtett hibaforrás.

API, batch vagy CRM-connector: melyik módszer illik hozzád

A választás a volumentől és a technikai kapacitástól függ, nem attól, melyik a „modernebb”.

  • A valós idejű API import (UploadClickConversions vagy CAPI direktben) akkor éri meg, ha van fejlesztői kapacitás és napi több tucat esemény zajlik.
  • A napi vagy heti batch feltöltés CSV alapon jó középutas megoldás kisebb csapatoknak, de a késleltetés torzíthatja az attribúciós ablakot.
  • A CRM-connectorok (HubSpot, Salesforce, natív POS-integrációk) leveszik a terhet a fejlesztésről, de formátumeltérések és duplikációs kockázat jár velük.
  • Közepes és nagy volumenű fiókoknál a bevált architektúra: CRM-connector normalizált exporttal, napi automatizált job és külön hibakezelő log a partial_failure eseteknek.

A Google Ads kampányoptimalizálási gyakorlat azt mutatja, hogy a legjobban skálázó fiókok mindig kombinálják az automatizált feltöltést emberi felülvizsgálattal az első hetekben.

Hogyan diagnosztizáld a hibákat a Google Ads felületén

A Google Ads offline adatok diagnosztikája egy helyen mutatja az adatminőséget, minőségi kategóriákkal (kiváló, jó, beavatkozást igényel) és munkánkénti előzményekkel.

  1. Nyisd meg a diagnosztikai panelt, és nézd meg, milyen kategóriába esik a legutóbbi feltöltés.
  2. Vizsgáld meg a figyelmeztetéseket, például a CLICK_NOT_FOUND jelzést, amely azt jelenti, hogy a megadott GCLID vagy identifier nem található az eredeti kattintáshoz.
  3. Kövesd a javítási sorrendet: először a formátumot ellenőrizd (telefonszám, email), majd a hashing implementációt, aztán az account mapping helyességét, végül a duplikációkat.
  4. Nézd az accepted events és successful_event_count mutatókat időbeli trendben, nem egyetlen napi értékben, mert egy rossz batch is torzíthatja a napi képet.

Milyen adatvédelmi minimumot kell technikailag betartani

A hashing nem jogi védőháló, csak technikai adatvédelem. A SHA-256 titkosítás megnehezíti az adat visszafejtését, de nem helyettesíti a jogalapot, amelyre az adatkezelésnek szüksége van.

  • Csak azokat a mezőket küldd, amelyek valóban szükségesek az egyezéshez, ne az egész CRM-rekordot.
  • Tartsd nyilván, mennyi ideig őrződ meg az importált eseményeket, és biztosítsd az érintett jogosultságait (törlés, hozzáférés).
  • Ha a leadgyűjtés folyamata bővül vagy új adatforrást vonsz be, egyeztess adatvédelmi felelőssel vagy jogi tanácsadóval, mielőtt élesítenéd az importot.

Gyors ellenőrzőlista az első 90 napra

  1. 1. nap: állítsd be a GCLID és fbclid gyűjtését minden űrlapon és hívásvégponton, ellenőrizd a Google tag konfigurációt.
  2. 1–7. nap: normalizáld a CRM mezőket, és építsd fel a hashelő pipeline-t (email, telefon, név).
  3. 1–30. nap: futtasd le a tesztfeltöltéseket, nézd a diagnosztikai panelt naponta, kövesd a match rate alakulását.
  4. 30–90. nap: skálázd fel automatizált batch vagy valós idejű pipeline-ra, és állíts be riasztást hirtelen match rate esésre.

Amit az ügynökségi tapasztalat elárul az offline importról

Napi szinten dolgozunk olyan fiókokkal, ahol a konverziós adat minősége dönti el, mennyire hatékonyan tanul az algoritmus. A tapasztalat egyértelmű: a technikai hibák (rossz formátum, hiányzó fbclid, elavult hashing) sokkal gyakrabban okoznak alacsony match rate-et, mint az azonosítók valódi hiánya.

Külső partnert érdemes bevonni, ha a csapatnak nincs kapacitása az adathigiéniára, a fejlesztői oldalra vagy a csaló leadek kiszűrésére. Ez nem minden fióknál szükséges, de ahol a havi büdzsé jelentős, az API-alapú, folyamatosan monitorozott import egyértelműen megtérül a jobb célozhatóságon keresztül.

— Balázs

Források

A Google fejlesztői oldala részletesen leírja az UploadClickConversions folyamatot kód szintű példákkal. A Google Ads súgó diagnosztikai cikke magyarázza az adatminőségi kategóriákat. A Meta oldalán a Conversions API dokumentáció tartalmazza az action_source és offline események pontos beállítását, kiegészítve a DataCops elemzésével a migrációs kockázatokról.

Ha a saját csapatod inkább a stratégiára és az eladásra koncentrálna, a technikai import terhét pedig kiszerveznéd, a Marketing Vision Agency kampánykezelési szolgáltatása pontosan ezt az adathigiéniai és mérési munkát végzi el a nagy büdzséjű fiókoknál.

Ajánlott