Lassú remarketing lista épülés iPhone és Safari alatt

A „lassú remarketing lista” jelenségre sokan úgy reagálnak, mintha egy kampánykezelési hiba volna: rossz közönségbeállítás, hibás címke, rossz fiók-összekötés, vagy egyszerűen „a Google megint vacakol”. A valóság ennél kellemetlenebb, ugyanakkor felszabadítóbb is: a remarketing listaépülés sebessége ma már gyakran a böngésző- és platformkörnyezet következménye. A mérés nem a te tulajdonod, mert az adatot nem te generálod, hanem a felhasználó eszköze és böngészője engedi át – részben, feltételekkel, időkorláttal. A Safari és az iOS/macOS környezetben futó WebKit-alapú böngészés azért különösen érzékeny, mert a böngésző célzottan védi a felhasználót a cross-site követéstől, és ennek részeként olyan technikai szabályokat vezet be, amelyek a hirdetési remarketing klasszikus építőköveit (cookie, helyi tárolók, URL-paraméterekből olvasott click ID-k) rövid pórázra fogják. A WebKit saját dokumentációja leírja, hogy a rendszer alapértelmezés szerint teljes körűen blokkolja a harmadik féltől származó cookie-kat, és több kapcsolódó védelmet is alkalmaz (például referrer-szűkítés, tárolók particionálása, külön szabályok a link-dekorációra, valamint időalapú törlések a szkripttel írható tárolókra).

A „lassú lista” a gyakorlatban általában nem azt jelenti, hogy senki nem kerül be. Inkább azt jelenti, hogy a forgalmadhoz képest aránytalanul kevés ember válik elérhetővé remarketingre, és a lista nem úgy nő, ahogy régen: nem ér fel az elvárt szintre, vagy felér, majd feltűnően hamar „visszaesik”, mintha lyukas vödörbe töltenél. Ennek a jelenségnek több rétege van. Az egyik réteg az, hogy a böngésző harmadik félként nem engedi a hirdetési azonosítók tárolását, így a klasszikus remarketing mechanizmusok sok kísérletből kevesebb „tartós” felhasználót tudnak képezni. A másik réteg a tárolási idő: a WebKit ITP modellje a szkripttel írható tárolókat (például JavaScript által létrehozott cookie-kat és más tárolókat) bizonyos feltételek mellett törli, ha nincs valódi felhasználói interakció egy adott időablakon belül. Ez a remarketingnél azért fáj, mert a remarketing definíció szerint késleltetett visszaterelés: nem a látogatás pillanatában, hanem napokkal később akarsz újra megszólítani. Ha a böngésző pont azt csinálja, hogy a késleltetés közben „elfelejt”, akkor a marketinged nem gyengül azért, mert rossz a kreatív, hanem azért, mert a technikai támasza rövidül. Ilyenkor a legnagyobb hiba az, ha a csapat kizárólag kampányoptimalizálással próbálja megoldani azt, ami mérési és adatgyűjtési környezet-probléma. Az első lépés szemlélet: a remarketing nem rosszabb lett, a mérés lett szigorúbb, és ehhez kell felnőtt, üzleti döntéshozói módon alkalmazkodni.

Hogyan kerül be valaki egy remarketing listába

Ahhoz, hogy gyorsabban és tisztábban diagnosztizálj, érdemes fejben szétszedni a remarketinget apró, ellenőrizhető lépésekre. Egy webes remarketing lista tipikusan úgy épül fel, hogy az oldaladon fut egy mérőkód (például Google tag), ez oldalbetöltéskor vagy eseményeknél kéréseket küld a mérési rendszernek, és közben azonosítókat kezel a böngészőben. A böngészőben tárolt jel (cookie vagy tároló) nem csak „szám” a rendszerben; ez maga a híd a későbbi felismeréshez. A hirdetési remarketing célja, hogy a későbbi böngészési helyzetben – amikor már nem az oldaladon van az user – a rendszer mégis tudja: ő az, aki korábban járt nálad. Ez a felismerés a modern adatvédelmi környezetben nem automatikus, mert több szűrőn kell átmenni: kell, hogy a címke tényleg lefusson; kell, hogy a böngésző tényleg engedje a releváns tárolást; kell, hogy a felhasználó a hirdetési személyre szabást ne tiltsa olyan módon, ami a remarketinget kizárja; és kell, hogy a lista a platform által elérhetővé tett minimumszinteket elérje. A Google Ads súgója például leírja, hogy a különböző hálózatokon a megjelenítéshez minimum aktív felhasználói szint kell az elmúlt 30 napban (publikus dokumentációban 100 aktív felhasználó szerepel több nagy felületnél). Ez a gyakorlatban azt jelenti, hogy kis forgalomnál a lista technikailag „létezik”, mégis üzletileg használhatatlan marad, mert nem indítható vele úgy kampány, ahogy szeretnéd.

A másik nagy csapda az, hogy sokan összemossák a mérési közönségeket (például analitikai közönségek) és a hirdetési rendszeren belül ténylegesen „remarketingre alkalmas” közönségeket. A Google Analytics saját súgója kimondja, hogy az analitikában látható közönségméret a feltételeket teljesítő felhasználók száma, míg a hirdetési rendszerekben ennek csak a „remarketable” része jelenik meg, és ezt több beállítás, felhasználói preferencia, valamint adatkezelési döntés befolyásolhatja. Ide tartozik például, hogy közönségexporthoz a Google signals vagy a user-provided data collection valamelyikének engedélyezése szükséges, és a hirdetési személyre szabás a fiók-összekötés szintjén is kapcsolható. Ebből következik egy egyszerű, üzletileg nagyon fontos tanulság: lehet sok látogatód és lehet értelmezhető analitikai képed, miközben a remarketing lista mégis sovány marad. Ilyenkor nem az a helyes kérdés, hogy „miért nem működik a remarketing”, hanem az, hogy „a látogatóim mekkora része válik hirdetési szempontból elérhetővé, és ezen milyen legitim, adatvédelmi szempontból tiszta eszközökkel tudok javítani”.

Diagnosztikai miniteszt (gyors, őszinte):

Ha azt látod, hogy a lista lassú, tedd fel magadnak ezt az öt kérdést, és ne engedd, hogy a csapat „érzésre” válaszoljon.

• Az oldal látogatóinak mekkora aránya érkezik iOS/Safari környezetből (külön mobil és desktop bontásban)?
• A remarketing címke futása valós felhasználóknál is stabil, vagy sok kérés el sem jut a mérési végpontra (szkriptblokkolás, hálózati szűrés)?
• A közönség export és a hirdetési személyre szabás engedélyezése rendben van a fiók-összekötéseken?
• A közönség mérete eléri a platform minimumát az elmúlt 30 napban, vagy csak „létezik a lista” státuszban van?
• A remarketing időablaka (membership duration) reális a böngészős tárolási időkhöz képest, vagy eleve hosszabb, mint amit a környezet tartósan bír?

Mit csinál az ITP technikailag

Az ITP-t sokan egyetlen mondatban próbálják elintézni („blokkolja a cookie-kat”), pedig a lényeg abban van, hogy milyen cookie-t, milyen kontextusban, milyen időtávon, és mi történik akkor, ha a rendszer tracking-képességűnek minősít egy domaint. A WebKit dokumentációja szerint az ITP alapértelmezés szerint teljes körűen blokkolja a harmadik féltől származó cookie-kat, és erre nincsen általános kivétel, a hozzáférést legfeljebb speciális mechanizmusokkal (például Storage Access API irány) lehet feloldani. Ugyanez a dokumentáció leírja, hogy a WebKit a „Prevent cross-site tracking” beállítás részeként már régóta szigorúan kezeli a third-party cookie-k kontextusát: a harmadik fél alapból nem tud új cookie-t létrehozni third-party helyzetben, amíg first-party környezetben nem került „bevezetésre”. Ez a hirdetéstechnikai világban azért fáj, mert a reklámrendszerek klasszikus működése történetileg arra épült, hogy a third-party kontextusban is elegáns módon el tudnak helyezni azonosítókat. Ma ez a pálya beszűkült.

Az ITP nem csupán tárolást tilt, hanem mintázatokat is figyel: a dokumentáció részletesen leírja, hogy a WebKit statisztikákat gyűjt a cross-site viselkedésről, és ha egy registrable domain elég sok különböző first-party oldalon jelenik meg erőforrásként, iframe-ként, vagy elég gyakran vesz részt cross-site átirányításokban, akkor „cross-site tracking capabilities” minősítést kaphat. A rendszer a bounce tracking (top frame redirect) jellegű mintákat külön is figyeli, és van olyan logika is, amely „tracker collusion” alapján más domainokat is besorolhat, ha azok visszatérően továbbítanak egy már besorolt domainre. A besorolás nem elméleti játék: a WebKit ugyanitt leírja, hogy a besorolt domainekhez kötődő website data törlése megtörténhet, ha nem volt felhasználói interakció first-party helyzetben egy adott időablakon belül. Ezzel párhuzamosan a WebKit leír egy külön mechanizmust a link decoration jelenségre is: amikor click ID-k paraméterként kerülnek átadásra, és a céloldal JavaScript segítségével beolvassa, majd eltárolja őket, az ITP ezt képes észlelni, és ilyenkor a landing oldalon JavaScript által létrehozott cookie-k lejáratát 24 órára korlátozhatja. Ez nem csak „adatvédelmi dísz”: ez a remarketing időtávját vágja el, mert a hirdetési újramegszólítás tipikusan több napos gondolkodási és döntési folyamatokra épül.

A harmadik, remarketing szempontból legkegyetlenebb rész a WebKit dokumentációban az úgynevezett „7-day cap on all script-writeable storage”. A leírás szerint az ITP törli a JavaScript által létrehozott cookie-kat, és más szkripttel írható tárolókat (például LocalStorage, IndexedDB, Service Worker cache) 7 nap után, ha nem történt felhasználói interakció a webhellyel. A dokumentációban az „interaction” definíciója is konkrét (kattintás, billentyű, tap), és ez azért fontos, mert sok vállalkozásnál a visszatérő látogatások jelentős része passzív: gyors információ-ellenőrzés, olvasás, összehasonlítás, majd kilépés. Ha nincs valódi interakció, a tároló „óra” nem feltétlen áll vissza, így a remarketing építése matematikailag is falnak tud menni. Ez az a pont, ahol üzletileg tisztán érdemes kimondani: ha a célod 30–90 napos remarketing, és a célcsoportod jelentős része iPhone/Safari felhasználó, akkor a klasszikus böngészős azonosítókra épített újramegszólítás sok esetben specializált technikai megoldások nélkül nem fogja hozni a korábbi korszak adatait.

Összefoglaló táblázat: ITP mechanizmus és remarketing következmény

Miért látsz GA4-ben felhasználót, mégis kevés a lista

Ez a pont az, ahol a legtöbb üzleti tulajdonos frusztrált lesz, mert „minden ott van”: van forgalom, a GA4-ben látszanak a sessionök, események, sőt konverziók is, miközben a Google Ads közönségei üresek vagy lassan kúsznak. Ennek a jelenségnek a megértéséhez szükség van egy felnőtt kompromisszumra: a mérés és a hirdetési újramegszólítás ma már nem ugyanaz a sportág, még ha ugyanaz a cég termékei is vannak a háttérben. A Google Analytics saját súgója egyértelműen különbséget tesz az analitikai közönségméret és a hirdetési rendszerekben megjelenő közönségméret között: a hirdetési oldalon csak a „remarketable” rész számít, és ezt érintik a felhasználói hozzájárulások és a hirdetési személyre szabás beállításai. A dokumentáció arról is beszél, hogy közönségexporthoz szükséges, hogy a Google signals vagy a user-provided data collection engedélyezve legyen, és ha a Google signals regionálisan tiltott egy adott területen, onnan származó adatok nem kerülnek be a Google Ads felé exportált közönségekbe. A magyar piacon ennek külön súlya van, mert a vállalkozások jelentős része európai forgalommal működik, ahol a hozzájárulási és személyre szabási döntések általában szigorúbbak, és a mérés sokszor konzervatívabb beállítások mellett fut.

A második réteg a Google Ads saját definíciós világa. A Google Ads közönség szempontból nem „összes felhasználót” akar látni, hanem olyan felhasználókat, akik a hirdetési rendszerekben ténylegesen megszólíthatók. A Google Ads súgója külön kiemeli, hogy az „Active users” fogalom a hirdetési jogosultság kontextusában értelmezett szám, és eltérhet a Google Analytics riportjaiban látott totál felhasználói számtól, valamint azt is leírja, hogy a megjelenítéshez hálózattól függő minimum aktív felhasználószámra van szükség az elmúlt 30 napban. Amikor a listád lassú, gyakran két dolog történik egyszerre: (1) a Safari/ITP miatt csökken a tartósan azonosítható és exportálható felhasználók aránya; (2) a maradék még nem éri el a minimumot, így kampányszinten nem indítható vagy nem fut stabilan, ezért te úgy érzékeled, hogy „nem épül”. Ez egy tipikus magyar KKV-s csapda: a forgalom nem óriási, a célpiac kisebb, a konverziós ciklus több napos, közben a böngésző rövidíti az emlékezetet. A végeredmény: listád mérete nem a forgalmad tükre, hanem a méréstechnikai és jogosultsági szűrők utáni maradék.

Mérési és adatgyűjtési megoldások 2026-ban

Amikor a lista lassú, a „javítsuk meg” típusú megközelítés helyett egy háromszintes döntést javaslok: (A) mit lehet rendbe tenni az alapokon, mert egyszerűen hibás vagy hiányos; (B) milyen, a böngészős korlátokkal kompatibilis méréstechnikai fejlesztések adnak vissza elérhetőséget; (C) milyen üzleti és csatorna-stratégiai változtatásokkal csökkented a remarketing függőséget. Az A szint sokszor meglepően prózai: a tag nem minden oldalon van; események nem futnak; a közönségfeltételek túl szűkek; a fiókösszekötésen a hirdetési személyre szabás tiltva van; a közönségexporthoz szükséges analytics beállítás hiányzik. A Google Analytics dokumentációja például konkrétan kimondja, hogy közönségexporthoz kell a Google signals vagy a user-provided data collection, és a link-szintű személyre szabási kapcsoló is döntő. Ebből következik: mielőtt technológiát vásárolsz, auditáld a saját konfigurációdat. Dajka Gábor tapasztalata szerint a „lassú lista” legalább felénél az alapbeállítások között is van olyan elem, ami részben vágja a listát – és ezt azért nem veszik észre, mert a GA4 ettől még szépen „mér”.

A B szint már érdekesebb: itt olyan megoldások jönnek, amelyek a böngészős szkriptblokkolás és a third-party korlátozások mellett stabilabb jelvisszanyerést adnak. A Google 2026. január 31-i frissítéssel ellátott fejlesztői dokumentációja bemutatja a Google tag gateway for advertisers megoldást, amelynek lényege, hogy a tag kiszolgálása és bizonyos mérési kérések első félként, a saját domainről történhetnek, egy köztes infrastruktúrán keresztül (CDN, load balancer, webserver). Ez két szempontból üzletileg hasznos: (1) a kérések egy része kevésbé hasonlít „külső” trackerre hálózati és szkript-szinten; (2) a mérés konfigurációja – legalább részben – tartósabb, mert a rendszer a saját infrastruktúrádon át kommunikál. Fontos felnőtt mondat: ez nem „feltöri” a böngészőt, és nem ad jogot arra, hogy a felhasználói döntéseket megkerüld. A célja inkább az, hogy a saját mérésedet a saját domainkörnyezetedhez közelebbre hozd, és csökkentsd a pusztán technikai veszteséget. ITP mellett ez azért releváns, mert a WebKit dokumentációjában több védelem együtt él: third-party cookie blokkolás, link-dekoráció, script-writeable tároló törlés. Minél inkább a first-party kontextusodra építesz, annál több esélyed van arra, hogy legalább a legitim, hozzájárult mérésed stabilabb legyen.

A B szint másik pillére a szerveroldali címkézés (server-side tagging). A Google fejlesztői anyaga úgy írja le, hogy ez a megközelítés a mérési adatfeldolgozást a felhasználó böngészője helyett egy általad kontrollált szerverre helyezi át, és a szerver containeren belül döntöd el, milyen események merre menjenek tovább. A dokumentáció azt is hangsúlyozza, hogy a szerver saját környezetedben fut, és te döntesz az adat alakításáról és továbbításáról. Ez remarketing szempontból azért érdekes, mert a böngészőoldali szkriptek blokkolása és instabilitása mellett a szerveroldali réteg képes javítani a jel minőségét: kevesebb „széttörő” esemény, tisztább paraméterezés, és jobb kontroll az adatvédelmi szabályok felett. Itt is igaz a józanság: ITP mellett a böngésző tárolóinak korlátai nem tűnnek el, mert a felhasználó eszközén van a gate. Viszont a szerveroldali megoldások képesek arra, hogy a hozzájárult és jogszerűen gyűjtött jelből több hasznos, konzisztens adatot csináljanak, és azzal legalább a kampányoptimalizálás tanulása, valamint bizonyos mérések stabilitása javuljon. Üzletileg ezt úgy fordítom le: a szerveroldali réteg nem fogyasztói elérés-növelő eszköz, hanem adatminőség és kontroll eszköz, ami a remarketing környezetében is érték, főleg akkor, ha a böngészőid egy része agresszíven szűr.

A B szint harmadik pillére az enhanced conversions. A Google Ads súgója leírja, hogy enhanced conversions esetén a konverziókor rendelkezésre álló first-party ügyféladatok (például e-mail, telefonszám, név, cím) a címkén keresztül hash-elve továbbíthatók a rendszer felé, és ez segíthet a konverziómérés javításában, mert a hash-elt adatok Google-fiókokhoz történő egyeztetése révén több konverzió kapcsolható vissza a hirdetési érintéshez. Ez a remarketing közönségek szempontjából nem ugyanaz, mint a klasszikus „site visitors” lista, mégis stratégiailag ide tartozik: ha a böngészős azonosítók bizonytalanok, a first-party azonosítók szerepe felértékelődik. A magyar KKV-knál ez tipikusan hírlevél, ajánlatkérés, regisztráció, kosárfolyamat, érdeklődői form, ügyfélszolgálati kapcsolatfelvétel. Itt egyszerre kell üzleti, technikai és etikai döntést hozni: csak olyan adatot küldesz, amire valóban szükséged van, és csak olyan helyzetben, ahol a felhasználó informált módon beleegyezett. A jó hír, hogy ez a világ a hosszú távú vállalkozások felé tol: akik képesek saját ügyfélkapcsolatot építeni, azok kevésbé függnek a böngésző emlékezetétől.

Akcióterv (30 napos, reális KKV-tempóban)

Stratégiai alkalmazkodás, ha a klasszikus remarketing plafonba fut

Most jön a rész, amit sokan nem szeretnek hallani, mert felelősséget kér: ha az iPhone/Safari arány magas, akkor a remarketinget stratégiailag át kell csomagolni. Nem azért, mert a remarketing „halott”, hanem azért, mert a böngésző emlékezete rövidebb, és a hirdetési jogosultság is szűkebb. Ilyenkor a legérettebb döntés az, hogy a remarketinget a döntési ciklushoz és a mérési realitáshoz igazítod. Gyakorlati szinten ez három dolgot jelent. Először: rövidebb ablakokkal dolgozol, és a közönségszegmenseket úgy építed, hogy gyorsabban elérj használható méretet. A platform minimumai (például 100 aktív felhasználó az elmúlt 30 napban több felülethez) eleve azt üzenik, hogy mikro-listákkal sokszor nem fogsz boldogulni. Másodszor: az on-site viselkedést átalakítod úgy, hogy több legyen a valódi interakció, mert az ITP interakció definíciója konkrét, és a tároló-törlési logikák interakcióhoz kötődnek. Ez nem manipuláció; ez usability és üzleti logika: akkor van esélyed konverzióra, ha a felhasználó valóban foglalkozik az ajánlattal, kér, visszakérdez, összehasonlít, kalkulál, letölt. Harmadszor: a remarketinget nem egyetlen retargeting listára bízod, hanem több, egymást kiegészítő csatornára és first-party kapcsolatra.

A következő szint az, amikor a remarketinget a vállalkozás „saját csatornái” felé tolod. A böngésző emlékezete rövidül, viszont a saját ügyfélkapcsolatod hosszabbítható: e-mail, ügyfélfiók, hűségprogram, ajánlatkérés, időpontfoglalás, letöltött anyag, webinár, közösség. Sok cég azért ragaszkodik a klasszikus remarketinghez, mert kényelmes: a rendszer „megy magától”, és a célzás automatikus. Csakhogy ennek ára van: ha a platformkörnyezet szigorodik, a kényelmi megoldások skálázhatósága csökken. A Google saját dokumentációi is abba az irányba mutatnak, hogy a first-party jel, a hozzájárulás, és az exportálható, személyre szabásra engedett adat szerepe nő: közönségexport feltételek, user-provided adatgyűjtés, enhanced conversions, első félként kiszolgált tagkörnyezet. Üzletileg én ezt úgy fordítom le, hogy a remarketinget nem dobnám ki, viszont a vállalkozás értékének építését nem tenném függővé attól, hogy a Safari hány napig emlékszik a cookie-ra. Aki hosszú távra épít, annak a remarketing csak egy eszköz a sok közül, és nem a bevétel egyetlen biztosítéka.

Dajka Gábor marketingszakértő, business coach és befektető szerint

Ha van egy mondat, amit ma minden vállalkozónak meg kell értenie a remarketingről, akkor ez: a digitális marketing nem visszamegy 2016-ba, és nem is lesz újra olyan, mintha a böngészők nem védenék a felhasználót. A WebKit dokumentációja világosan leírja, mennyire rendszerszintű a cross-site tracking elleni védelem, és a Google dokumentációja is világosan jelzi, hogy a hirdetési közönségek és exportálható, személyre szabásra alkalmas felhasználók világa szűrőkkel működik. Ilyen környezetben a jó vezetői döntés az, hogy két dolog párhuzamosan fut: stabilizálod a mérést a legitim eszközökkel (first-party kiszolgálás, szerveroldali réteg, enhanced conversions ott, ahol van erre jogalap és hozzájárulás), közben csökkented a remarketing-függőséget azzal, hogy erősítesz egy olyan ajánlatot és ügyfélutat, ami saját csatornákon is képes visszahozni az érdeklődőt. Aki csak a böngészős azonosítókra építi a teljes növekedést, az valójában nem remarketinget épít, hanem kiszolgáltatottságot. Aki viszont beleteszi az üzleti munkát az ajánlatba, a pozicionálásba, a tartalomba, a customer experience-be, és közben méréstechnikailag is felnőtt, az nyer a következő években. Itt illik megemlítenem azt a szemléletet, amit a „Online marketing és pszichológia” című könyvemben is képviselek: a magyar mikro- és kisvállalkozó nem engedheti meg magának, hogy a globális óriások kényelmi taktikáit másolja gondolkodás nélkül. Kisebb piac, szűkebb közönségek, tőkeérzékeny működés, közben a technológiai környezet folyamatosan szigorodik. Ehhez nem kapkodás kell, hanem stratégiai gondolkodás, tiszta mérési alapokkal.

„A remarketing ma már nem csak kampánykérdés. A remarketing az a pont, ahol a technológia, az etika és az üzleti modell találkozik. Aki ezt nem kezeli egyben, az előbb-utóbb a saját adatai foglya lesz.” – Dajka Gábor

Szakértő válaszol – gyakori kérdések

Mi a különbség a GA4-ben látott közönség és a Google Ads-ben használható remarketing közönség között?

A különbség a „mérés” és az „elérhetőség” között van. A Google Analytics közönségméret azt mutatja, hogy hány felhasználó felel meg a feltételeidnek analitikai szinten. A Google Ads oldalán ebből csak az a rész jelenik meg, amely hirdetési szempontból remarketingre alkalmas, és ezt befolyásolják a hirdetési személyre szabás beállításai, a Google signals vagy user-provided adatgyűjtés állapota, valamint regionális és felhasználói preferenciák. Ezért fordul elő, hogy GA4-ben „sok”, Ads-ben „kevés”. A két termék ugyanazon ökoszisztémában van, mégis más szabályrendszert szolgál.

Mekkora lista kell ahhoz, hogy tényleg tudjak remarketing kampányt futtatni?

A gyakorlatban nem az a kérdés, hogy hány ember van „összesen” a listában, hanem hogy az elmúlt 30 napban hány aktív felhasználó számít a platform szerint elérhetőnek. A Google Ads súgója több nagy felületnél 100 aktív felhasználót jelöl minimumként, és azt is hangsúlyozza, hogy az „Active users” eltérhet a GA4-ben látott totál felhasználótól. Magyar KKV-knál ez azért fontos, mert a kisebb forgalom miatt gyakran nem a célzás a szűk keresztmetszet, hanem a minimum-jogosultsági szint elérése. Ilyenkor egyszerű közönségek, rövidebb ablakok és több gyűjtési pont (több releváns esemény) hozhatja el a használható állapotot.

Segít-e a server-side tagging abban, hogy iPhone/Safari alatt gyorsabban épüljön a remarketing lista?

Segíthet a jelminőség és a mérési stabilitás javításában, viszont nem érdemes tőle azt várni, hogy a böngésző korlátai eltűnnek. A WebKit oldali szabályok a felhasználó eszközén futnak, így az azonosítók tárolása és élettartama továbbra is korlátozott lehet. A szerveroldali címkézés előnye inkább az, hogy a hozzájárult eseményeket tisztábban és kontrolláltabban tudod feldolgozni, és csökkenteni tudod a kliensoldali szkriptblokkolásból adódó veszteséget. Ha a célod a remarketing közönség méretének növelése, a server-side réteg önmagában ritkán elég; akkor dolgozik jól, ha együtt jár first-party jelstratégiával és olyan üzleti folyamattal, ami több first-party adatot termel (feliratkozás, ajánlatkérés, belépés).

Mi a legjobb lépés egy átlagos magyar KKV-nál, ha a forgalom fele mobilról jön, és sok az iPhone?

Elsőként a mérési alapokat tenném rendbe, mert ez olcsóbb, mint bármilyen új technológia: közönségexport feltételek, hirdetési személyre szabási kapcsolók, tagfutás stabilitása, reális közönség-ablakok. Második lépésként a listák logikáját úgy alakítanám, hogy gyorsan elérjem a minimumot: több releváns esemény, egyszerűbb szegmensek, rövidebb ablakok. Harmadik lépésként elkezdeném építeni a first-party alapot: e-mail feliratkozás, ajánlatkérés, belépés, lead-minőség javítás, és ott, ahol megvan a jogalap és a hozzájárulás, jöhet az enhanced conversions. A hosszú távú nyereség az, amikor a remarketing nem a böngésző emlékezetén áll, hanem a vállalkozás saját rendszerén és ügyfélkapcsolatán.

Források

• WebKit – Tracking Prevention in WebKit (ITP leírás, mechanizmusok)
• Google Analytics súgó – Audience size differences between Google Analytics and Google Ads
• Google Ads súgó – About audience segments in Audience manager (minimum méretek, aktív felhasználók)
• Google Ads súgó – About enhanced conversions
• Google for Developers – Set up Google tag gateway for advertisers (first-party tag kiszolgálás)