उपयोगकर्ता-एजेंट टारगेटिंग

पहले से ही उपयोगकर्ता-एजेंट हेडर को बिड रिक्वेस्ट में शामिल किया जाता है. इसका मकसद, शुरुआती डिवाइस के ब्राउज़र और प्लैटफ़ॉर्म जैसा ज़रूरी टारगेटिंग डेटा उपलब्ध कराना है. हालांकि, उपयोगकर्ता-एजेंट के इस्तेमाल को आसान बनाने और उपयोगकर्ता की निजता को बेहतर तरीके से सुरक्षित रखने के लिए, ब्राउज़र अक्सर उपयोगकर्ता-एजेंट को बड़ी संख्या में छिपाने के लिए उसमें बदलाव करते हैं. इस वजह से Google, उपयोगकर्ता-एजेंट क्लाइंट हिंट के साथ काम करता है. उपयोगकर्ता-एजेंट हेडर के साथ दिखने पर, ये बिड रिक्वेस्ट में शामिल होते हैं. इन क्लाइंट हिंट को (कम शब्दों में कहें, तो) Sec-Ch-UA* हेडर या JavaScript क्लाइंट हिंट एपीआई से लिया जा सकता है.

इस्तेमाल किए गए प्रोटोकॉल के आधार पर, उपयोगकर्ता-एजेंट हेडर यहां दिए गए किसी एक स्ट्रिंग फ़ील्ड में दिखता है:

  • Google: BidRequest.user_agent
  • ओपनआरटीबी: BidRequest.device.ua

उपलब्ध होने पर, UserAgent मैसेज में क्लाइंट हिंट की जानकारी अपने-आप भर जाएगी. हालांकि, उपयोगकर्ता एजेंट हेडर से पार्स की गई वैल्यू के आधार पर, यह मैसेज अपने-आप भर जाएगा. इस्तेमाल किए गए प्रोटोकॉल के आधार पर, इसे नीचे दिए गए किसी एक फ़ील्ड के तौर पर दिखाया जाएगा:

  • Google: BidRequest.user_agent_data
  • ओपनआरटीबी: BidRequest.device.sua

बिडिंग करने वाले लोगों को, उपयोगकर्ता-एजेंट स्ट्रिंग के बजाय UserAgent मैसेज का इस्तेमाल करने का सुझाव दिया जाता है.

UserAgent में डेटा कैसे जनरेट होता है

उपयोगकर्ता-एजेंट हेडर के उलट, UserAgent मैसेज, उपयोगकर्ता एजेंट की जानकारी को अलग-अलग फ़ील्ड में बांटकर किसी खास जानकारी को दिखाता है.

विज्ञापन अनुरोध में क्लाइंट हिंट की जानकारी उपलब्ध है या नहीं, इसके आधार पर UserAgent मैसेज को इन तरीकों से भरा जा सकता है:

  • अगर अनुरोध में कम से कम low-entropy क्लाइंट हिंट शामिल हैं, तो UserAgent उनके कॉन्टेंट के आधार पर अपने-आप भर जाता है.
  • अगर अनुरोध में सिर्फ़ उपयोगकर्ता-एजेंट हेडर शामिल है, तो UserAgent को हेडर से पार्स की जा सकने वाली जानकारी के आधार पर पॉप्युलेट किया जाता है.

उदाहरण: उपयोगकर्ता-एजेंट हेडर के आधार पर UserAgent में जानकारी अपने-आप भरी जा रही है

मान लें कि एक विज्ञापन अनुरोध है, जिसमें ब्राउज़र नीचे दिए गए हेडर भेजता है:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
            AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36

सिर्फ़ उपयोगकर्ता-एजेंट हेडर के आधार पर भरा गया UserAgent कुछ ऐसा दिख सकता है:

browsers: [{ brand: "Mozilla", version: ["5", "0"] },
           { brand: "AppleWebKit", version: ["537", "36"] },
           { brand: "Chrome", version: ["103", "0", "0", "0"] },
           { brand: "Safari", version: ["537", "36"] }],
platform: { brand: "Windows NT", version: ["10", "0"] },
mobile: false,
architecture: "x86",
bitness: "64",
model: "x64",
source: USER_AGENT_STRING

उदाहरण: क्लाइंट से मिले संकेतों के आधार पर UserAgent की जानकारी अपने-आप भरी जा रही है

मान लें कि एक विज्ञापन अनुरोध है, जिसमें ब्राउज़र नीचे दिए गए हेडर भेजता है:

User-Agent:                 Mozilla/5.0 (Windows NT 10.0; Win64; x64)
                            AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36
Sec-Ch-Ua:                  ".Not/A)Brand";v="99", "Google Chrome";v="103", "Chromium";v="103"
Sec-Ch-Ua-Arch:             x86
Sec-Ch-Ua-Full-Version:     103.0.5060.134
Sec-Ch-Ua-Mobile:           ?0
Sec-Ch-Ua-Platform:         Windows
Sec-Ch-Ua-Platform-Version: 15.0.0

ऐसे मामलों में जहां कम से कम एंट्रॉपी क्लाइंट हिंट को शामिल किया जाता है, उन हेडर के कॉन्टेंट के आधार पर UserAgent की जानकारी अपने-आप भर जाएगी, भले ही उपयोगकर्ता-एजेंट हेडर मौजूद हों. यह कुछ ऐसा दिखेगा:

browsers: [{ brand: ".Not/A)Brand", version: ["99", "0", "0", "0"] },
           { brand: "Google Chrome", version: ["103", "0", "5060", "134"] },
           { brand: "Chromium", version: ["103", "0", "5060", "134"] }],
platform: { brand: "Windows", version: ["15", "0", "0"] },
mobile: false,
architecture: "x86",
bitness: "64",
source: CLIENT_HINTS_HIGH_ENTROPY

उपयोगकर्ता-एजेंट हेडर और क्लाइंट हिंट के आधार पर डेटा अपने-आप भरा जा रहा है

कुछ फ़ील्ड में जानकारी अलग-अलग तरीके से भरी जाती है. यह इस बात पर निर्भर करता है कि वे उपयोगकर्ता-एजेंट हेडर पर आधारित हैं या क्लाइंट हिंट पर. इन अंतरों के बारे में नीचे खास जानकारी दी गई है:

  • एक जैसे ब्राउज़र और प्लैटफ़ॉर्म के लिए, उपयोगकर्ता एजेंट के हेडर या क्लाइंट हिंट के आधार पर, UserAgent.browsers.brand और UserAgent.platform.brand में अक्सर UserAgent का अंतर होता है. उदाहरण के लिए, अगर UserAgent.platform.brand, User-Agent हेडर पर आधारित होता, तो वह “Windows NT” या क्लाइंट हिंट पर आधारित होने पर “Windows” के तौर पर दिख सकता है.
  • कुछ UserAgent.browsers एंट्री, User-Agent हेडर या क्लाइंट हिंट के लिए यूनीक होती हैं. उदाहरण के लिए, अगर UserAgent उपयोगकर्ता-एजेंट हेडर पर आधारित था, तो “AppleWebKit” दिखेगा, जबकि “Chromium” सिर्फ़ तब दिखेगा, जब वह क्लाइंट हिंट पर आधारित होगा.
  • उपयोगकर्ता-एजेंट हेडर पर आधारित UserAgent में ही फ़्रीज़ की गई वैल्यू हो सकती हैं. उदाहरण के लिए, अगर प्लैटफ़ॉर्म Windows 11 22H2 है, तो UserAgent.platform.brand को “Windows NT” पर सेट किया जाएगा और UserAgent.platform.version को [“10”, “0”] पर सेट किया जाएगा, क्योंकि यह Windows के 10 या उसके बाद के किसी भी वर्शन के लिए फ़्रीज़ की गई वैल्यू है.

क्लाइंट हिंट पर आधारित UserAgent में मौजूद डेटा, आम तौर पर फ़्रीज़ की गई या छिपाने के लिए बदली गई जानकारी की जगह सही नहीं होगा. अगर उपयोगकर्ता-एजेंट हेडर और क्लाइंट हिंट के आधार पर UserAgent में कोई अंतर होता है, तो UserAgent की जानकारी को प्राथमिकता देनी चाहिए.

UserAgent ऑब्जेक्ट फ़ील्ड

इस सेक्शन में हर फ़ील्ड के बारे में खास जानकारी दी गई है. इसमें, खास तौर पर Google के आरटीबी के व्यवहार और इस्तेमाल के सबसे सही तरीकों पर फ़ोकस किया गया है.

ब्राउज़र

इसमें BrandVersion एंट्री की सूची होती है, जो आम तौर पर खासियत के हिसाब से क्रम में लगाई जाती हैं. उदाहरण के लिए, अगर आपको browsers के कॉन्टेंट की सूची बनानी है, तो हर एंट्री का brand इस क्रम में दिख सकता है:

ब्रैंड मतलब
Mozilla Mozilla के साथ काम करने वाला
AppleWebKit AppleWebKit-आधारित, Mozilla का एक सबसेट.
Chrome Chrome ब्राउज़र, AppleWebKit के साथ काम करने वाले ब्राउज़र का सबसेट
Safari मोबाइल के बजाय डेस्कटॉप का वैरिएंट.

UserAgent में ब्राउज़र को हमेशा किसी खास क्रम में नहीं रखा जाएगा. खास तौर पर, अगर यह क्लाइंट संकेतों पर आधारित हो, तो ऐसा करना ज़रूरी नहीं है. इस मेट्रिक में, source की वैल्यू के आधार पर दिखने वाले अन्य अंतर के बारे में बताया गया है:

  • USER_AGENT: version फ़ील्ड को मेजर वर्शन या फ़्रीज़ किए गए वर्शन में बदला जा सकता है. यह एजेंट की खास नीति पर निर्भर करता है. ध्यान दें, ऐसा कोई संकेत नहीं है कि वैल्यू को फ़्रीज़ किया गया है.
  • CLIENT_HINTS_LOW_ENTROPY और CLIENT_HINTS_HIGH_ENTROPY: एंट्री किसी भी शर्त के हिसाब से नहीं दी जाती हैं. उदाहरण के लिए, एक ही ब्राउज़र हर अनुरोध में इन एंट्री को अलग-अलग ऑर्डर में भेज सकता है. इनमें एक GREASE एंट्री भी शामिल हो सकती है, जिसे अनदेखा किया जाना चाहिए.
  • CLIENT_HINTS_HIGH_ENTROPY: ब्राउज़र में मिलने वाले सभी version फ़ील्ड पूरे वर्शन पर सेट हो सकते हैं.

प्लैटफ़ॉर्म

प्लैटफ़ॉर्म के बारे में जानकारी देने वाली BrandVersion एंट्री. ऐसा हो सकता है कि यह User-Agent हेडर और क्लाइंट हिंट के साथ काम न करे. इसलिए, कुछ प्लैटफ़ॉर्म को टारगेट करने के लिए आपको दो नामों की जांच करनी पड़ सकती है. उदाहरण के लिए, Apple के Macintosh ऑपरेटिंग सिस्टम को User-Agent हेडर में “Macintosh” के तौर पर दिखाया जाता है, जबकि Client Hears में “macOS” के तौर पर ब्रैंड किया जाता है. यहां उन अंतर के बारे में बताया गया है जो source की वैल्यू के आधार पर दिख सकते हैं:

  • USER_AGENT: version फ़ील्ड को मेजर वर्शन में बदला जा सकता है या फ़्रीज़ किया जा सकता है. ध्यान दें कि इसका कोई संकेत नहीं है कि वैल्यू को फ़्रीज़ किया गया है.
  • CLIENT_HINTS_LOW_ENTROPY: version फ़ील्ड में जानकारी नहीं भरी जाएगी.
  • CLIENT_HINTS_HIGH_ENTROPY: version फ़ील्ड को पूरे वर्शन पर सेट किया जा सकता है.

मोबाइल

इससे पता चलता है कि विज्ञापन जैसी सामग्री छोटी स्क्रीन और/या टच इनपुट के लिए ऑप्टिमाइज़ की जानी चाहिए या नहीं. ध्यान दें कि यह ज़रूरी नहीं है कि यह डिवाइस टाइप का संकेत दे, क्योंकि मोबाइल ब्राउज़र को “डेस्कटॉप साइट” का अनुरोध करने के लिए कॉन्फ़िगर किया जा सकता है.

आर्किटेक्चर

यह प्लैटफ़ॉर्म के आर्किटेक्चर की पहचान करता है, जैसे कि “x86” या “आर्म”.

क्लाइंट से मिले संकेतों के आधार पर UserAgent के लिए, ध्यान रखें कि यह जानकारी सिर्फ़ तब अपने-आप भर जाएगी, जब source को CLIENT_HINTS_HIGH_ENTROPY पर सेट किया गया हो.

बिटनेस

यह प्लैटफ़ॉर्म की बिटनेस की पहचान करता है, जैसे कि इसमें 32-बिट या 64-बिट वाला सीपीयू है. फ़ील्ड एक पूर्णांक स्ट्रिंग है, जो इसके आर्किटेक्चर के बारे में ज़्यादा जानकारी देती है. उदाहरण के लिए, किसी “x86” आर्किटेक्चर में “32” या “64” में से कोई एक बिटनेस सेट हो सकता है.

क्लाइंट से मिले संकेतों के आधार पर UserAgent के लिए, ध्यान रखें कि यह जानकारी सिर्फ़ तब अपने-आप भर जाएगी, जब source को CLIENT_HINTS_HIGH_ENTROPY पर सेट किया गया हो.

मॉडल

डिवाइस के मॉडल की पहचान करता है. लैपटॉप या डेस्कटॉप के लिए नहीं, बल्कि मोबाइल डिवाइसों के लिए इसके मॉडल का नाम दिखेगा, जैसे कि "Pixel 6 Pro".

यहां उन अंतर के बारे में बताया गया है जो source की वैल्यू के आधार पर दिख सकते हैं:

  • USER_AGENT
    • मोबाइल डिवाइस के अलावा दूसरे डिवाइस: model फ़ील्ड में अक्सर एक कंबाइंड आर्किटेक्चर और बिटनेस वैल्यू होती है, जैसे कि Windows के लिए “x64”. यह वैल्यू क्रॉस-प्लैटफ़ॉर्म नहीं है. उदाहरण के लिए, Linux एक ही हार्डवेयर के लिए “x86_64” का इस्तेमाल कर सकता है.
    • मोबाइल डिवाइस: इस फ़ील्ड में आर्किटेक्चर और बिटनेस शामिल नहीं होगी. अगर आपकी दिलचस्पी इन वैल्यू में है, तो UserAgent.architecture और UserAgent.bitness देखें.
  • CLIENT_HINTS_LOW_ENTROPY: model फ़ील्ड में जानकारी नहीं भरी जाएगी.
  • CLIENT_HINTS_HIGH_ENTROPY: model फ़ील्ड सिर्फ़ मोबाइल डिवाइस के डिवाइस मॉडल के लिए भरा जाएगा. डेस्कटॉप प्लैटफ़ॉर्म के लिए कोई वैल्यू सेट नहीं है.

सोर्स

इससे पता चलता है कि UserAgent बनाने के लिए कौनसे हेडर का इस्तेमाल किया गया है. क्लाइंट हिंट के लिए, यह इन दो मामलों में भी अंतर करता है:

  • CLIENT_HINTS_LOW_ENTROPY: सिर्फ़ बेसिक क्लाइंट हिंट उपलब्ध हैं.
  • CLIENT_HINTS_HIGH_ENTROPY: क्लाइंट हिंट उपलब्ध हैं. इसमें हाई एंट्रॉपी की कैटगरी में रखा गया कम से कम एक फ़ील्ड शामिल है.