Mitä Wixin sisäänrakennettu evästeiden suostumuksen banneri oikeasti tekee

Wix Cookie Consent Banner — saatavilla jokaiselle Wix-sivustolle Settings, Privacy & Compliance -kohdasta — on yksi kyvykkäimmistä natiivisuostumustyökaluista, joita mikään isännöity alusta toimittaa. Se tukee kategoriaperusteista opt-inia Essential-, Functional-, Analytics- ja Advertising-kategorioissa, voidaan konfiguroida edellyttämään nimenomaista myöntävää toimintaa, tukee monikielistä sisältöä sivuston käännöskerroksen kautta ja integroituu natiivisti suostumuspolitiikkaan, jota Wixin omat Marketing Apps noudattavat. Kun operaattori konfiguroi bannerin edellyttämään suostumusta ja ottaa käyttöön kategoriaperusteisen ohjauksen, Wixin natiivi-integraatiot — Wix Analytics, Facebook Pixel -integraatio, Google Ads -integraatio, Google Tag Manager -integraatio, Hotjar-integraatio — kunnioittavat käyttäjän valintaa ilman lisäkytkentää.

Mitä banneri ei tee, ja missä yleisin vaatimustenmukaisuuden epäonnistuminen tapahtuu, on niiden kolmansien osapuolten skriptien porttaus, jotka operaattori on lisännyt Wixin Custom Code -ominaisuuden, Velo-koodin tai upotettujen HTML-widgettien kautta. Banneri tallentaa käyttäjän valinnan; operaattorin tehtävä on lukea tuo valinta suostumuspolitiikasta ja ehdollisesti suorittaa kolmannen osapuolen logiikka, joka elää Wixin hallittujen integraatioiden listan ulkopuolella. Malli toimii, kun se on paikallaan, mutta se ei ole automaattinen.

Oletuskonfiguraatio ei riitä

Oletusbannerikonfiguraatio, kun operaattori ottaa sen ensimmäistä kertaa käyttöön, on implisiittinen suostumus — sivuston vierailu käsitellään suostumuksena, kunnes vierailija kieltäytyy. Tämä asema on ollut toistuvien viranomaislöydösten lähde Wix-isännöityjä sivustoja vastaan kaikkialla EEA:ssa, Yhdistyneessä kuningaskunnassa ja GDPR:n kanssa yhdenmukaistamissa järjestelmissä. Operaattorin on muutettava konfiguraatiota edellyttämään nimenomaista myöntävää suostumusta ennen muiden kuin välttämättömien evästeiden asettamista, asetettava kategoriaperusteisen kytkimet oletuksena pois ja varmistettava, että hylkäämisvaihtoehto on bannerin käyttöliittymässä vähintään yhtä näkyvä kuin hyväksymisvaihtoehto. Nämä kolme asetusta — nimenomainen suostumus, oletuksena pois, hylkäys näkyvä — ovat minimi, jonka Wix-sivusto tarvitsee ylittääkseen kynnyksen, jonka EDPB on asettanut vuoden 2023 evästeiden bannerin ohjeistuksessa ja vahvistanut vuoden 2026 työryhmän prioriteeteissa.

Miten Wix käsittelee suostumusta konepellin alla

Wix paljastaa vierailijan suostumustilan suostumuspolitiikkaobjektin kautta, jota alustan sisäiset integraatiot lukevat ja jonka operaattorin koodi voi lukea Velo-kehittäjäalustan kautta. Velo API näyttää suostumuspolitiikan wixWindow.consentPolicy -kohdan alla käyttöliittymässä ja vastaavan moduulin taustajärjestelmässä. Suostumuspolitiikka palauttaa jäsennellyn objektin, jossa on kategoriaperusteisia boolean-lippuja ja aikaleima; operaattorin Velo-koodi tai Custom Code lukee nämä liput ennen muiden kuin välttämättömien kolmannen osapuolen logiikan alustamista.

Wixin paljastamat suostumuskategoriat vastaavat standarditaksonomia. Essential kattaa istunto-, ostoskori-, turvallisuus- ja kuormantasausevästeet eikä vaadi suostumusta. Functional kattaa asetukset, äskettäin katsotut listat ja vastaavan muun kuin välttämättömän mutta ei-seurattavan tallennustilan. Analytics kattaa Wix Analyticsin, Google Analytics 4:n, Microsoft Clarityn ja vastaavat mittaustyökalut. Advertising kattaa Facebook Pixelin, Google Adsin, TikTok Pixelin, LinkedIn Insightin ja laajemman markkinointipikselivaraston. Natiivit Wix Marketing Apps portataan näissä kategorioissa automaattisesti; kaikki operaattorin lisäämä on portattava manuaalisesti.

Integrointimalli kolmansien osapuolten upotuksille ja Custom Code -koodille

Wixissä toimiva malli on neljässä osassa. Ensiksi, konfiguroi sisäänrakennettu Cookie Consent Banner edellyttämään nimenomaista suostumusta, aseta kategoriaperusteinen kytkin oletuksena pois ja varmista, että hylkäämisvaihtoehto on vähintään yhtä näkyvä kuin hyväksyminen. Toiseksi, tunnista jokainen kolmannen osapuolen skripti, jonka sivusto lisää Wixin natiivien integraatioiden listan ulkopuolelle — yleensä nämä sijaitsevat Settings-, Custom Code -kohdassa, Velo-koodimoduuleissa tai upotettuina HTML-widgetteinä — ja inventoi, mihin suostumuskategoriaan kukin kuuluu. Kolmanneksi, kääri jokainen kolmannen osapuolen skripti suostumustarkistukseen, joka lukee suostumuspolitiikan ennen suorittamista. Neljänneksi, varmista, että bannerista näkyvä tietosuojakäytäntö heijastaa todellisia kolmansien osapuolten vastaanottajia, ei geneeristä Wix-mallipohjatekstiä.

• Custom Code Settingsin alla — operaattorit lisäävät yleisesti Google Tag Managerin, lisä-Facebook Pixeleitä, lisä-Google Ads -konversiotunnisteita, Hotjar-koodinpätkiä ja puhelunseurauskriptejä Custom Code -ominaisuuden kautta. Jokainen näistä on konfiguroitava asianmukaisella Consent Mode -asetuksella Custom Code -käyttöliittymässä — Wix paljastaa suostumuskategorian valinnan koodinpätkäkohtaisesti — jotta koodinpätkä latautuu vain, kun kyseinen kategoria on myönnetty.
• Velo-koodi — tausta- ja käyttöliittymäpuolen Velo-koodi voi lukea wixWindow.consentPolicy -arvon ja ehdollisesti haaroittaa kolmansien osapuolten API:hin. Jokainen Velo-moduuli, joka kutsuu kolmannen osapuolen päätepistettä tapahtumien kirjaamiseksi, pikselien laukaisemiseksi tai tietojen synkronoimiseksi CRM:ään, on tarkistettava asianmukainen kategoria ennen suorittamista.
• Upotetut HTML-widgetit — kolmansien osapuolten upotetut HTML-iframet (chat-widgetit, kalenteriwidgetit, sosiaalisen median upotukset) lataavat yleensä omat skriptinsä, jotka asettavat omat evästeensä. Malli on renderöidä iframe Velo-ohjatun kääreen sisään, joka ehdollisesti lisää iframe-elementin vasta, kun kyseinen portti on myönnetty.
• Wix Studio -sivustot — Wix Studio perii saman suostumuspolitiikkamekanismin, mutta lisää responsiivisen suunnittelun ja kehittäjätilaominaisuudet, jotka tekevät Velo-tyylisestä suostumuksen portauksesta helpommin ylläpidettävän. Integrointimalli on identtinen; ylläpidon ergonomia on parempi.

Wix-spesifiset vaatimustenmukaisuuden sudenkuopat

Kolme mallia toistuu Wix-käyttöönotoissa ja kattaa suurimman osan viranomaisten merkitsemistä ongelmista. Ensimmäinen on operaattorin hallinnoima kolmannen osapuolen Google Tag Manager -säilö — operaattori asentaa GTM:n Custom Code -ominaisuuden kautta, lisää sitten kymmeniä tunnisteita GTM-käyttöliittymän kautta ilman Consent Mode v2 -konfigurointia GTM:ssä itsessään. Wixin banneri portaa GTM-lataajan oikein, mutta kun GTM on ladattu, sen sisällä olevat tunnisteet laukeavat ilman lisäsuostumustarkistuksia, ellei GTM:ää ole konfiguroitu noudattamaan Consent Modea. Korjaus on ottaa käyttöön Consent Mode v2 GTM-säilössä ja kytkeä kunkin tunnisteen laukaisu asianmukaiseen suostumussignaaliin.

Toinen on upotettu lomakkeen tarjoaja — Typeform, JotForm, Calendly ja vastaavat — joka lataa omat evästeensä analytiikkaa ja esitäyttötarkoituksia varten. Wixin banneri ei portaa upotettua widgettiä oletuksena; operaattorin on portattava itse widgetti-elementti Velon kautta tai käytettävä klikkaa-ladataksesi-mallikäytäntöä, joka lykkää iframen lataamista, kunnes käyttäjä on vuorovaikutuksessa sen kanssa.

Kolmas on rajat ylittävän siirron ilmoitus. Wixin isännöintiinfrastruktuuri toimii eri alueilla, mukaan lukien Yhdysvallat, ja monet operaattorin kolmansien osapuolten vastaanottajista toimivat muualla; Wixin toimittama tietosuojakäytäntömallipohja ei nimeä noita lainkäyttöalueita erikseen, ja operaattorin on muokattava ilmoitusta nimetäkseen kunkin vastaanottaja-alueen. EDPB:n vuoden 2023 ohjeistus on nimenomaisesti todennut, että yleinen palveluntarjoajien käsittelemät tiedot -kielenkäyttö ei riitä, ja sama standardi koskee Wix-isännöityjä sivustoja.

Validointi ja auditointiasema vuodelle 2026

Puolustettavan Wix-käyttöönoton vuonna 2026 on läpäistävä neljä teknistä tarkistusta. Ensiksi, EEA IP -osoitteesta tarjoillun puhtaan selaimen istunnon on tuotettava nolla muuta kuin välttämättömistä evästeistä ennen kuin bannerille on tehty toimenpide — ei vain nolla Wixin hallinnoimia evästeitä, vaan nolla evästeitä jokaisesta Custom Code -koodinpätkästä, Velo-moduulista ja upotetusta widgetistä. Toiseksi, hylkäyspolun on pidettävä tuo tila. Kolmanneksi, hyväksymispolun on tuotettava vain tunnisteet, joihin käyttäjä on antanut suostumuksen, ja Wixin suostumuksen lokimerkinnän yhdessä minkä tahansa operaattorikohtaisen lokin kanssa on sisällettävä vastaava tietue. Neljänneksi, peruuttamisen on välittömästi pysäytettävä lisätunnisteiden laukaisu, vanhennutettava suostumussession aikana asetetut evästeet ja levitettävä kieltäytyminen kaikille alajuoksun kolmansien osapuolten vastaanottajille, jotka ylläpitävät omaa tilaansa.

Auditointiketjun odotus on se, missä Wix paranee mutta vaatii silti operaattorin ponnistuksia. Alusta tallentaa suostumuspäätökset omaan lokiinsa, joka on sivuston omistajan saatavilla, mikä on riittävää moniin viranomaiskyselyihin. Käyttöönotoille, jotka tarvitsevat täydellisemmän auditointiketjun — bannerin versio, kategorian tila, kieliversio ja alajuoksun vastaanottajan tila — operaattorin on lisättävä Velo-koodi, joka kirjoittaa suostumustapahtumia kyselymahdollisuuden ulkoiseen tallennustilaan. Wix-sivusto, joka on konfiguroinut sisäänrakennetun bannerin oikein, portannut jokaisen Custom Code- ja Velo-polun, muokannut tietosuojakäytäntöä nimetäkseen jokaisen rajat ylittävän vastaanottajan ja lisännyt auditointiketjulokin, on Wix-sivusto, joka on kääntänyt alustan isännöidyn rakentajan yksinkertaisuuden vaatimustenmukaisuuden vastuusta kustantajan suostumuksen aseman puolustettavaksi osaksi.