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

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

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

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

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

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

उपयोगकर्ता एजेंट हेडर के उलट, 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 हेडर या क्लाइंट हिंट पर आधारित हैं या नहीं. इन अंतरों के बारे में खास जानकारी यहां दी गई है:

• एक जैसे ब्राउज़र और प्लैटफ़ॉर्म के लिए, UserAgent.browsers.brand और UserAgent.platform.brand में अक्सर अंतर होता है. यह अंतर, UserAgent के User-Agent हेडर या क्लाइंट हिंट के आधार पर होता है. उदाहरण के लिए, UserAgent.platform.brand को User-Agent हेडर के आधार पर “Windows NT” के तौर पर दिखाया जा सकता है. वहीं, क्लाइंट हिंट के आधार पर इसे “Windows” के तौर पर दिखाया जा सकता है.
• कुछ UserAgent.browsers एंट्री, User-Agent हेडर या क्लाइंट हिंट के लिए यूनीक होती हैं. उदाहरण के लिए, अगर UserAgent, User-Agent हेडर पर आधारित है, तो “AppleWebKit” दिखेगा. वहीं, अगर यह Client Hints पर आधारित है, तो “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 RTB से जुड़े व्यवहार और इस्तेमाल के सबसे सही तरीकों पर फ़ोकस किया गया है.

ब्राउज़र

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