Miért mutat a Meta több vásárlást, mint ahány rendelése van a webáruházamnak?

Általában azért, mert két eszköz ugyanazt a pixelt küldi eltérő eseményazonosítókkal, vagy mert a böngészős és a szerveres eseménynek nincs közös azonosítója. A Meta csak azokat a példányokat tudja összevonni, amelyeknek ugyanaz az eseménynevük és ugyanaz az eseményazonosítójuk.

Meddig vár a Meta az események deduplikálásakor?

A Meta akkor deduplikál egy böngészős és egy szerveres eseményt, ha azonos az eseménynevük és az eseményazonosítójuk, és az első után 48 órán belül érkeznek meg.

Ki kell kapcsolnom a böngészőpixelt a duplikátumok megszüntetéséhez?

Nem. Inkább add ugyanazt az eseményazonosítót a böngészőeseménynek és a szervereseménynek. A böngészőpixel olyan jelzéseket tesz hozzá, mint a sütik, a szerveresemény pedig akkor is megérkezik, ha a böngészőt blokkolják.

Megoldhatja a deduplikáció, hogy több platform ugyanazt az eladást magának tulajdonítja?

Nem. Ez átfedő attribúció, nem duplikált esemény. Vesd össze a platformok állításait a webáruházad rendeléseivel, és egyetlen attribúciós modellel hasonlítsd össze a csatornákat.

Deduplikálja a Pinterest a címkét és a Conversions API-t?

Igen, ha mindkét esemény ugyanazt az event_id-t és eseménynevet hordozza, és 48 órán belül megérkezik. A Pinterest az elsőként kapott eseményt tartja meg, a későbbi példányokat eltávolítja. A ROASaurusban a Tag és a szerver a vásárlási folyamat mind az öt eseményét egyező azonosítókkal és nevekkel küldi.

Duplikált vásárlási események: miért számolódnak kétszer az eladások

A legfontosabb tudnivalók

A duplikált vásárlási esemény az, amikor egy hirdetési platform egyetlen rendelést két vagy több vásárlásként számol.
A szokásos okok: egy böngészőpixel és egy szerveresemény, amelyeknek nincs közös eseményazonosítójuk, valamint két eszköz, amely ugyanazt a pixelt küldi.
A Meta, a TikTok, a Snapchat, a Pinterest és a Reddit egyaránt egy példányt tart meg, ha a böngésző- és a szerveresemények azonos azonosítót hordoznak, és a platform időablakán belül érkeznek meg.
Amikor a Meta, a Google és a TikTok is ugyanazt az eladást magának tulajdonítja, egyetlen esemény sem ment el kétszer: ez átfedő attribúció, amelyet a deduplikáció nem tud megoldani.
Hasonlítsd össze az egyes források vásárlásszámát a webáruházad rendeléseivel: ha egyetlen forrásban több vásárlás van, mint rendelés, akkor van egy második küldő is.

A duplikált vásárlási események akkor keletkeznek, amikor egy hirdetési platform egyetlen rendelést két vagy több vásárlásként számol. A szokásos okok: egy böngészőpixel és egy szerveresemény, amelyeknek nincs közös eseményazonosítójuk, valamint két eszköz, amely ugyanazt a pixelt küldi. Az eredmény felfújt konverziók, a valósnál jobbnak látszó ROAS, és olyan eladásokból tanuló licitálás, amelyek meg sem történtek.

Ez az útmutató elmagyarázza az okokat, az egy platformon belüli duplikátumok és az ugyanazt az eladást magának tulajdonító több platform közötti különbséget, azt, hogyan működik a deduplikáció a Metán, a TikTokon, a Snapchaten, a Pinteresten és a Redditen, valamint hogyan találhatod meg és javíthatod ki a duplikátumokat.

Mi számít duplikált vásárlási eseménynek?

Két különböző problémát neveznek dupla számolásnak. Más az okuk, és csak az egyik követési hiba.

	Duplikátum egy platformon belül	Több platform is magának tulajdonít egy eladást
Mi történik	Egy platform ugyanazt a rendelést többször is megszámolja	Több platform is magának tulajdonítja az érdemet ugyanazért a rendelésért
Példa	A Meta 2 vásárlást mutat egyetlen $80 értékű rendelésre	A Meta, a Google és a TikTok is ugyanazt a $80 értékű rendelést jelenti
Ok	Egy rendeléshez két esemény, közös eseményazonosító nélkül	Mindegyik platform a saját attribúciós szabályai szerint írja jóvá az eladást
Deduplikációval javítható	Igen	Nem
Mit tegyél	Pixelenként egy küldő és rendelésenként egy eseményazonosító	Vesd össze a webáruházad rendeléseivel, és használj egyetlen attribúciós modellt

A deduplikáció az első problémát oldja meg. A másodikhoz a saját rendelési adataidra van szükség.

Miért számolódnak kétszer a vásárlások

Egy böngészőpixel és egy szerveresemény közös azonosító nélkül

Sok webáruház szándékosan kétszer küldi el minden vásárlást: egyszer a böngészőpixelből, egyszer pedig egy szerverről egy konverziós API-n keresztül. Ez jó megoldás, mert a szerveres példány akkor is megérkezik, ha a böngészős blokkolva van. A platform azonban csak akkor tudja egyesíteni a két példányt, ha ugyanaz az eseményazonosító és ugyanaz az eseménynév szerepel rajtuk. Ha a böngésző véletlenszerű azonosítót használ, a szerver pedig a rendelésszámot, a platform két különböző vásárlást lát.

Két eszköz, amely ugyanazt a pixelt küldi

Ez az ok gyakori, és könnyű észrevétlenül hagyni, főleg egy új követőeszközre való áttérés után. A webáruház telepít egy követő appot, de megtartja a platform saját értékesítésicsatorna-appját, egy Google Tag Manager címkét vagy a sablonban lévő pixelkódot. Minden eszköz a saját azonosítóival küldi el a saját Purchase eseményét. Az egyes eszközökön belüli deduplikáció működik, a platform mégis két egymástól független vásárlást kap.

Ugyanaz az esemény, újra elküldve

A rendelés-visszaigazoló oldalon lévő vásárlási címke újra elsülhet, ha a vásárló újratölti vagy újra megnyitja az oldalt. Egy szerver is elküldhet egy rendelést kétszer, például egyszer a létrehozásakor, majd még egyszer a kifizetésekor. Az eseményazonosítót a rendelésazonosítóból képezd, hogy az ismétlés ugyanazt az azonosítót hordozza, mint az első példány, és a platform felismerhesse.

Hogyan működik a deduplikáció?

A deduplikáció az, ahogyan egy platform megtart egy példányt egy olyan eseményből, amelyet többször is megkapott. A szabály az útmutatóban szereplő platformokon hasonló: a példányoknak ugyanazt az azonosítót kell hordozniuk, általában ugyanazzal az eseménynévvel együtt, és egy időablakon belül kell megérkezniük. A platform ekkor egy példányt tart meg, a többit eldobja.

browser Purchase event_id=order-1042Böngészőpixel a pénztárban

server Purchase event_id=order-1042Conversions API, azonos név és azonosító: összevonva az elsővel

browser Purchase event_id=7c1e9a40Egy második app ugyanazon a pixelen, saját azonosítóval: újra megszámolva

Az első két esemény azonosítója megegyezik, ezért egy vásárlásnak számít. A harmadiknak saját azonosítója van, így a platform két vásárlást jelent az 1042-es rendelésnél.

Ebből két gyakorlati szabály következik. Az azonosítót egyszer hozd létre, olyasmiből, amit a böngésző és a szerver is ismer, például a rendelésazonosítóból. És mindkét oldalon pontosan ugyanazt az eseménynevet használd, ahogy a platform definiálja, például a Metán Purchase.

Deduplikációs szabályok platformonként

A részletek platformonként eltérnek. Ez a táblázat az egyes platformok hivatalos dokumentációját foglalja össze 2026 októberében.

Platform	Böngészőmező	Szervermező	Időablak	Megjegyzések
Meta	`eventID`	`event_id`	48 óra	Az eseménynévnek is egyeznie kell. Az fbp-vel vagy external_id-val működő tartalék megoldás csak akkor működik, ha a böngészőesemény érkezik előbb.
TikTok	`event_id`	`event_id`	48 óra	Az eseménynévnek is egyeznie kell. A TikTok az elsőként kapott eseményt tartja meg.
Snapchat	`client_dedup_id`, vásárlásoknál pedig `transaction_id`	`event_id`, vásárlásoknál pedig `order_id`	48 óra, vásárlási rendelésazonosítónál 30 nap	Az eseménynévnek is egyeznie kell. A client_dedup_id páros élvez elsőbbséget.
Pinterest	`event_id`	`event_id`	48 óra	Mindkét forrásból ugyanazt az eseménynevet küldd. A Pinterest az elsőként kapott eseményt tartja meg.
Reddit	`conversionId`	`conversion_id`	2 nap	Azonos eseménytípus, egyéni eseményeknél azonos név. Óránként fut le, és akár 24 órába is telhet, mire megjelenik.

Az általános szabály: ugyanaz az esemény, ugyanaz az azonosító, az időablakon belül. A mezőnevek eltérnek, ezért minden integrációt külön ellenőrizz.

A ROASaurusban a Meta, a TikTok, a Snapchat, a Pinterest és a Reddit böngészőpixelei ugyanazt az eseményazonosítót küldik, mint a szerveresemények, így ezek a platformok deduplikálnak. A Snapchatnél a pixel a rendelésazonosítót is elküldi transaction_id néven, ami megfelel a szerveroldali vásárlás order_id mezőjének. A Pinterestnél a Tag és az API egyező eseménynevekkel dolgozik. Az X, a Microsoft Advertising és a Taboola csak szervereseményeket kap, így nincs mit összevonni. Ha te magad küldöd az eseményeket, a Meta Conversions API útmutatója megmutatja, hová kerül az eseményazonosító a pixelben és az API-hívásban.

Az, hogy több platform is magának tulajdonít egy eladást, nem duplikált esemény

Most a második probléma. Egy vásárló megnéz egy TikTok-videót, két nappal később rákattint egy Google Shopping hirdetésre, majd egy Meta retargeting hirdetés után vásárol. Mindegyik platformnak megvan a saját feljegyzése egy kattintásról vagy megtekintésről, és mindegyik jelenti az eladást. Egyetlen esemény sem ment el kétszer, ezért semmilyen deduplikációs beállítás nem változtat ezen.

Egy hét alatt magának tulajdonított bevétel (példa webáruház)

Hogyan találd meg a duplikált vásárlási eseményeket

Vesd össze az egyes forrásokat a rendeléseiddel
Vegyél egy teljes napot. Számold meg, hogy az egyes források hány Purchase eseményt küldtek aznap, deduplikáció előtt: a böngészőpixel és a szerveresemények. Néhány eseménykezelő eszköz kapcsolati mód szerint is megmutatja ezt a bontást, a szerveroldali követőeszközödnek pedig saját naplója van arról, mit küldött el. Hasonlítsd össze az egyes számokat azzal, hogy a webáruházad hány rendelést fogadott aznap.
Olvasd el a deduplikációs jelentéseket
Néhány platform jelenti az általa eltávolított duplikátumokat. A Reddit például hét napig naplót vezet a deduplikált eseményekről, a Pinterest pedig az Ads Managerben eseményenként mutatja a deduplikációt.
Adj le egy tesztrendelést
Nyisd meg a platform tesztesemények nézetét, és adj le egy rendelést. Egy böngészős és egy szerveres Purchase eseményt kell látnod ugyanazzal az eseményazonosítóval. Egy harmadik Purchase vagy két különböző azonosító megmutatja az okot.
Sorold fel az összes eszközt, amely küldheti a pixelt
Nézd meg az értékesítési csatorna appokat, a címkekezelő konténereket, a sablonkódot és a régebbi követő appokat. Egy böngészőbővítmény, például a Meta Ads Data Advisor, korábbi nevén Meta Pixel Helper, megmutatja, mely pixelesemények futnak le egy oldalon.

Az első lépés a leggyorsabb ellenőrzés. Az egyetlen küldővel rendelkező forrás rendelésenként legfeljebb egy vásárlást küld. A böngészős szám általában alacsonyabb a rendeléseidnél a reklámblokkolók és az elutasított hozzájárulás miatt. Így ha egyetlen forrásban több vásárlás van, mint rendelés, az egy második küldőre vagy ismétlődő eseményekre utal:

Forrás (példa webáruház, egy nap)	Vásárlások	Webáruház-rendelések	Arány	Mire utal
Meta, böngésző	186	120	1.55	Több vásárlás, mint rendelés: két eszköz is elsüti a böngészőpixelt
Meta, szerver	119	120	0.99	Normális: egy szerveroldali küldő
TikTok, szerver	241	120	2.01	Minden rendelés kétszer: két app küldi az Events API-t

Források szerinti számok, deduplikáció előtt. Az 1.0 feletti arány azt jelenti, hogy a forrás néhány rendelést kétszer küld. A 2.0 körüli arány azt jelenti, hogy szinte minden rendelést kétszer küld.

Hogyan javítsd ki a duplikált vásárlási eseményeket

Pixelenként tarts egy küldőt. Válassz egy eszközt minden pixelhez, és kapcsold ki azt a pixelt mindenhol máshol: az értékesítési csatorna appokban, a címkekezelő címkéiben és a sablonkódban. Shopifyon töröld ugyanazt a pixelt a Facebook & Instagram csatorna adatmegosztási beállításaiból, mert minden adatmegosztási szint továbbra is küldi a böngészőpixelt. A TikTok appot ugyanígy ellenőrizd.
Rendelésenként egy eseményazonosítót használj. Képezd az azonosítót a rendelésazonosítóból, és küldd el a böngészőeseménnyel és a szervereseménnyel is.
Ugyanazt az eseménynevet használd. A böngészőnek és a szervernek ugyanúgy kell elneveznie az eseményt, pontosan úgy, ahogy a platform definiálja.
Az időablakon belül küldj. A napokkal később érkező szerveresemény nem kerül összevonásra. A Metán, a TikTokon és a Pinteresten az ablak 48 óra, a Redditen két nap.
Minden változtatás után teszteld újra. Ismételd meg a tesztrendelést, és másnap vesd össze újra a számokat.

Hogyan kerüli el a ROASaurus a duplikált vásárlási eseményeket

A ROASaurus minden vásárlást a webáruház rendelési adataiból küld el, és a böngészős és a szerveres példánynak ugyanazt az eseményazonosítót adja, amely a rendelésazonosítóból épül fel. Shopifyon a szerveresemény a kifizetett rendelés webhookjából érkezik, ezért a köszönőoldal újratöltése nem hoz létre új szervereseményt. Az Event log platformonként felsorolja az összes szerveroldali kézbesítést a kéréssel és a platform válaszával, így láthatod, mi ment el az egyes rendelésekhez. A teljes folyamatot a szerveroldali követés Shopifyon című útmutató mutatja.

Ha egy platform még mindig több vásárlást mutat, mint rendelést, akkor egy másik eszköz küldi ugyanazt a pixelt. A A dupla számolás megelőzése felsorolja, hol keresd, a szerveroldali követés pedig elmagyarázza, melyik eseményeket küldi a ROASaurus az egyes platformoknak.

Források

A ROASaurusban

Olvass tovább

KövetésReklámblokkolók és követés: mit veszít a webáruházadA reklámblokkolók megállítják a követőpixeleket, így a hirdetési platformok nem látják a vásárlásokat. Nézd meg, mely események vesznek el, miért nem vesznek el a szerveroldali események, és hogyan mérheted meg, mennyit veszítesz.KövetésConsent Mode v2 és GDPR: mit küldhet egy webáruházConsent Mode v2 webáruházaknak: a Google négy hozzájárulási jelzése, mit kér az uniós jog, és mit küldhet még a szerveroldali követés. Csak általános tájékoztatás.KövetésSafari ITP és hirdetéskövetés: mi működik mégA Safari ITP a szkriptek által beállított sütiket 7 napra korlátozza, egyes hirdetési kattintások után pedig 24 órára. Nézd meg, mit jelent ez az attribúcióra nézve, és melyik követés működik még.