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

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

User-Agent हेडर को BidRequest.device.ua फ़ील्ड में स्ट्रिंग के तौर पर दिखाया जाता है.

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

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

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

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

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

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

ध्यान दें: source फ़ील्ड का इस्तेमाल करके, यह पता लगाया जा सकता है कि UserAgent को भरने के लिए किसका इस्तेमाल किया गया है. उदाहरण के लिए, अगर इसे USER_AGENT_STRING पर सेट किया गया था, तो इसका मतलब है कि UserAgent को User-Agent हेडर के कॉन्टेंट के आधार पर पॉप्युलेट किया गया था.

उदाहरण: User-Agent हेडर के आधार पर 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

User-Agent हेडर के आधार पर अपने-आप पॉप्युलेट होने वाला 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, उन हेडर के कॉन्टेंट के आधार पर पॉप्युलेट होगा. भले ही, User-Agent हेडर मौजूद हों. यह इस तरह दिखेगा:

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

User-Agent हेडर बनाम क्लाइंट हिंट के आधार पर जानकारी भरना

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

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

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

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

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

ब्राउज़र

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

ब्रैंड	मतलब
मोज़िल्ला	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 ऑपरेटिंग सिस्टम को उपयोगकर्ता-एजेंट हेडर में “Macintosh” के तौर पर ब्रैंड किया गया है, लेकिन क्लाइंट हिंट में “macOS” के तौर पर. यहां source की वैल्यू के आधार पर दिखने वाले अन्य अंतरों के बारे में बताया गया है:

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

मोबाइल

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

आर्किटेक्चर

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

क्लाइंट हिंट पर आधारित 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: क्लाइंट हिंट उपलब्ध हैं. इनमें कम से कम एक ऐसा फ़ील्ड भी शामिल है जिसे ज़्यादा एन्ट्रोपी के तौर पर बांटा गया है.