Blokkolják a reklámblokkolók a Meta pixelt?

Sok reklámblokkoló és adatvédelmi böngésző blokkolja. Ha a szkriptet blokkolják, attól a látogatótól nem érkezik böngészőesemény a Metához, de a rendelési adataidból szerveroldalon küldött vásárlások továbbra is megérkeznek.

Hány vásárló használ reklámblokkolót?

A közönségedtől, az eszközeidtől és az országaidtól függ, ezért egy általános szám keveset árul el a webáruházadról. A saját különbségedet úgy mérheted meg, hogy ugyanarra az időszakra összeveted a webes rendeléseket a pixeled által küldött Purchase eseményekkel.

Blokkolhatják a reklámblokkolók a szerveroldali követést?

A rendelési adatokból küldött vásárlást nem, mert az a kérés egy szerverről megy a platform API-jára. A blokkoló viszont megállíthatja a kattintásazonosítót elmentő böngészőszkriptet, ezért fontos a first-party gyűjtés.

A reklámblokkoló ugyanaz, mint a hozzájárulás megtagadása?

Nem. A hozzájárulás megtagadása a sütibanneren hozott döntés, amelyet a követésednek tiszteletben kell tartania. A reklámblokkoló a böngésző eszköze. Mindkettő csökkenti a pixelesemények számát, ezért külön mérd őket.

Kell még a pixel, ha szerveroldalon küldöm a vásárlásokat?

Igen, a blokkoló nélküli látogatók miatt. A pixel böngészési eseményeket és böngészősütiket ad hozzá, és ugyanazzal az event id-val a platform minden vásárlásnak egy példányát tartja meg.

Reklámblokkolók és követés: mit veszít a webáruházad

A legfontosabb tudnivalók

A reklámblokkolók szűrőlistákkal állítják meg a pixelszkripteket és azok kéréseit, így a hirdetési platform egyáltalán nem kap eseményt arról a böngészőről.
Egy letiltott pixel elveszíti az oldalmegtekintéseket, a kosárba tételeket és a vásárlásokat, és a vásárlás számít a legtöbbet, mert ez határozza meg a jelentett ROAS-t és a licitálást.
A rendelési adataidból szerveroldalon küldött vásárlásokat ez nem érinti, mert a vásárló böngészője nem küldi el őket.
A saját lemaradásodat úgy mérheted meg, hogy a webáruházad webes rendeléseit a böngészőpixel által küldött Purchase eseményekkel veted össze, nem a kampányoknak tulajdonított konverziókkal.
A szerveroldali követés nem tudja visszahozni azokat a böngészési eseményeket és kattintásazonosítókat, amelyeket sosem mentettek el, a first-party adatgyűjtés pedig csökkenti ezt a veszteséget.

A reklámblokkolók úgy állítják meg a követést, hogy megakadályozzák a hirdetési platform pixelszkriptjének, vagy az általa küldött kéréseknek a betöltődését a vásárló böngészőjében. Ilyenkor a platform sosem értesül az oldalmegtekintésről, a kosárba tételről vagy a vásárlásról, pedig a rendelés ott van a webáruházadban. A rendelési adataidból szerveroldalon küldött vásárlásokat ez nem érinti, mert a küldésükben nem vesz részt a vásárló böngészője.

Ez az útmutató elmagyarázza, hogyan működnek a reklámblokkolók és a böngészők adatvédelmi funkciói, mely eseményeket veszíti el a webáruházad, mit tud visszahozni a szerveroldali követés, és mit nem. Egy egyszerű módszerrel zárul, amellyel a saját webáruházadban is lemérheted a különbséget.

Hogyan állítják meg a reklámblokkolók a követőpixeleket?

A legtöbb reklámblokkoló szűrőlistákkal dolgozik. A szűrőlista szabályok hosszú sora, amelyek webcímeket illesztenek: ismert hirdetési és követőszkriptek domainjeit, útvonalait és fájlneveit. Ha egy oldal olyasmit kér a böngészőtől, ami megfelel egy szabálynak, a blokkoló megszakítja a kérést.

A legismertebb listák az EasyList a hirdetésekhez és az EasyPrivacy a követéshez. Olyan bővítményekkel működnek, mint az Adblock Plus, az AdBlock, a uBlock Origin és az AdGuard. Egy nagy hirdetési platform pixele könnyű célpont ezeknek a listáknak, mert sok különböző oldalon ugyanazt a szkriptet tölti be ugyanarról a domainről.

Az oldal betöltődikA sablonod tartalmazza a hirdetési platform pixelszkriptjét.

A blokkoló ellenőrzi a címetA szkript címe megfelel egy szűrőlista egyik szabályának.

A kérés megszakadA szkript sosem fut le, ezért nem jön létre esemény.

Hirdetési platformSemmit sem kap erről a látogatásról.

Egy letiltott pixel nem gyengébb eseményt küld. Egyáltalán nem küld eseményt.

Beépített védelemmel rendelkező böngészők

Egyes böngészők bővítmény nélkül is blokkolják a követőket. A Brave alapértelmezés szerint minden oldalon bekapcsolja a Shields funkcióját, amely blokkolja a harmadik felek hirdetéseit, követőit és az oldalak közötti sütiket. A Firefox privát ablakokban blokkolja az ismert, oldalak közötti követést végző domainekről érkező tartalmat, és a felhasználók szigorúbb beállításokat is választhatnak, amelyek minden ablakra érvényesek. A Safari Intelligent Tracking Prevention funkciója blokkol minden harmadik féltől származó sütit, és lerövidíti a szkriptek által beállított sütik élettartamát. A Safari ITP és hirdetéskövetés című útmutatónk elmagyarázza ezeket a korlátokat.

Hálózati szintű blokkolók

Vannak, akik egy egész eszközön vagy otthoni hálózaton blokkolják a követőket, DNS-alapú blokkolóval vagy követőszűrővel ellátott VPN-nel. Ezek a hálózat minden böngészőjében és alkalmazásában megállítják a követődomainek felé irányuló kéréseket. A böngésző váltása nem változtat az eredményen.

Mely eseményeket veszíti el a webáruházad?

Ha a pixelt blokkolják, az összes esemény elvész, amelyet abból a böngészőből küldött volna. A kár nem minden eseménynél egyforma.

Esemény	Mire használják	Elvész, ha a pixelt blokkolják?	Pótolhatják a rendelési adatok?
PageView, ViewContent	Az oldal látogatóiból épített közönségek, termék-retargeting	Igen	Nem
AddToCart, InitiateCheckout	Optimalizálás a vásárlást megkezdő vásárlók felé, kosár-retargeting	Igen	Nem
Purchase	Jelentett konverziók, ROAS, vásárlásoptimalizálás, értékalapú licitálás	Igen	Igen
Kattintásazonosító a céloldalon	A vásárlás összekötése a pontos hirdetési kattintással	Igen, ha a követőszkriptet is blokkolják	Nem, a böngészőben kell elmenteni

A vásárlás a legértékesebb esemény, és ez az, amit a rendelési adatok mindig pótolni tudnak.

Az elveszett böngészési események kisebbre szűkítik a retargeting-közönségeidet. Az elveszett vásárlások nagyobb kárt okoznak. A platform kevesebb konverziót jelent, a hirdetési riportban a ROAS lecsökken, a licitáló algoritmus pedig kevesebb vevőből tanul. Egy nyereséges kampány így veszteségesnek tűnhet, és előfordulhat, hogy lekapcsolod.

Miért nem blokkolják a rendelési adatokból küldött szerveroldali eseményeket

A reklámblokkoló a vásárló böngészőjében fut. Csak azokat a kéréseket tudja megállítani, amelyeket a böngésző küld. Ha a vásárlást a webáruházad rendelési adataiból küldik el, a kérés egy szerverről megy a hirdetési platform API-jára. A vásárló böngészője nem része ennek az útvonalnak, így a blokkolónak nincs mit megszakítania.

14:02:11 PageView pixelA böngészőben egy szűrőlista blokkolja

14:09:47 Purchase pixel order-1042Sosem kerül elküldésre, mert a pixelszkript nem töltődött be

14:09:52 webhook order-1042 paidA webáruház jelenti a kifizetett rendelést a szervernek

14:10:12 Purchase server order-1042Elküldve a Conversions API-nak hashelt e-mail-címmel és telefonszámmal

Példa: egy látogatás reklámblokkolóval. A böngésző semmit sem küld, a vásárlás mégis eljut a platformhoz a rendelésből.

A platform ezután az eseményben szereplő adatokkal párosítja a vásárlást egy személlyel: a rendelésből származó hashelt e-mail-címmel és telefonszámmal, az IP-címmel és a user agenttel, valamint a kattintásazonosítóval, ha el lett mentve. Ezek közül semmi sem megy át a blokkolón. A teljes adatútvonalról a mi a szerveroldali követés című útmutatóban olvashatsz.

Mit nem tud visszaszerezni a szerveroldali követés?

A kattintásazonosítóhoz böngésző kell

Maga a rendelés biztonságban van, de a hirdetési kattintással való összekötés a böngészőben történik. Egy szkriptnek ki kell olvasnia a kattintásazonosítót a céloldal URL-jéből, és el kell mentenie. Ha egy reklámblokkoló ezt a szkriptet is blokkolja, a rendelés kattintásazonosító nélkül érkezik meg. A platform ilyenkor is párosíthatja a vásárlást a hashelt ügyféladatok alapján, de az egyezés kevésbé biztos.

Két dolog csökkenti ezt a veszteséget. Először, gyűjtsd az eseményeket first-party módon: a követőszkriptet és annak kéréseit a saját domainedről szolgáld ki, például egy Shopify app proxyn vagy a webhelyed egyik aldomainjén keresztül. A szűrőlisták az ismert, harmadik féltől származó követőcímeket célozzák, így a first-party útvonalat sokkal nehezebb blokkolni, bár nem lehetetlen. Másodszor, használd azt a céloldalt, amelyet néhány webáruház-platform, például a Shopify, minden rendelés mellé eltárol. Ha ez az URL még tartalmazza a kattintásazonosítót vagy az UTM-eket, a rendelés böngészőesemény nélkül is hozzárendelhető a hirdetéshez.

A böngészési események így is elvesznek

A rendelési adatok rendeléseket tartalmaznak, nem oldalmegtekintéseket. A rendelésekből küldött vásárlások nem hozzák vissza azon látogatók oldalmegtekintéseit és kosárba tételi eseményeit, akiknek a böngészője mindent blokkolt. Egy first-party gyűjtő továbbíthatja ezeket az eseményeket a szerverről, ha a saját kérései átjutnak.

A megtagadott hozzájárulás nem blokkolás

Az a látogató, aki a sütibanneren elutasítja a marketingsütiket, nem ugyanaz, mint a reklámblokkolót használó látogató. Az első látogató döntött, és a követésednek ezt tiszteletben kell tartania. Ha a Respect visitor consent be van kapcsolva, a ROASaurus nem állít be látogatóazonosítót ennek a látogatónak, így a hirdetési kattintásai és látogatásai nem kapcsolódnak hozzá. A böngészőeseményei látogatóazonosító, IP-cím és böngészőadatok nélkül maradnak meg, és nem kerülnek elküldésre a hirdetési platformoknak. A kifizetett rendelést ettől még elküldjük szerveroldalon, a rendelésből származó hashelt ügyféladatokkal, valamint a rendelés IP-címével és user agentjével. A veszteséged mérésekor tartsd külön a két csoportot, a részletekért pedig lásd a hozzájárulás és adatvédelem részt.

Hogyan becsüld meg a saját veszteségedet

Nincs szükséged iparági átlagokra, amelyek a közönségtől, az eszköztől és az országtól függnek. A saját lemaradásodat úgy mérheted meg, hogy ugyanarra az időszakra összeveted a webáruházad rendeléseit a böngészőpixel által jelentett vásárlásokkal.

Válassz egy időszakot és egy platformot
Használj 14 vagy 30 napot és egy platformot, például a Metát. Mindkét rendszerben ugyanazt az időzónát használd.
Számold meg a webes rendeléseket a webáruházadban
Indulj ki az összes rendelésből. Vedd ki azokat, amelyek sosem mennek át az online pénztáradon: kasszás (POS) rendelések, kézi és piszkozat rendelések, előfizetés-megújítások és tesztrendelések.
Számold meg a böngészőből érkező Purchase eseményeket
A platform eseménykezelő eszközében számold meg azokat a Purchase eseményeket, amelyeket a böngészőpixel küldött. Ez a legegyszerűbb, mielőtt szerveroldali eseményeket adnál hozzá. Ha a szerveroldali események már futnak, használd a platform kapcsolati mód szerinti nézetét, ahol van ilyen. A Meta Events Manager megmutatja minden esemény kapcsolati módját, és a deduplikáció előtt számolja ott az eseményeket. Ne használd a hirdetési riport tulajdonított vásárlásait.
Oszd el
A böngészős vásárlások ÷ webes rendelések az az arány, amelyet a pixel látott. A maradék a különbség.
Válaszd szét a hozzájárulást és a blokkolást
Becsüld meg a marketingsütiket elutasító látogatók rendeléseit a hozzájárulás-kezelő eszközöd elutasítási arányával. A maradék többnyire reklámblokkolókból, adatvédelmi beállításokból és be nem töltődött oldalakból adódik.

Példa webáruház, 30 nap	Rendelések	A webes rendelések aránya
Az összes rendelés a webáruházban	1,240
Kasszás (POS), kézi és megújítási rendelések	−90
Webes rendelések	1,150	100%
Purchase események a böngészőpixelből	874	76%
Különbség	276	24%
Becsült rendelések a hozzájárulást megtagadó látogatóktól (10% elutasítási arány)	115	10%
Maradék: reklámblokkolók, adatvédelmi beállítások, be nem töltődött oldalak	161	14%

Ebben a példa webáruházban a pixel nagyjából 4 webes rendelésből 1-et elvét. Nagyjából minden 7 rendelésből 1 a blokkolás és a böngészőhibák miatt vész el, nem a hozzájárulás miatt.

A különbség a ROAS-t is megváltoztatja. Tegyük fel, hogy a Meta 2.0-s ROAS-t jelent ennél a webáruháznál, a megtérülési ROAS pedig 2.3. A pixeladatok alapján a kampányok veszítenek. Ha a hirdetések által hozott rendelések ugyanúgy 24%-os arányban maradtak ki, mint az összes webes rendelés, a pixel a hirdetési bevételnek csak a 76%-át látta. A valódi ROAS ekkor nagyjából 2.0 ÷ 0.76 = 2.6 lenne, ami a megtérülési pont felett van. Ez felső becslés, mert nem minden hiányzó rendelés származott hirdetésből. A megtérülési ROAS című útmutatónk elmagyarázza, hogyan állítsd be ezt a küszöböt.

Hogyan csökkentheted a veszteséget

A megoldások minden webáruház-platformon ugyanazok. Együtt működnek a legjobban.

Küldd el a vásárlásokat a rendelési adatokból. Ez minden csatlakoztatott platformon bezárja a vásárlási hiányt, bármit blokkol is a látogató böngészője.
Tartsd meg a pixelt, közös event id-val. A blokkoló nélküli látogatók továbbra is küldenek böngészőeseményeket sütikkel és oldalkontextussal. Ugyanaz az event id mindkét példányon lehetővé teszi, hogy a platform az egyiket megtartsa. Lásd a dupla számolás megelőzése részt.
Gyűjts first-party módon. A követőszkriptet és annak eseményeit a saját domainedről szolgáld ki, így a kattintásazonosítók több látogatónál mentődnek el.
Küldj hashelt ügyféladatokat. A rendelésből származó e-mail-cím és telefonszám lehetővé teszi, hogy a platform kattintásazonosító nélküli vásárlásokat is párosítson.
Mérj újra. Egy hónap múlva ismételd meg az összehasonlítást. A platform által fogadott Purchase eseményeknek most már egyezniük kell a webes rendeléseiddel.

Példa webáruház: a Meta által 30 nap alatt fogadott Purchase események

Csak pixelPixel + szerver, deduplikálva

Purchase események

874

1,150

Miután a vásárlásokat a rendelési adatokból küldik, mind az 1,150 webes rendelés eljut a platformhoz. A pixel továbbra is böngészőadatokat ad ahhoz a 874 rendeléshez, amelyet látott.

Hogyan kezeli a ROASaurus a reklámblokkolókat

A ROASaurus minden kifizetett rendelést szerveroldalon küld el azoknak a hirdetési platformoknak, amelyeket a Tracking & platforms alatt hozzáadsz, így a vásárló böngészőjében lévő reklámblokkoló nem állítja meg a vásárlást. Shopifyon a webáruház eseményei a Shopify app proxyján keresztül, a saját webáruház-domaineden mennek át. A szkriptet és az eseményeit a webhelyed egy CNAME aldomainjéről is kiszolgálhatod. Ha egy látogatónak nincs böngészős érintkezési pontja, a ROASaurus attribúciója a rendelés céloldali URL-jében lévő kattintásazonosítókra és UTM-ekre támaszkodik, ha a webáruház rögzít ilyet, ahogy a Shopify is teszi.

Minden kézbesítést és a platform válaszát az Event log sorolja fel, így ellenőrizheted, hogy minden rendelés eljutott-e minden platformhoz. A beállításhoz lásd a szerveroldali követést és a Shopify-integrációt.

Források

A ROASaurusban

Olvass tovább

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ésDuplikált vásárlási események: miért számolódnak kétszer az eladásokA duplikált vásárlási események felfújják a konverziókat és a ROAS-t. Nézd meg az okokat, hogyan deduplikál a Meta, a TikTok, a Snapchat, a Pinterest és a Reddit, és hogyan javíthatod ki.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.