थर्ड-पार्टी कुकी क्या है?

थर्ड-पार्टी कुकी एक छोटा डेटा टुकड़ा है जो उपयोगकर्ता द्वारा वर्तमान में विजिट किए जा रहे डोमेन के अलावा किसी अन्य डोमेन द्वारा संग्रहीत किया जाता है, जो अक्सर किसी एड टेक कंपनी के ट्रैकिंग स्क्रिप्ट द्वारा प्रकाशक के पेज में एम्बेड किया जाता है। क्योंकि एक ही एड टेक डोमेन हजारों असंबंधित साइटों में एम्बेड किया जा सकता है, इसकी कुकी उस कंपनी को उन सभी में एक ही ब्राउज़र को पहचानने देती है, जिसने थर्ड-पार्टी कुकीज़ को पिछले दो दशकों के अधिकांश समय के लिए क्रॉस-साइट एड टारगेटिंग और फ़्रीक्वेंसी कैपिंग की रीढ़ बना दिया।

फर्स्ट-पार्टी बनाम थर्ड-पार्टी, सरल शब्दों में#

फर्स्ट-पार्टी डेटा सीधे किसी व्यवसाय द्वारा अपने स्वयं के उपयोगकर्ताओं के बारे में एकत्र किया जाता है और यह इस क्रॉस-साइट कुकी तंत्र पर बिल्कुल भी निर्भर नहीं करता है, यही कारण है कि थर्ड-पार्टी कुकीज़ प्रतिबंधित होने के साथ यह और अधिक मूल्यवान हो गया है।

ब्राउज़र उनसे दूर क्यों हटे#

Safari और Firefox ने वर्षों पहले थर्ड-पार्टी कुकीज़ को डिफ़ॉल्ट रूप से ब्लॉक कर दिया था। Chrome, जिसका ब्राउज़र बाजार में सबसे बड़ा हिस्सा है, ने नए टारगेटिंग और मापन API के आसपास बने ब्राउज़र-स्तरीय गोपनीयता पहल के हिस्से के रूप में उन्हें प्रतिबंधित और अप्रचलित करने के कई चरणों से गुजरा है। नियामकों और ब्राउज़र निर्माताओं द्वारा उठाई गई मूल चिंता वही थी जो रियल-टाइम बिडिंग गोपनीयता नियमों को आकार दे रही थी: असंबंधित साइटों पर उपयोगकर्ता की ब्राउज़िंग गतिविधि को स्पष्ट सहमति के बिना एक साथ जोड़ा जा रहा था। वही पहल OpenRTB कार्यान्वयन को भी छूती है, क्योंकि बिड अनुरोध ऐतिहासिक रूप से कुकी-आधारित पहचानकर्ता ले जाते थे जिनसे बचने के लिए नए API डिज़ाइन किए गए हैं।

नेटिव और प्रोग्रामेटिक टारगेटिंग के लिए इसका क्या मतलब है#

थर्ड-पार्टी कुकीज़ पर निर्भर क्रॉस-साइट व्यवहारिक टारगेटिंग और फ़्रीक्वेंसी कैपिंग ब्राउज़रों द्वारा उन्हें प्रतिबंधित करने के साथ कम विश्वसनीय रूप से काम करती है, जिससे उद्योग संदर्भिक टारगेटिंग की ओर बढ़ रहा है, जो उपयोगकर्ता इतिहास के बजाय पेज कंटेंट के साथ विज्ञापनों को मैच करता है, प्रमाणित फर्स्ट-पार्टी पहचानकर्ता, और Privacy Sandbox छत्र के तहत प्रस्तावित समूह-आधारित दृष्टिकोण। मुख्य रूप से क्रॉस-साइट कुकी डेटा के आसपास बना एक डेटा मैनेजमेंट प्लेटफॉर्म को भी उसी तरह अनुकूलित करना पड़ा है। नेटिव विज्ञापन पहले से ही ओपन-वेब डिस्प्ले की तुलना में क्रॉस-साइट रीटारगेटिंग पर कम निर्भर था, क्योंकि नेटिव इन्वेंट्री आमतौर पर वेब पर चारों ओर पीछा करने के बजाय प्रकाशक की अपनी कंटेंट फ़ीड के भीतर संदर्भिक रूप से खरीदी जाती है, इसलिए नेटिव खरीद पर व्यावहारिक प्रभाव आम तौर पर रीटारगेटिंग-भारी डिस्प्ले और सोशल प्रॉस्पेक्टिंग की तुलना में छोटा रहा है।

विज्ञापनदाता इसके बजाय क्या कर रहे हैं#

• ईमेल कैप्चर, लॉग्ड-इन अनुभवों और लॉयल्टी प्रोग्राम के माध्यम से सीधे फर्स्ट-पार्टी डेटा बनाना।
• प्रॉस्पेक्टिंग के लिए संदर्भिक टारगेटिंग पर अधिक निर्भर होना, जिसके लिए उपयोगकर्ता को साइटों के बीच ट्रैक करने की आवश्यकता बिल्कुल नहीं है।
• जहां उपलब्ध हो, प्रकाशकों के स्वयं के प्रमाणित ID समाधानों के साथ काम करना।
• Privacy Sandbox API का परीक्षण करना क्योंकि Chrome का रोलआउट आगे बढ़ता है, वर्तमान दस्तावेज़ देखते हुए क्योंकि समयरेखा और यांत्रिकी एक से अधिक बार बदल चुकी है।

यह बदलाव आम तौर पर प्रोग्रामेटिक विज्ञापन को छूता है, न कि केवल रीटारगेटिंग को, क्योंकि हेडर बिडिंग नीलामी और रियल-टाइम बिडिंग दोनों वर्षों से एक ही क्रॉस-साइट कुकी प्लंबिंग पर निर्भर थे।

OpenAdLibrary कैसे मदद करता है#

संदर्भिक, फ़ीड-आधारित नेटिव प्लेसमेंट कभी भी रीटारगेटिंग-भारी डिस्प्ले अभियानों की तरह थर्ड-पार्टी कुकीज़ पर उतने निर्भर नहीं थे, यह एक कारण है कि कुछ विज्ञापनदाता नेटिव की ओर बजट शिफ्ट कर रहे हैं क्योंकि कुकी-आधारित टारगेटिंग अन्य जगहों पर कम विश्वसनीय हो रही है। OpenAdLibrary का नेटिव एड स्पाई टूल दिखा सकता है कि आपके वर्टिकल के विज्ञापनदाता पहले से ही संदर्भिक-प्रथम नेटिव क्रिएटिव कैसे चला रहे हैं।