Amplitude को सहमति की आवश्यकता क्यों है

डिफ़ॉल्ट Amplitude Browser SDK और Amplitude मोबाइल SDK पेज व्यू रिकॉर्ड करने से कहीं अधिक करते हैं। इनिशियलाइज़ेशन पर वे फर्स्ट-पार्टी स्टोरेज में एक डिवाइस आइडेंटिफायर सेट करते हैं, एक सेशन आइडेंटिफायर जनरेट करते हैं, रेफरर कैप्चर करते हैं, URL से UTM और क्लिक आइडेंटिफायर पार्स करते हैं, और ऑटोकैप्चर किए गए इवेंट्स को कतारबद्ध करना शुरू करते हैं: पेज व्यू, एलिमेंट क्लिक, फॉर्म इंटरैक्शन, फ़ाइल डाउनलोड, और — नवीनतम रिलीज़ में — सेशन रीप्ले। वे उन इवेंट्स को IP-व्युत्पन्न जियोलोकेशन, user-agent-व्युत्पन्न डिवाइस डेटा, और, यदि कॉन्फ़िगर किया गया हो, डेटा पार्टनर्स से थर्ड-पार्टी एनरिचमेंट के साथ भी समृद्ध करते हैं।

उन चरणों में से प्रत्येक एक अलग सहमति कानूनी आधार को संलग्न करता है। एक डिवाइस आइडेंटिफायर को स्टोर करना ePrivacy Directive के Article 5(3) के तहत एक स्टोरेज-एंड-एक्सेस ऑपरेशन है, जिसके लिए यूरोपीय आर्थिक क्षेत्र, यूनाइटेड किंगडम, और किसी भी क्षेत्राधिकार में जिसने समान मानक आयात किया है, पूर्व, स्वतंत्र रूप से दी गई, विशिष्ट, सूचित और असंदिग्ध सहमति की आवश्यकता होती है। उस आइडेंटिफायर से बंधी व्यवहार संबंधी घटनाओं को कैप्चर करना GDPR के तहत व्यक्तिगत डेटा का प्रसंस्करण है। थर्ड-पार्टी डेटा के साथ समृद्धि एक दूसरे नियंत्रक संबंध का परिचय देती है। CCPA और CPRA उसी प्रसंस्करण को बिक्री या साझाकरण के रूप में वर्गीकृत करते हैं जब तक कि प्रकाशक के पास Amplitude के साथ उचित रूप से परिभाषित सेवा-प्रदाता अनुबंध न हो — जो उपलब्ध है, लेकिन केवल तभी जब एकीकरण विज्ञापन सुविधाओं को अक्षम करने के लिए कॉन्फ़िगर किया गया हो।

Amplitude सहमति से पहले क्या एकत्र करता है — और आपको क्या दबाना चाहिए

सबसे सामान्य कार्यान्वयन गलती Amplitude को एक हल्के विश्लेषण टूल के रूप में मानना है जो कुकी बैनर के साथ चल सकता है। यह नहीं चल सकता। एक डिफ़ॉल्ट amplitude.init() कॉल पर SDK पेज के पहले पेंट के भीतर कम से कम एक कुकी या लोकल स्टोरेज एंट्री लिखेगा, एक identify कॉल भेजेगा, और इवेंट्स को बफर करना शुरू करेगा। इनमें से कोई भी तब तक अनुमेय नहीं है जब तक उपयोगकर्ता ने प्रासंगिक सहमति श्रेणी को सकारात्मक रूप से स्वीकार नहीं किया हो।

एक अनुपालन एकीकरण को इसलिए amplitude.init() में तब तक देरी करनी चाहिए जब तक CMP ने संकेत नहीं दिया कि विश्लेषण सहमति श्रेणी दी गई है। SDK को CMP के उद्देश्य 8 (एनालिटिक्स) या उद्देश्य 1 (स्टोरेज और एक्सेस) सिग्नल पर निर्भर सहमति-गेटेड <script> टैग से बिल्कुल भी लोड नहीं किया जाना चाहिए, यह इस बात पर निर्भर करता है कि CMP किस फ्रेमवर्क को उजागर करता है। यदि SDK को पहले लोड करना आवश्यक है — उदाहरण के लिए क्योंकि यह एप्लिकेशन कोड में बंडल किया गया है और लेज़िली फेच नहीं किया जा सकता — इनिशियलाइज़ेशन कॉल को defaultTracking: false और optOut: true पास करना चाहिए ताकि सहमति दर्ज होने तक कोई इवेंट न भेजा जाए, और फिर एक डिफर्ड ऑप्ट-इन इवेंट को उन फ्लैग्स को पलटना चाहिए।

Amplitude जो कुकीज़ और स्टोरेज लिखता है

Browser SDK 2.x डिफ़ॉल्ट रूप से AMP_{apiKey} नाम की एक सिंगल फर्स्ट-पार्टी कुकी लिखता है, एक साल की एक्सपायरी के साथ, जिसमें डिवाइस आइडेंटिफायर और सेशन मेटाडेटा होता है। पुराने संस्करण amplitude_id_{apiKey} भी लिखते थे। मोबाइल SDK एप्लिकेशन के सैंडबॉक्स स्टोरेज के अंदर उसी आइडेंटिफायर को बनाए रखते हैं। सेशन रीप्ले एक दूसरी कुकी, AMP_MKTG_{apiKey}, जोड़ता है, और Amplitude के एनरिचमेंट पार्टनर अतिरिक्त थर्ड-पार्टी कुकीज़ सेट कर सकते हैं यदि एक्सपेरिमेंट-टार्गेटिंग या ऑडियंस मॉड्यूल सक्षम हों। ये सभी गैर-आवश्यक हैं और सहमति की आवश्यकता है।

Amplitude को सहमति फ्रेमवर्क में मैप करना

Amplitude मूल रूप से Google Consent Mode v2, IAB TCF, या IAB Global Privacy Platform को लागू नहीं करता। यह एक दोष नहीं है — Amplitude एक फर्स्ट-पार्टी एनालिटिक्स प्लेटफॉर्म है, न कि एक एड-टेक विक्रेता — लेकिन इसका अर्थ है कि एकीकरण की जिम्मेदारी प्रकाशक पर है। व्यवहार में जो पैटर्न काम करता है वह है प्रत्येक Amplitude मॉड्यूल को एक अलग सहमति गेट के रूप में मानना और उसे उस विशिष्ट सिग्नल से बाँधना जिसे CMP पहले से उजागर करता है।

• कोर एनालिटिक्स इवेंट्स एनालिटिक्स उद्देश्य से जुड़े होते हैं। TCF संदर्भ में यह सबसे सामान्यतः उद्देश्य 8 (कंटेंट प्रदर्शन मापना) और उद्देश्य 1 (सूचना स्टोर करना और/या एक्सेस करना) का संयोजन है। Google Consent Mode के लिए यह analytics_storage से मैप होता है।
• सेशन रीप्ले को एक सख्त सिग्नल के पीछे होना चाहिए। रीप्ले रेंडर किए गए DOM को कैप्चर करता है, जिसमें फॉर्म वैल्यू शामिल हैं जब तक स्पष्ट रूप से मास्क न किया गया हो, इसलिए एक अलग preferences या functional ऑप्ट-इन उपयुक्त है, और रीप्ले को डिफ़ॉल्ट रूप से बंद रहना चाहिए, भले ही एनालिटिक्स दिया गया हो।
• ऑडियंस, कोहोर्ट और थर्ड-पार्टी एनरिचमेंट मार्केटिंग उद्देश्य से जुड़े होते हैं। TCF संदर्भ में यह उद्देश्य 7 (विज्ञापन प्रदर्शन मापना) या उद्देश्य 9 (बाजार अनुसंधान लागू करना) है। Google Consent Mode के लिए यह ad_storage और ad_user_data से मैप होता है।
• प्रयोग — Amplitude Experiment वैध-हित के आधार पर अनाम, अल्पकालिक आवंटन के साथ चल सकता है, लेकिन उपयोगकर्ता आइडेंटिफायर से जुड़ा स्थायी आवंटन कोर एनालिटिक्स जैसी ही सहमति की आवश्यकता है।

कार्य करने वाला एकीकरण पैटर्न

संदर्भ कार्यान्वयन जो नियामक की समीक्षा से गुजरता है, उसमें चार गतिशील भाग होते हैं: एक CMP जो उपयोगकर्ता द्वारा सहमति बदलने पर रियल-टाइम इवेंट उजागर करता है, एक डिफर्ड SDK लोडर जो प्रासंगिक श्रेणी के लिए वह इवेंट फायर होने के बाद ही Amplitude लाता है, एक सेशन-स्तर गार्ड जो जहाँ कानून अनुमति देता है वहाँ उपयोगकर्ता के पिछले अनाम डिवाइस आइडेंटिफायर को खोए बिना ऑप्ट-आउट का सम्मान करता है, और सर्वर-साइड ब्रिज उन इवेंट्स के लिए जिन्हें सहमति की परवाह किए बिना संग्रह की वास्तव में आवश्यकता है — जैसे सुरक्षा टेलीमेट्री या धोखाधड़ी का पता लगाना — अपने स्वयं के कानूनी आधार के साथ एक अलग एंडपॉइंट के माध्यम से रूट किया गया।

वेब कार्यान्वयन

वेब पर, सबसे स्वच्छ पैटर्न window.__cmp_consent ऑब्जेक्ट या मानक __tcfapi कॉलबैक के माध्यम से CMP की सहमति स्थिति उजागर करना है, फिर एक छोटा बूटस्ट्रैप स्क्रिप्ट होना जो सहमति परिवर्तनों की सदस्यता लेता है। जब एनालिटिक्स सहमति false से true में बदलती है, बूटस्ट्रैप CMP-प्रबंधित CDN से Amplitude SDK लाता है, amplitude.init(apiKey, undefined, { defaultTracking: true }) कॉल करता है, और सहमति पेंडिंग रहने के दौरान मेमोरी में कतारबद्ध किसी भी इवेंट को रीप्ले करता है। जब सहमति वापस false में बदलती है, बूटस्ट्रैप amplitude.setOptOut(true) कॉल करता है, document.cookie एक्सपायरी के माध्यम से AMP_ कुकी को साफ करता है, और किसी भी इन-मेमोरी स्टेट को हटाता है। महत्वपूर्ण रूप से, बूटस्ट्रैप को कभी भी बैनर रेंडर के समान अनुरोध प्रवाह में Amplitude को आलसी रूप से इनिशियलाइज़ नहीं करना चाहिए — SDK को एक स्पष्ट अनुदान का इंतजार करना होगा।

मोबाइल कार्यान्वयन

iOS पर समकक्ष Amplitude फ्रेमवर्क को आयातित रखना है लेकिन Amplitude.instance().initialize(apiKey: apiKey) को तब तक स्थगित करना है जब तक इन-ऐप सहमति प्रवाह ने एक सकारात्मक एनालिटिक्स सिग्नल वापस नहीं किया हो। ATT प्रॉम्प्ट एक अलग चिंता है: ATT IDFA को नियंत्रित करता है, जबकि Amplitude का आइडेंटिफायर SDK का अपना UUID है जो ऐप सैंडबॉक्स में संग्रहीत है। दोनों को EEA में सहमति की आवश्यकता है, लेकिन कानूनी आधार और प्रॉम्प्ट अलग हैं। Android पर SDK संस्करण के आधार पर Amplitude.getInstance().initializeApolloClient() या समकक्ष के साथ यही तर्क लागू होता है।

सर्वर-साइड मोड

Amplitude HTTP V2 API के माध्यम से सर्वर-साइड इनजेशन का समर्थन करता है। सर्वर-साइड इवेंट्स सहमति से मुक्त नहीं हैं — कानूनी आधार डेटा का अनुसरण करता है, परिवहन का नहीं — लेकिन सर्वर-साइड इनजेशन प्रकाशक को पूर्ण नियंत्रण देता है कि कौन से फ़ील्ड भेजे जाते हैं, जिससे आंशिक सहमति का सम्मान करना आसान हो जाता है। एक सामान्य पैटर्न है वैध हित के तहत सर्वर-साइड पर एक न्यूनतम आवश्यक-केवल इवेंट सेट कैप्चर करना, और केवल उन इवेंट्स को व्यवहार संबंधी विवरण के साथ समृद्ध करना जब उपयोगकर्ता ने क्लाइंट पर एनालिटिक्स सहमति दी हो।

एकीकरण को मान्य करना

मान्यता चरण वह है जिसे प्रकाशक अक्सर छोड़ देते हैं और नियामक अक्सर जाँचते हैं। एक सही ढंग से एकीकृत Amplitude तैनाती को चार जाँचें पास करनी चाहिए। पहली, सहमति बैनर दिखाए गए लेकिन कोई विकल्प नहीं बनाए गए ब्राउज़र को api.amplitude.com या api.eu.amplitude.com के लिए शून्य अनुरोध और document.cookie में शून्य AMP_ कुकीज़ उत्पन्न करनी चाहिए। दूसरी, एनालिटिक्स श्रेणी को अस्वीकार करने से वह स्थिति बनी रहनी चाहिए — कोई इवेंट नहीं, कोई कुकीज़ नहीं, AMP_ उपसर्ग के साथ कोई लोकल स्टोरेज एंट्री नहीं। तीसरी, एनालिटिक्स स्वीकार करने से एक identify और उसके बाद इवेंट ट्रैफिक उत्पन्न होना चाहिए, और AMP_ कुकी को प्रकाशक की CMP नीति के अनुरूप SameSite एट्रिब्यूट के साथ दिखाई देना चाहिए। चौथी, बाद में सहमति वापस लेने से तुरंत आगे के इवेंट्स बंद हो जाने चाहिए और संग्रहीत आइडेंटिफायर साफ हो जाने चाहिए — देरी से सफाई एक निष्कर्ष है।

ऑडिट ट्रेल अलग से महत्वपूर्ण है। EDPB के 2023 कुकी बैनर दिशानिर्देशों और नवीनीकृत 2026 टास्क फोर्स प्राथमिकताओं के तहत, नियामक अपेक्षा करते हैं कि प्रकाशक Amplitude प्रोजेक्ट में किसी भी दिए गए इवेंट के लिए साबित कर सके कि उसे उत्पन्न करने वाले उपयोगकर्ता ने कैप्चर के समय वैध सहमति दी थी। इसके लिए CMP की सहमति लॉग डिवाइस आइडेंटिफायर या सेशन आइडेंटिफायर द्वारा क्वेरी योग्य होना आवश्यक है, और Amplitude इवेंट पेलोड में एक सहमति-संस्करण फ़ील्ड होना चाहिए जो उस लॉग से वापस जुड़ती है। प्रत्येक इवेंट पर सहमति स्ट्रिंग को एक कस्टम यूजर प्रॉपर्टी के रूप में संग्रहीत करना उस लिंक को ऑडिट योग्य बनाने का सबसे सरल तरीका है।

सही क्षेत्र और डेटा निवास चुनना

Amplitude दो प्रोडक्शन क्षेत्र संचालित करता है: US (api.amplitude.com) और EU (api.eu.amplitude.com)। EEA और UK ट्रैफिक के लिए EU क्षेत्र सही डिफ़ॉल्ट है — यह डेटा को EEA के भीतर रखता है और ट्रांसफर-जोखिम सतह को कम करता है जिसे Schrems II निर्णय और EU-US Data Privacy Framework ने किसी भी एनालिटिक्स समीक्षा के लिए केंद्रीय बना दिया है। क्षेत्र बदलना पूर्वव्यापी नहीं है: मौजूदा डेटा वहीं रहता है जहाँ पहली बार इनजेस्ट किया गया था। CMP रोलआउट की योजना बना रहे प्रकाशकों के लिए इसलिए स्केलिंग से पहले क्षेत्र की पुष्टि करना और गोपनीयता नोटिस में चुनाव का दस्तावेज़ीकरण करना उचित है ताकि कानूनी आधार श्रृंखला संग्रह से भंडारण तक स्वच्छ हो। सही ढंग से चुना गया क्षेत्र, सही ढंग से गेट किए गए SDK और क्वेरी योग्य सहमति लॉग के साथ जोड़ा गया, वही है जो Amplitude तैनाती को नियामक जोखिम से एनालिटिक्स स्टैक के रक्षात्मक भाग में बदलता है।