Wix Cookie Consent Banner एकीकरण गाइड: अंतर्निहित CMP, Velo और 2026 में थर्ड-पार्टी एम्बेड
Wix सैकड़ों मिलियन छोटे व्यवसायों, निर्माताओं और ऑपरेटरों के लिए डिफ़ॉल्ट वेब प्लेटफ़ॉर्म है जिनके पास इंजीनियरिंग टीम नहीं है और वे नहीं चाहते। प्लेटफ़ॉर्म की ताकत ठीक यही है — एक होस्ट किया गया साइट बिल्डर जहां अंतर्निहित बुनियादी ढांचा, भुगतान प्रसंस्करण, सामग्री प्रबंधन और तेजी से बढ़ता मार्केटिंग स्टैक उस व्यक्ति से अमूर्त हो जाते हैं जो वास्तव में साइट चला रहा है। वह अमूर्तता भी वही है जहां Wix के सहमति जोखिम केंद्रित होते हैं। प्लेटफ़ॉर्म एक अंतर्निहित कुकी सहमति बैनर प्रदान करता है जिसे ऑपरेटर कुछ क्लिक में सक्षम कर सकता है; बैनर इस सतही प्रश्न को संतुष्ट करता है कि क्या कोई बैनर मौजूद है; और ऑपरेटर आगे बढ़ जाता है। कठिन प्रश्न — क्या बैनर वास्तव में सहमति से पहले टैग को फायर होने से रोक रहा है, क्या थर्ड-पार्टी HTML एम्बेड और Velo कोड सही ढंग से नियंत्रित हैं, क्या सहमति लॉग ऑडिट योग्य है, क्या क्रॉस-बॉर्डर ट्रांसफर प्रकटन सटीक है — शायद ही कभी पूछे जाते हैं, और एक Wix साइट जिसने इन्हें नहीं पूछा वह GDPR, ePrivacy, या उनके साथ संरेखित क्षेत्रीय व्यवस्थाओं को संतुष्ट नहीं करती। यह गाइड बताता है कि क्या कॉन्फ़िगर करें और क्या जोड़ें ताकि 2026 में एक Wix तैनाती रक्षायोग्य स्थिति तक पहुंचे।
Wix का अंतर्निहित कुकी सहमति बैनर वास्तव में क्या करता है
Wix Cookie Consent Banner — Settings, Privacy & Compliance के तहत हर Wix साइट के लिए उपलब्ध — किसी भी होस्टेड प्लेटफ़ॉर्म द्वारा प्रदान किए जाने वाले सबसे सक्षम मूल सहमति उपकरणों में से एक है। यह Essential, Functional, Analytics और Advertising श्रेणियों में प्रति-श्रेणी opt-in का समर्थन करता है, स्पष्ट सकारात्मक कार्रवाई की आवश्यकता के लिए कॉन्फ़िगर किया जा सकता है, साइट की अनुवाद परत के माध्यम से बहुभाषी सामग्री का समर्थन करता है, और Wix की अपनी Marketing Apps द्वारा सम्मानित सहमति नीति के साथ मूल रूप से एकीकृत होता है। जब ऑपरेटर बैनर को सहमति की आवश्यकता के लिए कॉन्फ़िगर करता है और प्रति-श्रेणी नियंत्रण सक्षम करता है, तो Wix के मूल एकीकरण — Wix Analytics, Facebook Pixel एकीकरण, Google Ads एकीकरण, Google Tag Manager एकीकरण, Hotjar एकीकरण — बिना किसी अतिरिक्त वायरिंग के उपयोगकर्ता की पसंद का सम्मान करते हैं।
बैनर जो नहीं करता, और जहां सबसे सामान्य अनुपालन विफलता होती है, वह है उन थर्ड-पार्टी स्क्रिप्ट को नियंत्रित करना जो ऑपरेटर ने Wix के Custom Code फ़ीचर, Velo कोड, या एम्बेड किए गए HTML विजेट के माध्यम से जोड़े हैं। बैनर उपयोगकर्ता की पसंद रिकॉर्ड करता है; ऑपरेटर का काम है कि वह उस पसंद को सहमति नीति से पढ़े और उस थर्ड-पार्टी लॉजिक को सशर्त रूप से निष्पादित करे जो Wix की प्रबंधित एकीकरण सूची के बाहर रहता है। पैटर्न एक बार स्थापित होने पर काम करता है, लेकिन यह स्वचालित नहीं है।
डिफ़ॉल्ट कॉन्फ़िगरेशन पर्याप्त नहीं है
जब ऑपरेटर पहली बार बैनर सक्षम करता है तो डिफ़ॉल्ट बैनर कॉन्फ़िगरेशन अनुमानित सहमति है — साइट पर जाना सहमति के रूप में माना जाता है जब तक आगंतुक अस्वीकार नहीं करता। वह स्थिति EEA, UK और GDPR के साथ संरेखित व्यवस्थाओं में Wix-होस्टेड साइटों के खिलाफ बार-बार नियामक निष्कर्षों का स्रोत रही है। ऑपरेटर को कॉन्फ़िगरेशन बदलना होगा ताकि गैर-आवश्यक कुकीज़ सेट होने से पहले स्पष्ट सकारात्मक सहमति की आवश्यकता हो, प्रति-श्रेणी टॉगल को डिफ़ॉल्ट रूप से बंद करना होगा, और यह सत्यापित करना होगा कि बैनर UI में अस्वीकृति विकल्प स्वीकृति विकल्प जितना ही प्रमुख है। ये तीन सेटिंग्स — स्पष्ट सहमति, डिफ़ॉल्ट बंद, अस्वीकृति प्रमुख — वह न्यूनतम है जो Wix साइट को EDPB द्वारा 2023 कुकी बैनर दिशानिर्देशों में निर्धारित और 2026 टास्क फ़ोर्स प्राथमिकताओं में पुष्टि की गई सीमा पार करने के लिए चाहिए।
Wix हुड के नीचे सहमति को कैसे संभालता है
Wix एक सहमति नीति ऑब्जेक्ट के माध्यम से आगंतुक की सहमति स्थिति उजागर करता है जिसे प्लेटफ़ॉर्म के आंतरिक एकीकरण पढ़ते हैं और ऑपरेटर का कोड Velo डेवलपर प्लेटफ़ॉर्म के माध्यम से पढ़ सकता है। Velo API सहमति नीति को फ्रंट एंड पर wixWindow.consentPolicy के तहत और बैक एंड पर समकक्ष मॉड्यूल के तहत उजागर करता है। सहमति नीति प्रति श्रेणी बूलियन फ्लैग और टाइमस्टैम्प के साथ एक संरचित ऑब्जेक्ट लौटाती है; ऑपरेटर का Velo कोड या Custom Code किसी भी गैर-आवश्यक थर्ड-पार्टी लॉजिक को प्रारंभ करने से पहले उन फ्लैग को पढ़ता है।
Wix द्वारा उजागर की गई सहमति श्रेणियां मानक वर्गीकरण के साथ मेल खाती हैं। Essential सत्र, कार्ट, सुरक्षा और लोड-बैलेंसिंग कुकीज़ को कवर करता है और सहमति की आवश्यकता नहीं है। Functional प्राथमिकताओं, हाल ही में देखी गई सूचियों और गैर-आवश्यक लेकिन गैर-ट्रैकिंग भंडारण को कवर करता है। Analytics Wix Analytics, Google Analytics 4, Microsoft Clarity और समान माप उपकरणों को कवर करता है। Advertising Facebook Pixel, Google Ads, TikTok Pixel, LinkedIn Insight और व्यापक मार्केटिंग पिक्सेल इन्वेंटरी को कवर करता है। मूल Wix Marketing Apps इन श्रेणियों पर स्वचालित रूप से नियंत्रित होती हैं; ऑपरेटर द्वारा जोड़ी गई सभी चीजों को मैन्युअल रूप से नियंत्रित करना होगा।
थर्ड-पार्टी एम्बेड और Custom Code के लिए एकीकरण पैटर्न
Wix पर काम करने वाले पैटर्न के चार भाग हैं। पहला, अंतर्निहित Cookie Consent Banner को स्पष्ट सहमति की आवश्यकता के लिए कॉन्फ़िगर करें, प्रति-श्रेणी टॉगल को डिफ़ॉल्ट रूप से बंद करें, और सुनिश्चित करें कि अस्वीकृति विकल्प कम से कम स्वीकृति जितना प्रमुख हो। दूसरा, हर थर्ड-पार्टी स्क्रिप्ट की पहचान करें जिसे साइट Wix की मूल एकीकरण सूची के बाहर जोड़ती है — आमतौर पर ये Settings, Custom Code में, Velo कोड मॉड्यूल में, या एम्बेडेड HTML विजेट में रहती हैं — और उनकी सूची बनाएं कि प्रत्येक किस सहमति श्रेणी में आती है। तीसरा, प्रत्येक थर्ड-पार्टी स्क्रिप्ट को एक सहमति जांच में लपेटें जो निष्पादन से पहले सहमति नीति पढ़ती है। चौथा, सुनिश्चित करें कि बैनर से प्रदर्शित गोपनीयता नोटिस वास्तविक थर्ड-पार्टी प्राप्तकर्ताओं को दर्शाता है, न कि Wix की सामान्य टेम्पलेट भाषा को।
- Settings के तहत Custom Code — ऑपरेटर आमतौर पर Custom Code के माध्यम से Google Tag Manager, अतिरिक्त Facebook Pixels, अतिरिक्त Google Ads रूपांतरण टैग, Hotjar स्निपेट और कॉल-ट्रैकिंग स्क्रिप्ट जोड़ते हैं। इनमें से प्रत्येक को Custom Code UI में उचित Consent Mode सेटिंग के साथ कॉन्फ़िगर किया जाना चाहिए — Wix प्रति-स्निपेट स्तर पर सहमति-श्रेणी चयन उजागर करता है — ताकि स्निपेट केवल तभी लोड हो जब प्रासंगिक श्रेणी दी गई हो।
- Velo कोड — बैक-एंड और फ्रंट-एंड Velo कोड wixWindow.consentPolicy पढ़ सकता है और सशर्त रूप से थर्ड-पार्टी API में विस्तारित हो सकता है। कोई भी Velo मॉड्यूल जो इवेंट लॉग करने, पिक्सेल फायर करने या CRM में डेटा सिंक करने के लिए थर्ड-पार्टी एंडपॉइंट को कॉल करता है, उसे निष्पादन से पहले प्रासंगिक श्रेणी की जांच करनी होगी।
- एम्बेडेड HTML विजेट — थर्ड-पार्टी से एम्बेडेड HTML iframes (चैट विजेट, कैलेंडर विजेट, सोशल एम्बेड) आमतौर पर अपनी स्क्रिप्ट लोड करते हैं जो अपनी कुकीज़ सेट करती हैं। पैटर्न है Velo-नियंत्रित रैपर के अंदर iframe रेंडर करना जो iframe एलिमेंट को सशर्त रूप से तभी इन्सर्ट करता है जब प्रासंगिक गेट दिया गया हो।
- Wix Studio साइटें — Wix Studio समान सहमति नीति तंत्र विरासत में लेता है लेकिन रेस्पॉन्सिव डिज़ाइन और डेवलपर-मोड सुविधाएं जोड़ता है जो Velo-स्टाइल सहमति गेटिंग को बनाए रखना आसान बनाती हैं। एकीकरण पैटर्न समान है; रखरखाव की एर्गोनॉमिक्स बेहतर है।
Wix-विशिष्ट अनुपालन नुकसान
तीन पैटर्न Wix तैनाती पर बार-बार आते हैं और नियामक-चिह्नित मुद्दों का बड़ा हिस्सा बनाते हैं। पहला ऑपरेटर-प्रबंधित थर्ड-पार्टी Google Tag Manager कंटेनर है — ऑपरेटर Custom Code के माध्यम से GTM इंस्टॉल करता है, फिर GTM UI के माध्यम से GTM में ही Consent Mode v2 कॉन्फ़िगर किए बिना दर्जनों टैग जोड़ता है। Wix बैनर GTM लोडर को सही ढंग से नियंत्रित करता है, लेकिन एक बार GTM लोड होने के बाद अंदर के टैग बिना किसी आगे की सहमति जांच के फायर होते हैं जब तक GTM को Consent Mode का सम्मान करने के लिए कॉन्फ़िगर नहीं किया गया है। समाधान GTM कंटेनर में Consent Mode v2 सक्षम करना और प्रत्येक टैग के ट्रिगर को उचित सहमति संकेत से जोड़ना है।
दूसरा एम्बेडेड फ़ॉर्म प्रदाता है — Typeform, JotForm, Calendly और इसी तरह के — जो एनालिटिक्स और प्री-फिल उद्देश्यों के लिए अपनी कुकीज़ लोड करता है। Wix बैनर डिफ़ॉल्ट रूप से एम्बेडेड विजेट को नियंत्रित नहीं करता; ऑपरेटर को Velo के माध्यम से विजेट एलिमेंट को स्वयं नियंत्रित करना होगा, या क्लिक-टू-लोड प्लेसहोल्डर पैटर्न का उपयोग करना होगा जो उपयोगकर्ता के इसके साथ इंटरैक्ट करने तक iframe लोड में देरी करता है।
तीसरा क्रॉस-बॉर्डर ट्रांसफर प्रकटन है। Wix की होस्टिंग बुनियादी ढांचा संयुक्त राज्य अमेरिका सहित कई क्षेत्रों में चलती है, और ऑपरेटर के कई थर्ड-पार्टी प्राप्तकर्ता अन्यत्र चलते हैं; Wix द्वारा प्रदान किया गया गोपनीयता नोटिस टेम्पलेट उन न्यायक्षेत्रों का विशेष रूप से उल्लेख नहीं करता, और ऑपरेटर को प्रत्येक प्राप्तकर्ता क्षेत्र का नाम लेने के लिए नोटिस संपादित करना होगा। EDPB के 2023 मार्गदर्शन ने स्पष्ट रूप से कहा है कि सामान्य सेवा प्रदाताओं द्वारा संसाधित डेटा भाषा पर्याप्त नहीं है, और Wix-होस्टेड साइटों पर भी यही मानक लागू होता है।
2026 के लिए सत्यापन और ऑडिट स्थिति
2026 में एक रक्षायोग्य Wix तैनाती को चार तकनीकी जांच पास करनी होगी। पहला, EEA IP पते से सेवित एक स्वच्छ ब्राउज़र सत्र को बैनर पर कार्रवाई से पहले शून्य गैर-आवश्यक कुकीज़ उत्पन्न करनी चाहिए — न केवल शून्य Wix-प्रबंधित कुकीज़, बल्कि हर Custom Code स्निपेट, Velo मॉड्यूल और एम्बेडेड विजेट से शून्य कुकीज़। दूसरा, अस्वीकृति पथ को उस स्थिति को बनाए रखना होगा। तीसरा, स्वीकृति पथ को केवल वे टैग उत्पन्न करने होंगे जिनके लिए उपयोगकर्ता ने सहमति दी है, और Wix सहमति लॉग के साथ किसी भी ऑपरेटर-साइड लॉग में मिलान रिकॉर्ड होना चाहिए। चौथा, वापसी को तुरंत आगे के टैग फायर रोकने चाहिए, सहमति दिए गए सत्र के दौरान सेट की गई कुकीज़ को एक्सपायर करना चाहिए, और किसी भी डाउनस्ट्रीम थर्ड-पार्टी प्राप्तकर्ताओं को opt-out प्रचारित करना चाहिए जो अपनी स्थिति बनाए रखते हैं।
ऑडिट-ट्रेल अपेक्षा वह है जहां Wix सुधर रहा है लेकिन अभी भी ऑपरेटर प्रयास की आवश्यकता है। प्लेटफ़ॉर्म अपने स्वयं के लॉग में सहमति निर्णय रिकॉर्ड करता है जो साइट मालिक के लिए सुलभ है, जो कई नियामक प्रश्नों के लिए पर्याप्त है। ऐसी तैनाती के लिए जिन्हें पूर्ण ऑडिट ट्रेल की आवश्यकता है — बैनर संस्करण, श्रेणी स्थिति, भाषा संस्करण और डाउनस्ट्रीम प्राप्तकर्ता स्थिति — ऑपरेटर को Velo कोड जोड़ना होगा जो सहमति इवेंट को एक क्वेरी योग्य बाहरी स्टोर में लिखता है। एक Wix साइट जिसने अंतर्निहित बैनर को सही ढंग से कॉन्फ़िगर किया है, हर Custom Code और Velo पथ को नियंत्रित किया है, प्रत्येक क्रॉस-बॉर्डर प्राप्तकर्ता का नाम लेने के लिए गोपनीयता नोटिस संपादित किया है, और ऑडिट-ट्रेल लॉग जोड़ा है, वह एक Wix साइट है जिसने प्लेटफ़ॉर्म की होस्टेड-बिल्डर सरलता को अनुपालन दायित्व से प्रकाशक की सहमति स्थिति के रक्षायोग्य भाग में बदल दिया है।