Wix Cookie Consent Banner Integrációs Útmutató: Beépített CMP, Velo és Harmadik Féltől Származó Beágyazások 2026-ban
A Wix az alapértelmezett webplatform több száz millió kisvállalkozás, alkotó és üzemeltető számára, akiknek nincs mérnöki csapatuk, és nem is akarnak egyet. A platform ereje pontosan abban rejlik — egy hosztolt webhelykészítő, ahol az alapul szolgáló infrastruktúra, a fizetésfeldolgozás, a tartalomkezelés és egyre inkább a marketingverem el van vonva a webhelyet ténylegesen üzemeltető személytől. Ez az absztrakció az is, ahol a Wix hozzájárulási kockázatai koncentrálódnak. A platform beépített cookie-hozzájárulási bannert szállít, amelyet az üzemeltető néhány kattintással engedélyezhet; a banner kielégíti azt a felszíni szintű kérdést, hogy létezik-e egy banner; és az üzemeltető továbblép. A nehezebb kérdések — hogy a banner valójában megakadályozza-e a tagek tüzelését a hozzájárulás előtt, hogy a harmadik féltől származó HTML-beágyazások és Velo-kód helyesen vannak-e kapuzva, hogy a hozzájárulási napló auditálható-e, hogy a határon átnyúló adattovábbítás közzététele pontos-e — ritkán merülnek fel, és egy Wix-oldal, amely nem tette fel ezeket a kérdéseket, nem elégíti ki a GDPR-t, az ePrivacy-t vagy azokat a regionális rezsimeket, amelyek ezekkel összhangba kerültek. Ez az útmutató végigvezet azon, mit kell konfigurálni és mit kell hozzáadni ahhoz, hogy egy 2026-os Wix telepítés védhető pozíciót érjen el.
Mit tesz valójában a Wix beépített cookie-hozzájárulási bannere
A Wix Cookie Consent Banner — amely minden Wix-oldalon elérhető a Settings, Privacy & Compliance alatt — az egyik legtöbb képességgel rendelkező natív hozzájárulási eszköz, amelyet bármely hosztolt platform szállít. Kategóriánkénti opt-in-t támogat az Essential, Functional, Analytics és Advertising kategóriák között, konfigurálható úgy, hogy explicit megerősítő műveletet igényeljen, többnyelvű tartalmat támogat a webhely fordítási rétegén keresztül, és natívan integrálódik a hozzájárulási politikával, amelyet a Wix saját Marketing Apps-je tiszteletben tart. Amikor az üzemeltető úgy konfigurálja a bannert, hogy hozzájárulást igényeljen, és engedélyezi a kategóriánkénti vezérlőket, a Wix natív integrációi — Wix Analytics, a Facebook Pixel integráció, a Google Ads integráció, a Google Tag Manager integráció, a Hotjar integráció — tiszteletben tartják a felhasználó döntését további bekötés nélkül.
Amit a banner nem tesz meg, és ahol a leggyakoribb megfelelési hiba bekövetkezik, az a harmadik féltől származó szkriptek kapuzása, amelyeket az üzemeltető a Wix Custom Code funkcióján, Velo-kódon vagy beágyazott HTML-widgeteken keresztül adott hozzá. A banner rögzíti a felhasználó döntését; az üzemeltető feladata ennek a döntésnek a leolvasása a hozzájárulási politikából és a Wix kezelt integrációs listáján kívül élő harmadik féltől származó logika feltételes végrehajtása. A minta egyszer beállítva működik, de nem automatikus.
Az alapértelmezett konfiguráció nem elegendő
Az alapértelmezett banner-konfiguráció, amikor az üzemeltető először engedélyezi, implicit hozzájárulás — a webhelylátogatás hozzájárulásnak minősül, amíg a látogató el nem utasítja. Ez a pozíció ismételt szabályozói megállapítások forrása volt a Wix-hosztolt oldalakkal szemben az EEA-ban, az UK-ban és a GDPR-ral összhangba került rezsimekben. Az üzemeltetőnek módosítania kell a konfigurációt, hogy explicit megerősítő hozzájárulást igényeljen, mielőtt nem alapvető cookie-kat állítanak be, alapértelmezés szerint ki kell kapcsolnia a kategóriánkénti kapcsolókat, és ellenőriznie kell, hogy az elutasítás opció legalább annyira kiemelkedő, mint az elfogadás opció a banner felhasználói felületén. Ez a három beállítás — explicit hozzájárulás, alapértelmezés szerint kikapcsolt, elutasítás kiemelkedő — az a minimum, amelyre egy Wix-oldalnak szüksége van ahhoz, hogy elérje azt a küszöböt, amelyet az EDPB 2023-as cookie-banner iránymutatásaiban meghatározott, és amelyet a 2026-os munkacsoport prioritásaiban megerősített.
Hogyan kezeli a Wix a hozzájárulást a motorháztető alatt
A Wix a látogató hozzájárulási állapotát egy hozzájárulási politikai objektumon keresztül teszi elérhetővé, amelyet a platform belső integrációi olvasnak, és amelyet az üzemeltető kódja a Velo fejlesztői platformon keresztül olvashat. A Velo API a hozzájárulási politikát a wixWindow.consentPolicy alatt teszi elérhetővé a front enden, és az egyenértékű modulon a back enden. A hozzájárulási politika egy strukturált objektumot ad vissza kategóriánkénti boolean jelzőkkel és egy időbélyeggel; az üzemeltető Velo-kódja vagy Custom Code-ja olvassa ezeket a jelzőket, mielőtt bármilyen nem alapvető harmadik féltől származó logikát inicializál.
A Wix által kitett hozzájárulási kategóriák a szokásos taxonómiához vannak leképezve. Az Essential a munkamenet-, kosár-, biztonsági és terheléselosztási cookie-kat fedi le, és nem igényel hozzájárulást. A Functional a preferenciákat, a nemrégiben megtekintett listákat és a hasonló nem alapvető, de nem nyomkövető tárhelyet fedi le. Az Analytics a Wix Analytics-t, a Google Analytics 4-et, a Microsoft Clarity-t és a hasonló mérőeszközöket fedi le. Az Advertising a Facebook Pixel-t, a Google Ads-t, a TikTok Pixel-t, a LinkedIn Insight-ot és a szélesebb marketing pixel készletet fedi le. A natív Wix Marketing Apps ezeken a kategóriákon automatikusan kapuz; mindent, amit az üzemeltető hozzáad, manuálisan kell kapuzni.
Az integrációs minta harmadik féltől származó beágyazásokhoz és Custom Code-hoz
A Wix-en működő minta négy részből áll. Először konfigurálja a beépített Cookie Consent Banner-t úgy, hogy explicit hozzájárulást igényeljen, állítsa alapértelmezés szerint ki a kategóriánkénti kapcsolókat, és biztosítsa, hogy az elutasítás opció legalább annyira kiemelkedő, mint az elfogadás. Másodszor, azonosítsa az összes harmadik féltől származó szkriptet, amelyet az oldal a Wix natív integrációs listáján kívül ad hozzá — ezek jellemzően a Settings, Custom Code-ban, Velo-kódmodulokban vagy beágyazott HTML-widgetekben élnek — és leltározza fel, hogy melyik hozzájárulási kategóriába esik mindegyik. Harmadszor, csomagolja be az egyes harmadik féltől származó szkripteket egy hozzájárulási ellenőrzésbe, amely a hozzájárulási politikát olvassa végrehajtás előtt. Negyedszer, biztosítsa, hogy a bannerből felszínre hozott adatvédelmi nyilatkozat tükrözze a tényleges harmadik féltől származó fogadókat, ne a generikus Wix sablon nyelvet.
- Custom Code a Settings alatt — az üzemeltetők általában a Google Tag Manager-t, további Facebook Pixel-eket, további Google Ads konverziós tageket, Hotjar snippeteket és híváskövetési szkripteket adnak hozzá a Custom Code-on keresztül. Mindegyiket a megfelelő Consent Mode beállítással kell konfigurálni a Custom Code felhasználói felületén — a Wix snippet-szintű hozzájárulási kategória kiválasztást tesz elérhetővé — hogy a snippet csak akkor töltődjön be, amikor a megfelelő kategóriát megadták.
- Velo-kód — a back-end és front-end Velo-kód képes olvasni a wixWindow.consentPolicy-t és feltételesen kiterjedni harmadik féltől származó API-kra. Minden Velo-modul, amely harmadik féltől származó végpontot hív meg események naplózásához, pixelek tüzeléséhez vagy adatok CRM-mel való szinkronizálásához, ellenőrizni kell a vonatkozó kategóriát a végrehajtás előtt.
- Beágyazott HTML-widgetek — harmadik felektől beágyazott HTML iframes (chat-widgetek, naptár-widgetek, közösségi beágyazások) jellemzően betöltik saját szkriptjeiket, amelyek saját cookie-kat állítanak be. A minta az, hogy az iframe-et egy Velo-vezérelt csomagolón belül kell renderelni, amely feltételesen szúrja be az iframe-elemet csak azután, hogy a vonatkozó kaput megadták.
- Wix Studio oldalak — a Wix Studio ugyanazt a hozzájárulási politikai mechanizmust örökli, de reszponzív dizájn- és fejlesztői módú funkciókat ad hozzá, amelyek megkönnyítik a Velo-stílusú hozzájárulási kapuzás karbantartását. Az integrációs minta azonos; a karbantartás ergonómiája jobb.
A Wix-specifikus megfelelési csapdák
Három minta tér vissza a Wix telepítéseknél, és ezek adják a szabályozók által megjelölt problémák nagy részét. Az első az üzemeltető által kezelt harmadik féltől származó Google Tag Manager konténer — az üzemeltető GTM-et telepít a Custom Code-on keresztül, majd tucat számra adja hozzá a tageket a GTM felhasználói felületén anélkül, hogy a Consent Mode v2-t konfigurálná magán a GTM-en belül. A Wix banner helyesen kapuzza a GTM-töltőt, de amint a GTM betöltődik, a benne lévő tagek további hozzájárulási ellenőrzések nélkül tüzelnek, hacsak a GTM-et nem konfigurálták a Consent Mode tiszteletben tartására. A javítás az, hogy engedélyezni kell a Consent Mode v2-t a GTM konténerben, és minden tag kiváltóját a megfelelő hozzájárulási jelhez kell kötni.
A második a beágyazott űrlapszolgáltató — Typeform, JotForm, Calendly és hasonlók —, amely saját cookie-kat tölt be analitikai és előkitöltési célokra. A Wix banner alapértelmezés szerint nem kapuzza a beágyazott widgetet; az üzemeltetőnek magát a widget-elemet kell kapuznia Velón keresztül, vagy a kattintásra-betöltés helyőrző mintát kell használnia, amely késlelteti az iframe betöltését, amíg a felhasználó nem lép kapcsolatba vele.
A harmadik a határon átnyúló adattovábbítás közzététele. A Wix hosztolási infrastruktúrája régiók között fut, beleértve az Egyesült Államokat, és az üzemeltető harmadik féltől származó fogadóinak nagy része máshol fut; a Wix által szállított adatvédelmi nyilatkozat sablon nem nevezi meg ezeket a joghatóságokat kifejezetten, és az üzemeltetőnek szerkesztenie kell a nyilatkozatot, hogy megnevezze az egyes fogadói régiókat. Az EDPB 2023-as útmutatása egyértelmű volt, hogy a generikus szolgáltatók által feldolgozott adatok megfogalmazás nem elegendő, és ugyanez a mérce vonatkozik a Wix-hosztolt oldalakra.
Érvényesítés és audit pozíció 2026-ra
Egy védhető Wix telepítésnek 2026-ban négy technikai ellenőrzésen kell átmennie. Először, egy EEA IP-címről kiszolgált tiszta böngészési munkamenetnek nulla nem alapvető cookie-t kell produkálnia, mielőtt a bannerre cselekedtek — nem csak nulla Wix-kezelt cookie-t, hanem nulla cookie-t minden Custom Code snippettől, Velo modulból és beágyazott widgettől. Másodszor, az elutasítási útvonalnak meg kell őriznie ezt az állapotot. Harmadszor, egy elfogadási útvonalnak csak azokat a tageket kell produkálnia, amelyekhez a felhasználó hozzájárult, és a Wix hozzájárulási naplójának az üzemeltető oldali naplóval együtt tartalmaznia kell a megfelelő rekordot. Negyedszer, a visszavonásnak azonnal meg kell állítania a további tag tüzeléseket, le kell jártatnia a hozzájárult munkamenet során beállított cookie-kat, és az opt-out-ot el kell terjeszteni minden downstream harmadik féltől származó fogadóhoz, amely saját állapotot tart fenn.
Az audit-napló elvárás az a terület, ahol a Wix fejlődik, de még mindig igényel üzemeltetői erőfeszítést. A platform rögzíti a hozzájárulási döntéseket saját naplójában, amely hozzáférhető a webhelytulajdonos számára, ami elegendő sok szabályozói kérdéshez. Azokhoz a telepítésekhez, amelyeknek teljesebb audit-naplóra van szükségük — banner verzió, kategória állapot, nyelv verzió és downstream-fogadó állapot — az üzemeltetőnek Velo-kódot kell hozzáadnia, amely hozzájárulási eseményeket ír egy lekérdezhető külső tárolóba. Egy Wix-oldal, amely helyesen konfigurálta a beépített bannert, kapuzott minden Custom Code és Velo útvonalat, szerkesztette az adatvédelmi nyilatkozatot, hogy megnevezze az egyes határon átnyúló fogadókat, és hozzáadta az audit-napló naplót, egy olyan Wix-oldal, amely a platform hosztolt-készítő egyszerűségét egy kiadó hozzájárulási pozíciójának védhető részévé alakította át a megfelelési kötelezettségből.