कुकी मैचिंग

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

कॉन्सेप्ट

आम तौर पर, डोमेन के मालिक अपनी साइट ब्राउज़ करने वाले उपयोगकर्ताओं के लिए कुकी का कॉन्टेंट सेट करते हैं. इनका इस्तेमाल उस डोमेन में उपयोगकर्ताओं की पहचान करने के लिए किया जाता है. भले ही, दो डोमेन के मालिक इस डेटा को शेयर करने के लिए सहमत हों, लेकिन इंटरनेट ब्राउज़र का सुरक्षा मॉडल, एक डोमेन को दूसरे डोमेन की सेट की गई कुकी को पढ़ने से रोकता है.

डिजिटल विज्ञापन के संदर्भ में, Google उन उपयोगकर्ताओं की पहचान करता है जिनके पास doubleclick.net डोमेन की कुकी होती हैं. साथ ही, रीयल-टाइम बिडिंग में हिस्सा लेने वाले बिडर के पास अपना डोमेन हो सकता है. इस डोमेन में, वे उन उपयोगकर्ताओं की पहचान करते हैं जिन्हें वे विज्ञापन दिखाना चाहते हैं. कुकी मैचिंग की मदद से, बिडर अपनी कुकी को Google की कुकी से मैच कर सकते हैं. इससे वे यह तय कर सकते हैं कि बिड के अनुरोध में भेजा गया इंप्रेशन, टारगेट किए जा रहे उपयोगकर्ताओं में से किसी एक से जुड़ा है या नहीं. उन्हें अपना कुकी डेटा या बिडर के लिए खास Google उपयोगकर्ता आईडी मिलेगा. यह बिड के अनुरोध में मौजूद doubleclick.net कुकी का एन्क्रिप्ट (सुरक्षित) किया गया फ़ॉर्म होता है.

इस गाइड में बताई गई कुकी मैचिंग सेवा की मदद से, बिडर की कुकी और Google User ID के बीच संबंध बनाया और बनाए रखा जा सकता है. साथ ही, इससे उपयोगकर्ता सूचियां भी भरी जा सकती हैं.

मैच टेबल

मैच टेबल का इस्तेमाल, एक डोमेन के आईडी या अन्य डेटा को दूसरे डोमेन में मैप करने के लिए किया जा सकता है. बिडर, कुकी मैचिंग सेवा का इस्तेमाल करके अपनी मैच टेबल भर सकते हैं. इसके लिए, वे किसी उपयोगकर्ता की कुकी को उपयोगकर्ता के Google यूज़र आईडी से मैप करते हैं. इसके अलावा, वे Google की ओर से होस्ट की गई मैच टेबल को भी भर सकते हैं. बिडर के बिडिंग ऐप्लिकेशन के लिए मैच टेबल ज़रूरी होती हैं. इनकी मदद से, बिडिंग ऐप्लिकेशन उस उपयोगकर्ता के लिए कुकी का डेटा ऐक्सेस कर पाता है जिसे इंप्रेशन दिखाया जा रहा है.

Google पर होस्ट की गई मैच टेबल

हमारा सुझाव है कि आप Google को अपनी मैच टेबल होस्ट करने की अनुमति दें. इससे, रखरखाव को आसान बनाने, लेटेन्सी को कम करने, और कुछ देशों/इलाकों में उपयोगकर्ताओं के लिए मैच डेटा को ऐक्सेस करने में मदद मिलती है. इससे आपको वेब-सुरक्षित base64-एनकोडेड स्ट्रिंग तय करने की सुविधा मिलती है. इसे होस्ट किया गया मैच डेटा कहा जाता है. इसे किसी उपयोगकर्ता के Google User ID पर मैप किया जाएगा. मिलते-जुलते कॉन्टेंट का पता चलने के बाद, इसका इस्तेमाल इन तरीकों से किया जा सकता है:

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

  • उपयोगकर्ता सूचियां: उपयोगकर्ता सूचियों में, Google यूज़र आईडी या होस्ट किए गए मैच डेटा को भरा जा सकता है.

  • प्रीटारगेटिंग: प्रीटारगेटिंग को इस तरह से कॉन्फ़िगर किया जा सकता है कि आपको सिर्फ़ ऐसे बिड अनुरोध मिलें जिनमें होस्ट किया गया मैच डेटा शामिल हो. इसका इस्तेमाल, कुकी स्पेस से बाहर के उपयोगकर्ताओं के लिए, कम काम के इंप्रेशन को हटाने के लिए किया जा सकता है.

उपयोगकर्ता सूचियां

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

शुरू करें

कुकी मैचिंग का इस्तेमाल शुरू करने के लिए, आपको अपने टेक्निकल खाता मैनेजर से संपर्क करना होगा. वह कुछ खास वर्कफ़्लो चालू कर सकता है. साथ ही, यहां दी गई चीज़ों को कॉन्फ़िगर करने में आपकी मदद कर सकता है:

  • कुकी मैचिंग नेटवर्क आईडी (एनआईडी): यह एक स्ट्रिंग आईडी होता है. यह कुकी मैचिंग और इससे जुड़ी अन्य कार्रवाइयों के लिए, बिडर खाते की यूनीक पहचान करता है.
  • कुकी मैचिंग यूआरएल: यह एक ऐसे एंडपॉइंट का बेस यूआरएल होता है जो कुकी मैचिंग वर्कफ़्लो के तहत, आने वाले अनुरोधों को स्वीकार करेगा और उन्हें मैनेज करेगा. बिडर, इस यूआरएल में मैक्रो एम्बेड कर सकते हैं. इससे वे कुकी मैचिंग वर्कफ़्लो में, इस यूआरएल को पास किए गए पैरामीटर के क्रम को कंट्रोल कर सकते हैं.
  • मैच टैग: यह वह टैग है जिसे आपको उपयोगकर्ता के ब्राउज़र में रखना होगा. ऐसा बिडर की ओर से शुरू किए गए कुकी मैचिंग वर्कफ़्लो के लिए करना होगा. इसे विज्ञापनों के साथ दिखाया जा सकता है या विज्ञापनों के बाहर वेब प्रॉपर्टी पर रखा जा सकता है.
  • कुकी मैचिंग रिपोर्ट का यूआरएल (ज़रूरी नहीं): एकतरफ़ा कुकी मैचिंग वर्कफ़्लो में, यह एक ऐसा यूआरएल होता है जिसे उपलब्ध कराया जा सकता है. इससे एक ऐसे एंडपॉइंट के बारे में जानकारी मिलती है जिसे गड़बड़ी की जानकारी मिलेगी. ऐसा तब होता है, जब एचटीटीपी 302 रीडायरेक्ट के ज़रिए कुकी मैचिंग नहीं हो पाती है. डिफ़ॉल्ट रूप से, कुकी मैचिंग की प्रोसेस में गड़बड़ी होने पर ही जवाब इस यूआरएल पर भेजे जाएंगे. हालांकि, बिडर अनुरोध कर सकते हैं कि रीडायरेक्ट हमेशा भेजा जाए.
  • कुकी मैच असिस्ट यूआरएल: यह उन एक्सचेंज के लिए है जो कुकी मैच असिस्ट वर्कफ़्लो लागू करते हैं. यह उस एंडपॉइंट का बेस यूआरएल है जो आने वाले अनुरोधों का जवाब देता है.
  • कुकी मैच असिस्ट का कोटा: कुकी मैच असिस्ट वर्कफ़्लो लागू करने वाले एक्सचेंज के लिए, यह उन अनुरोधों की ज़्यादा से ज़्यादा संख्या है जो उनके कुकी मैचिंग यूआरएल को हर सेकंड मिल सकते हैं. इसका मकसद, सीएमए के अनुरोधों से एक्सचेंज के सर्वर पर ज़्यादा लोड पड़ने से रोकना है.

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

इस्तेमाल किए जा सकने वाले मैक्रो

बिडर के पास, कुकी मैचिंग यूआरएल को कॉन्फ़िगर करने का विकल्प होता है. इसमें एक या उससे ज़्यादा मैक्रो शामिल किए जा सकते हैं. ये मैक्रो, %%GOOGLE_<PARAM_NAME>%% या %%GOOGLE_<PARAM_NAME>_PAIR%% के फ़ॉर्मैट में होने चाहिए. इन मैक्रो और उनकी एक्सपैंड की गई वैल्यू का इस्तेमाल किया जा सकता है:

मैक्रो बढ़ाई गई वैल्यू
GOOGLE_GID GOOGLE_USER_ID
GOOGLE_GID_PAIR &google_gid=GOOGLE_USER_ID
GOOGLE_CVER COOKIE_VERSION_NUMBER
GOOGLE_CVER_PAIR &cver=COOKIE_VERSION_NUMBER
GOOGLE_ERROR ERROR_ID
GOOGLE_ERROR_PAIR &google_error=ERROR_ID
GOOGLE_PUSH PIXEL_MATCH_DATA
GOOGLE_PUSH_PAIR &google_push=PIXEL_MATCH_DATA
GOOGLE_ALL_PARAMS google_gid=GOOGLE_USER_ID&cver=COOKIE_VERSION_NUMBER&google_error=ERROR_ID

मैक्रो का उदाहरण

बिडर के पास https://user.bidder.com/cookies पर होस्ट किए गए एंडपॉइंट के साथ कुकी मैचिंग इंटिग्रेशन है. साथ ही, इसे लागू करने के लिए, बिडर की ओर से पहले से तय किए गए पैरामीटर के साथ-साथ, पूरी तरह मैच होने वाले पिक्सल पैरामीटर की ज़रूरत होती है. ये पैरामीटर इस क्रम में होने चाहिए: google_push, google_gid, google_cver, और google_error. बिडर, कुकी मैचिंग यूआरएल को इस तरह सेट करके ऐसा कर सकता है:

https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%

जब Google बाद में इस बिडर को मैच करने का अनुरोध भेजता है, तो इसे इस तरह से बढ़ाया जाएगा:

https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3

Google की कुकी मैचिंग सेवा, इन तीन वर्कफ़्लो के साथ काम करती है.

दोनों तरफ़ से कुकी मैच करने की सुविधा, बिडर की ओर से शुरू की गई वर्कफ़्लो को रेफ़र करती है. इसमें बिडर, उपयोगकर्ता के ब्राउज़र में एक मैच टैग रखता है, जो उसे Google पर रीडायरेक्ट करता है. इस वर्कफ़्लो की मदद से, Google और बिडर, दोनों मैच टेबल भर सकते हैं. इस वर्कफ़्लो का एक उदाहरण यहां दिया गया है.

पहला चरण: मैच टैग को प्लेस करना

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

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />

मैच टैग में अतिरिक्त पैरामीटर शामिल किए जा सकते हैं, ताकि अलग-अलग इस्तेमाल के उदाहरणों को पूरा किया जा सके. इन पैरामीटर के बारे में ज़्यादा जानने के लिए, टैग के यूआरएल पैरामीटर मैच करना लेख पढ़ें.

दूसरा चरण: Google, मैच किए गए डेटा के साथ रीडायरेक्ट करके जवाब देता है

मैच टैग की वजह से, Google की कुकी मैचिंग सेवा को उपयोगकर्ता के ब्राउज़र से अनुरोध मिलेगा. इसके बाद, यह सेवा बिडर के कुकी मैचिंग यूआरएल पर HTTP 302 रीडायरेक्ट करेगी. रीडाइरेक्ट में क्वेरी पैरामीटर शामिल होंगे. ये पैरामीटर, यूआरएल में Google यूज़र आईडी और उसके वर्शन नंबर के बारे में जानकारी देंगे. साथ ही, बिडर को अनुरोध हेडर में शामिल की गई अपनी कुकी भी मिलेगी. असल में, https://ad.network.com/pixel के तौर पर तय किए गए कुकी मैचिंग यूआरएल के लिए, पिछले मैच टैग का रीडायरेक्ट यूआरएल कुछ ऐसा दिख सकता है:

https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

google_gid पैरामीटर के ज़रिए पास किया गया Google User ID, बिना पैडिंग वाली वेब-सेफ़ base64-encoded स्ट्रिंग होती है. बिडर को मैच टेबल होस्ट करने का विकल्प मिलता है. हमारा सुझाव है कि वे कुकी मैचिंग सेवा से मिली स्ट्रिंग को सेव करें. इसके बाद की बिड रिक्वेस्ट में, यह BidRequest.user.id के ज़रिए दी गई वैल्यू से मेल खाएगा.

google_cver में दिया गया वर्शन, Google User ID के लिए संख्या वाला वर्शन नंबर दिखाता है. किसी उपयोगकर्ता के लिए Google यूज़र आईडी कभी-कभी बदलता है. इसके बाद, इसे बढ़ा दिया जाता है.

अगर Google को मैच करने के आपके अनुरोध को प्रोसेस करते समय कोई गड़बड़ी मिलती है, तो google_error पैरामीटर सेट किया जाएगा.

तीसरा चरण: बिडर, रीडायरेक्ट प्रोसेस करता है और पिक्सल के साथ जवाब देता है

बिडर को कुकी मैचिंग यूआरएल पर रीडायरेक्ट किया जाता है. इसमें वे पैरामीटर शामिल होते हैं जो बिडर ने पहले चरण में तय किए थे. साथ ही, वे पैरामीटर भी शामिल होते हैं जो Google ने दूसरे चरण में दिए थे. इसके अलावा, उन्हें अपना कुकी भी HTTP हेडर में मिलेगा. अगर यह कार्रवाई पूरी हो जाती है, तो मैच टेबल होस्ट करने वाला बिडर, अपनी कुकी को जवाब में शामिल Google यूज़र आईडी से मैच कर सकता है. हमारा सुझाव है कि बिडर, कुकी मैचिंग सेवा से मिली स्ट्रिंग को सेव करें.

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

बिडर को हमेशा 1x1 पिक्सल वाली ऐसी इमेज दिखानी चाहिए जो दिखती न हो. इसके अलावा, बिडर HTTP 204 कोई कॉन्टेंट नहीं है वाला जवाब भी दे सकता है.

इस वर्कफ़्लो को इस डायग्राम में दिखाया गया है. इसमें अनुरोधों और जवाबों को ऐरो से दिखाया गया है. साथ ही, उनके साथ मौजूद डेटा आइटम को ब्रैकेट में दिखाया गया है.

टैग के यूआरएल पैरामीटर से मैच करना

पैरामीटर ब्यौरा
google_nid बिडर खाते के लिए नेटवर्क आईडी (एनआईडी). इस आईडी को Bidders रिसॉर्स के ज़रिए वापस पाया जा सकता है.
google_cm यह Google की कुकी मैचिंग सेवा को यह जानकारी देता है कि उसे कुकी मैचिंग करनी चाहिए. पैरामीटर की वैल्यू को अनदेखा किया जाता है और इसे छोड़ा जा सकता है.
google_sc इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. अगर उपयोगकर्ता के लिए Google की कुकी मौजूद नहीं है, तो यह कुकी उसे सेट करती है. पैरामीटर की वैल्यू को अनदेखा किया जाता है और इसे छोड़ा जा सकता है. अगर कोई कुकी मौजूद नहीं है, तो पैरामीटर को शामिल न करने पर गड़बड़ी होती है.
google_no_sc इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. इससे Google की Cookie Matching Service को यह पता चलता है कि अगर उपयोगकर्ता के लिए कोई कुकी मौजूद नहीं है, तो उसे कुकी सेट नहीं करनी चाहिए. पैरामीटर की वैल्यू को अनदेखा किया जाता है और इसे छोड़ा जा सकता है.
google_hm

ऐसा डेटा जिसे बिडर, Google के होस्ट किए गए मैच टेबल में सेव करना चाहता है.

यह वैल्यू, वेब के लिए सुरक्षित base64-एनकोडेड स्ट्रिंग होती है. इसमें पैडिंग का इस्तेमाल करना ज़रूरी नहीं है. कच्चा डेटा 40 बाइट या इससे कम होना चाहिए. उदाहरण के लिए, Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u.
google_redir यह यूआरएल के डेटा को कोड में बदली गई ऐसी स्ट्रिंग होती है जिसे बिडर तब तय कर सकता है, जब उसे Google को यह निर्देश देना हो कि वह इस मैच टैग के लिए, HTTP 302 रीडायरेक्ट को कोड में बदले गए यूआरएल पर भेजे. इससे Google को पार्टनर को किए जाने वाले चेन किए गए कॉल में सबसे आगे रखा जा सकता है. अगर इसे google_hm के बिना या google_cm के साथ तय किया जाता है, तो गड़बड़ी का मैसेज दिखेगा.
google_ula इस स्ट्रिंग का इस्तेमाल, उपयोगकर्ता को मौजूदा उपयोगकर्ता सूची में जोड़ने के लिए किया जाता है. वैल्यू का अनुमानित फ़ॉर्मैट userlistid[,timestamp] है:
  • userlistid: उपयोगकर्ता सूची का एक संख्यात्मक आईडी.
  • timestamp: POSIX फ़ॉर्मैट में एक वैकल्पिक टाइमस्टैंप. इससे पता चलता है कि उपयोगकर्ता को उपयोगकर्ता सूची में कब जोड़ा गया था.

उपयोगकर्ता को एक से ज़्यादा सूचियों में जोड़ने के लिए, इस यूआरएल पैरामीटर को दोहराया जा सकता है.
gdpr इससे पता चलता है कि डेटा के इस्तेमाल पर, जीडीपीआर की पाबंदियां लागू होती हैं. ज़्यादा जानकारी के लिए, ईयू के उपयोगकर्ता की सहमति से जुड़ी ज़रूरी शर्तें या कुकी मैच करने की ज़रूरी शर्तों पर पड़ने वाला असर देखें. ये जानकारी, Authorized Buyers के IAB टीसीएफ़ v2.0 के दस्तावेज़ में दी गई है.

उदाहरण: gdpr=1
gdpr_consent टीसी स्ट्रिंग, जो असली उपयोगकर्ता की सहमति को दिखाती है. ज़्यादा जानकारी के लिए, ईयू में रहने वाले उपयोगकर्ताओं की सहमति लेने से जुड़ी ज़रूरी शर्तें देखें. इसके अलावा, टीसी स्ट्रिंग कैसे पास की जाएगी? के बारे में जानने के लिए, Authorized Buyers के IAB टीसीएफ़ 2.0 वर्शन का दस्तावेज़ देखें.
process_consent इससे पता चलता है कि बिडर ने Google की ईयू उपयोगकर्ता की सहमति से जुड़ी नीति में बताए गए डेटा के इस्तेमाल के लिए, असली उपयोगकर्ता की सहमति ली है.

अगर अनुरोध, ईयू उपयोगकर्ता की सहमति से जुड़ी नीति के दायरे में नहीं आता है या अनुरोध में सहमति के अन्य पैरामीटर उपलब्ध हैं (gdpr_consent), तो इस पैरामीटर को अनदेखा कर दिया जाता है.

उदाहरण: process_consent=T

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

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />

रीडायरेक्ट यूआरएल पैरामीटर

रीडायरेक्ट यूआरएल, बिडर के खाते के लिए कॉन्फ़िगर किए गए बेस कुकी मैचिंग यूआरएल से बनाया जाता है. इसमें google_ और बिडर के तय किए गए पैरामीटर शामिल होते हैं. ये पैरामीटर, मैच टैग में तय किए गए पैरामीटर पर निर्भर करते हैं. google_ के इन रिस्पॉन्स पैरामीटर को तय किया गया है:

पैरामीटर ब्यौरा
google_gid Google का यूज़र आईडी. अगर अनुरोध में google_cm तय किया गया है और अनुरोध पूरा हो गया है, तो इसे सेट करें.
google_cver कुकी का वर्शन. अगर अनुरोध में google_cm तय किया गया है और अनुरोध पूरा हो गया है, तो इसे सेट करें.
google_error

यह एक पूर्णांक वैल्यू होती है, जो अनुरोध से जुड़ी गड़बड़ी के बारे में बताती है. यह जवाब मिलने का मतलब है कि कोई कार्रवाई नहीं की गई है. साथ ही, google_ के जवाब के अन्य पैरामीटर सेट नहीं किए जाएंगे. गड़बड़ी की इन वैल्यू का इस्तेमाल किया जा सकता है:

  • 1: उपयोगकर्ता के पास Google की कुकी है, लेकिन उसने इस कुकी का इस्तेमाल करके किसी भी तरह की ट्रैकिंग से ऑप्ट आउट किया है.
  • 2: कोई मान्य कार्रवाई तय नहीं की गई है. उदाहरण के लिए, कोई कार्रवाई नहीं करने का अनुरोध मिला है.
  • 3: उपयोगकर्ता के पास Google कुकी नहीं है. Google, कुकी मैचिंग सेवा के ज़रिए कुकी सेट नहीं करेगा.
  • 4: टकराव वाली कार्रवाइयां तय की गई हैं. एक ही अनुरोध में google_push और google_cm, दोनों फ़्लैग नहीं दिए जा सकते, क्योंकि इनके मकसद अलग-अलग हैं.
  • 5: Google सर्वर को रीडायरेक्ट करते समय, अमान्य google_push पैरामीटर पास किया गया था. यह दोनों दिशाओं में होने वाले पिक्सल मैचिंग अनुरोध का हिस्सा था. रीडायरेक्ट में, google_push को वही वैल्यू सेट करनी होगी जो आपको पिक्सल के शुरुआती अनुरोध में मिली थी.
  • 6: मैच टैग में अमान्य एनआईडी दिया गया था.
  • 7: एक अमान्य कुकी का पता चला है.
  • 8: अब सेवा में नहीं है. कोई कुकी नहीं मिली.
  • 9: कोई कुकी नहीं मिली. टेस्ट कुकी सेट करने की कोशिश की गई है.
  • 10: google_redir पैरामीटर का इस्तेमाल, google_hm की जानकारी दिए बिना किया गया था. इसके अलावा, इसका इस्तेमाल google_cm के साथ भी किया गया था.
  • 15: अनुरोध उस इलाके से आया है जहां Google को मैच टेबल को Google पर होस्ट करना ज़रूरी है. इस वजह से, इस जवाब में Google उपयोगकर्ता आईडी शामिल नहीं है.
google_hm

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

  • 1 - अनुमति नहीं है: ग्राहक के पास, होस्ट की गई मैच टेबल की एंट्री में बदलाव करने का ऐक्सेस नहीं है.
  • 2 - डिकोड करने में गड़बड़ी: पैरामीटर की वैल्यू को डिकोड नहीं किया जा सका.
  • 3 - पेलोड बहुत लंबा है: पैरामीटर की वैल्यू को डिकोड करने पर, 40 बाइट से ज़्यादा का डेटा मिलता है.
  • 4 - सिस्टम की गड़बड़ी: डेटा सेव करते समय सिस्टम में कोई गड़बड़ी हुई.
  • 5 - थ्रॉटल किया गया: थ्रॉटलिंग की वजह से, इस राइट को प्रोसेस नहीं किया गया.
google_ula

उपयोगकर्ता सूची में जोड़ने की कार्रवाई की स्थिति. अगर अनुरोध में एक से ज़्यादा google_ula बताए गए थे, तो इसे दोहराया जाता है. फ़ॉर्मैट यह है:
userlistid,status code

उदा: google_ula=1234567890,0

google_ula ऑपरेशन, इनमें से कोई भी स्टेटस कोड दिखा सकता है:

  • 0 - कोई गड़बड़ी नहीं है. उपयोगकर्ता को उपयोगकर्ता सूची में जोड़ दिया गया है.
  • 2 - अनुमति नहीं दी गई. आपके पास दी गई उपयोगकर्ता सूची में उपयोगकर्ताओं को जोड़ने की अनुमति नहीं है.
  • 5 - उपयोगकर्ता सूची का आईडी अमान्य है. उपयोगकर्ता सूची का दिया गया आईडी अमान्य है.
  • 6 - बंद किए गए एट्रिब्यूट का आईडी. उपयोगकर्ता सूची का दिया गया आईडी बंद है.
  • 10 - सिस्टम की गड़बड़ी. कुकी मैचिंग सेवा में कोई गड़बड़ी हुई है. उपयोगकर्ता को फिर से मैच करने की कोशिश की जा सकती है.

यहां दिए गए उदाहरणों में बताया गया है कि वेब पेज ब्राउज़ करने वाले किसी सामान्य उपयोगकर्ता के लिए, कुकी मैचिंग कैसी दिख सकती है.

पहला उदाहरण: उपयोगकर्ता अपनी कुकी मिटाता है और किसी साइट को ब्राउज़ करता है

जेन सभी कुकी की कैश मेमोरी मिटा देती है. इसके बाद, वे ExampleNews.com के होम पेज पर जाते हैं.

यहां देखें कि क्या होता है:

  1. ExampleNews.com, Google (Ad Manager) से विज्ञापन रेंडर करता है और उन्हें कॉल करता है.
  2. ऐड यूनिट, डाइनैमिक तौर पर विज्ञापन स्लॉट असाइन करने की सुविधा के लिए ज़रूरी शर्तें पूरी करती है. इसलिए, Google, रीयल-टाइम बिडिंग सेवा के ज़रिए FinestDSP और बिड लगाने वाले अन्य लोगों को बिड के अनुरोध भेजता है.
  3. FinestDSP का बिडर ऐप्लिकेशन, बिड रिक्वेस्ट को स्वीकार करता है और उसे प्रोसेस करता है. इसके बाद, बिड का जवाब भेजता है.
  4. Google को बिडर्स से बिड रिस्पॉन्स मिलते हैं. इनमें FinestDSP का वह रिस्पॉन्स भी शामिल है जिसमें मैच टैग (पिक्सल) वाला विज्ञापन शामिल होता है.
  5. नीलामी में FinestDSP जीत जाता है. Google, Jane को FinestDSP का विज्ञापन और मैच टैग दिखाता है.
  6. मैच टैग, Google की कुकी मैच सर्विस को कॉल करता है. इसमें google_nid और google_cm पैरामीटर तय किए जाते हैं.
  7. कुकी मैच सर्विस, जेन की Google कुकी को पढ़ती है. इसके बाद, जेन के ब्राउज़र को FinestDSP के कुकी मैचिंग यूआरएल पर रीडायरेक्ट करती है. इसमें google_gid और google_cver पैरामीटर सेट होते हैं.
  8. जेन का ब्राउज़र, FinestDSP के कुकी मैच यूआरएल पर रीडायरेक्ट होने की प्रोसेस को लोड करता है.
  9. FinestDSP का कुकी मैचिंग एंडपॉइंट, रीडायरेक्ट के अनुरोध को प्रोसेस करता है. इसमें Google की ओर से सेट किए गए यूआरएल पैरामीटर और एचटीटीपी हेडर में Jane के लिए उनकी कुकी शामिल होती है. FinestDSP अब अपनी मैच टेबल में, अपनी कुकी की मैपिंग को google_gid में सेव कर सकता है.
  10. FinestDSP, रीडायरेक्ट का जवाब एक अदृश्य 1x1 पिक्सल से देता है.
दूसरी स्थिति: ऐसा उपयोगकर्ता जिसकी मैपिंग पहले से मौजूद है

पहले सीन के एक हफ़्ते बाद, जेन फिर से ExampleNews.com पर जाती है. अब जेन के पास अपने कंप्यूटर पर बिडर और Ad Manager, दोनों की कुकी हैं. इसलिए, यहां बताया गया है कि मैचिंग कैसे काम करती है.

  1. वेब पेज रेंडर होता है. इससे Google (Ad Manager) ऐसे विज्ञापनों का अनुरोध करता है जो पेज पर रेंडर किए जाएंगे.
  2. विज्ञापन की नीलामी के दौरान, Google बिडिंग करने वाले लोगों या कंपनियों को बिड रिक्वेस्ट भेजता है. इनमें FinestDSP भी शामिल है.
  3. FinestDSP को बिड रिक्वेस्ट मिलती है. इसमें google_gid जैसे सिग्नल शामिल होते हैं.
  4. FinestDSP, अपनी मैच टेबल में google_gid को ढूंढता है. इसके बाद, उसे Jane से जुड़ी वह कुकी मिलती है जो एक हफ़्ते पहले बनाई गई थी (पहले उदाहरण में).
  5. कुकी से जुड़ी जानकारी के आधार पर, FinestDSP का बिडिंग लॉजिक, इंप्रेशन पर बिड लगाता है और नीलामी जीत जाता है.
  6. जेन को उसकी दिलचस्पी के हिसाब से विज्ञापन दिख सकता है. यह विज्ञापन, FinestDSP के पास मौजूद जानकारी के आधार पर दिखाया जाता है.

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

पहला चरण: मैच टैग को बिडर के कुकी मैचिंग यूआरएल पर डायरेक्ट करें

इस फ़्लो को शुरू करने के लिए, बिडर को एक मैच टैग लगाना होगा, ताकि वह उपयोगकर्ता के ब्राउज़र में रेंडर हो सके. अमेरिका के उन राज्यों के उपयोगकर्ताओं के लिए, निजता से जुड़ी पाबंदियों के बिना काम करने वाले उपयोगकर्ताओं के वर्कफ़्लो के उलट, मैच टैग को उपयोगकर्ता के ब्राउज़र को कुकी मैचिंग वाले यूआरएल पर रीडायरेक्ट करना होगा. उदाहरण के लिए, अगर कुकी मैचिंग यूआरएल को https://ad.network.com/pixel के तौर पर कॉन्फ़िगर किया गया है, तो यह ऐसा दिखेगा:

<img src="https://ad.network.com/pixel" />

उपयोगकर्ता के ब्राउज़र में लोड होने पर, यह बिडर के कुकी मैचिंग यूआरएल से पिक्सल का अनुरोध करेगा. इस अनुरोध में, एचटीटीपी हेडर में उनकी कुकी शामिल होगी. अगले चरण के लिए, इसे एक्सट्रैक्ट किया जाना चाहिए.

बिडर के कुकी मैचिंग एंडपॉइंट को Google की कुकी मैचिंग सेवा पर रीडायरेक्ट करना होगा. इसमें google_hm पैरामीटर भी शामिल है, जिसमें वेब-सुरक्षित base64-encoded कुकी डेटा भरा गया है. रीडायरेक्ट यूआरएल कुछ ऐसा दिख सकता है:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA

Google को एक रीडायरेक्ट मिलेगा. इसमें आपके तय किए गए पैरामीटर शामिल होंगे. साथ ही, एचटीटीपी हेडर में Google की कुकी भी शामिल होगी.

चौथा चरण: अगर रिपोर्ट यूआरएल दिया गया है, तो Google, रीडायरेक्ट होने पर पिक्सल को दिखाता है. ऐसा तब होता है, जब रीडायरेक्ट सही तरीके से होता है या उसमें कोई गड़बड़ी होती है

अगर कुकी मैचिंग की प्रोसेस पूरी हो जाती है या बिडर के खाते के लिए कोई कुकी मैचिंग रिपोर्ट यूआरएल नहीं दिया गया है, तो Google डिफ़ॉल्ट रूप से 1x1 ट्रांसपैरंट पिक्सल दिखाएगा. इसके बाद, वर्कफ़्लो खत्म हो जाएगा. बिड के बाद के अनुरोधों में, इस उपयोगकर्ता के लिए इंप्रेशन में बिडर का होस्ट किया गया मैच डेटा BidRequest.user.buyeruid में शामिल होगा. बिडर, होस्ट किए गए मैच डेटा का इस्तेमाल करके भी उपयोगकर्ता सूचियां भर सकते हैं.

अगर कोई गड़बड़ी होती है, तो Google, बिडर को कुकी मैचिंग रिपोर्ट के यूआरएल पर रीडायरेक्ट कर देगा. साथ ही, गड़बड़ी की वजह google_error पैरामीटर में बता देगा. अगर बिडर की कुकी मैचिंग रिपोर्ट का यूआरएल https://ad.network.com/report है, तो रीडायरेक्ट यूआरएल इस तरह दिखेगा:

<img src="https://ad.network.com/report?google_error=ERROR_ID" />

उपयोगकर्ता का ब्राउज़र, बिडर के कुकी मैचिंग रिपोर्ट यूआरएल पर रीडायरेक्ट हो जाएगा. इसमें, Google की ओर से google_error पैरामीटर में बताई गई गड़बड़ी की वजह (अगर कोई हो) भी शामिल होगी. गड़बड़ी के कोड को समझने के बारे में ज़्यादा जानने के लिए, पैरामीटर का ब्यौरा देखें.

छठा चरण: बिडर, 1x1 ट्रांसपैरंट पिक्सल दिखाता है

बिडर को उपयोगकर्ता के ब्राउज़र को 1x1 ट्रांसपैरंट पिक्सल भेजकर जवाब देना होगा.

निजता से जुड़ी पाबंदियों वाले अमेरिकी राज्यों में उपयोगकर्ताओं के लिए, डिफ़ॉल्ट वर्कफ़्लो को इस डायग्राम में दिखाया गया है. इसमें अनुरोधों और जवाबों को ऐरो से दिखाया गया है. साथ ही, उनके साथ मौजूद डेटा आइटम को कोष्ठक में दिखाया गया है.

पैरामीटर ब्यौरा
google_nid बिडर खाते के लिए नेटवर्क आईडी (एनआईडी). इस आईडी को Bidders रिसॉर्स के ज़रिए वापस पाया जा सकता है.
google_sc इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. अगर उपयोगकर्ता के लिए Google की कुकी मौजूद नहीं है, तो यह कुकी उसे सेट करती है. पैरामीटर की वैल्यू को अनदेखा किया जाता है और इसे छोड़ा जा सकता है. अगर कोई कुकी मौजूद नहीं है, तो पैरामीटर को शामिल न करने पर गड़बड़ी होती है.
google_no_sc इस पैरामीटर का इस्तेमाल बंद कर दिया गया है. इससे Google की Cookie Matching Service को यह पता चलता है कि अगर उपयोगकर्ता के लिए कोई कुकी मौजूद नहीं है, तो उसे कुकी सेट नहीं करनी चाहिए. पैरामीटर की वैल्यू को अनदेखा किया जाता है और इसे छोड़ा जा सकता है.
google_hm

इसमें वह डेटा होता है जिसे बिडर, Google के होस्ट किए गए मैच टेबल में सेव करना चाहता है.
google_redir यह एक ऐसा कोड में बदला गया यूआरएल होता है जिस पर Google को एचटीटीपी 302 रीडायरेक्ट भेजना होता है. आपने जिस यूआरएल को चुना है उस पर रीडायरेक्ट किए जाएंगे. साथ ही, गड़बड़ियों और कार्रवाइयों के पूरा होने की जानकारी के लिए, google_error पैरामीटर का इस्तेमाल किया जाएगा.
google_ula इस स्ट्रिंग का इस्तेमाल, उपयोगकर्ता को मौजूदा उपयोगकर्ता सूची में जोड़ने के लिए किया जाता है. वैल्यू का अनुमानित फ़ॉर्मैट userlistid[,timestamp] है:
  • userlistid: उपयोगकर्ता सूची का एक संख्यात्मक आईडी.
  • timestamp: POSIX फ़ॉर्मैट में एक वैकल्पिक टाइमस्टैंप. इससे पता चलता है कि उपयोगकर्ता को उपयोगकर्ता सूची में कब जोड़ा गया था.

उपयोगकर्ता को एक से ज़्यादा सूचियों में जोड़ने के लिए, इस यूआरएल पैरामीटर को दोहराया जा सकता है.
gdpr इससे पता चलता है कि डेटा के इस्तेमाल पर, जीडीपीआर की पाबंदियां लागू होती हैं. ज़्यादा जानकारी के लिए, ईयू के उपयोगकर्ता की सहमति से जुड़ी ज़रूरी शर्तें या कुकी मैच करने की ज़रूरी शर्तों पर पड़ने वाला असर देखें. ये जानकारी, Authorized Buyers के IAB टीसीएफ़ v2.0 के दस्तावेज़ में दी गई है.

उदाहरण: gdpr=1
gdpr_consent टीसी स्ट्रिंग, जो असली उपयोगकर्ता की सहमति को दिखाती है. ज़्यादा जानकारी के लिए, ईयू में रहने वाले उपयोगकर्ताओं की सहमति लेने से जुड़ी ज़रूरी शर्तें देखें. इसके अलावा, टीसी स्ट्रिंग कैसे पास की जाएगी? के बारे में जानने के लिए, Authorized Buyers के IAB टीसीएफ़ 2.0 वर्शन का दस्तावेज़ देखें.
process_consent इससे पता चलता है कि बिडर ने Google की ईयू उपयोगकर्ता की सहमति से जुड़ी नीति में बताए गए डेटा के इस्तेमाल के लिए, असली उपयोगकर्ता की सहमति ली है.

अगर अनुरोध, ईयू उपयोगकर्ता की सहमति से जुड़ी नीति के दायरे में नहीं आता है या अनुरोध में सहमति के अन्य पैरामीटर उपलब्ध हैं (gdpr_consent), तो इस पैरामीटर को अनदेखा कर दिया जाता है.

उदाहरण: process_consent=T
पैरामीटर ब्यौरा
google_error

यह एक पूर्णांक वैल्यू होती है, जो अनुरोध से जुड़ी गड़बड़ी के बारे में बताती है. यह जवाब मिलने का मतलब है कि कोई कार्रवाई नहीं की गई है. साथ ही, google_ के जवाब के अन्य पैरामीटर सेट नहीं किए जाएंगे. गड़बड़ी की इन वैल्यू का इस्तेमाल किया जा सकता है:

  • 1: उपयोगकर्ता के पास Google की कुकी है, लेकिन उसने इस कुकी का इस्तेमाल करके किसी भी तरह की ट्रैकिंग से ऑप्ट आउट किया है.
  • 2: कोई मान्य कार्रवाई तय नहीं की गई है. उदाहरण के लिए, कोई कार्रवाई नहीं करने का अनुरोध मिला है.
  • 3: उपयोगकर्ता के पास Google कुकी नहीं है. Google, कुकी मैचिंग सेवा के ज़रिए कुकी सेट नहीं करेगा.
  • 4: टकराव वाली कार्रवाइयां तय की गई हैं. एक ही अनुरोध में google_push और google_cm, दोनों फ़्लैग नहीं दिए जा सकते, क्योंकि इनके मकसद अलग-अलग हैं.
  • 5: Google सर्वर को रीडायरेक्ट करते समय, अमान्य google_push पैरामीटर पास किया गया था. यह दोनों दिशाओं में होने वाले पिक्सल मैचिंग अनुरोध का हिस्सा था. रीडायरेक्ट में, google_push को वही वैल्यू सेट करनी होगी जो आपको पिक्सल के शुरुआती अनुरोध में मिली थी.
  • 6: मैच टैग में अमान्य एनआईडी दिया गया था.
  • 7: एक अमान्य कुकी का पता चला है.
  • 8: अब सेवा में नहीं है. कोई कुकी नहीं मिली.
  • 9: कोई कुकी नहीं मिली. टेस्ट कुकी सेट करने की कोशिश की गई है.
  • 10: google_redir पैरामीटर का इस्तेमाल, google_hm की जानकारी दिए बिना किया गया था. इसके अलावा, इसका इस्तेमाल google_cm के साथ भी किया गया था.
  • 15: अनुरोध उस इलाके से आया है जहां Google को मैच टेबल को Google पर होस्ट करना ज़रूरी है. इस वजह से, इस जवाब में Google उपयोगकर्ता आईडी शामिल नहीं है.

Google की ओर से शुरू किया गया: दोनों तरफ़ से पिक्सल मैचिंग

दोनों तरफ़ से पिक्सल मैचिंग, Google की कुकी मैचिंग सेवा के लिए एक वर्कफ़्लो है. इसमें Google, एल्गोरिदम के हिसाब से चुने गए बिडर के Google User ID को मैच करने की कोशिश करता है. यह बिडर, रीयल-टाइम बिडिंग की नीलामी जीतने वाले बिडर के अलावा कोई और होता है. जब कोई विज्ञापन दिखाया जाता है, तब Google एक मैच टैग सेट करता है. यह टैग, उपयोगकर्ता के ब्राउज़र को उस बिडर के कुकी मैचिंग यूआरएल से एक पारदर्शी पिक्सल लोड करने का निर्देश देता है जिसे चुना गया है. इससे Google और बिडर, दोनों को किसी उपयोगकर्ता के साथ मैच टेबल को भरने की अनुमति मिलेगी. इस वर्कफ़्लो का एक उदाहरण यहां दिया गया है.

पहला चरण: Google, मैच टैग सेट करता है

जब उपयोगकर्ता के ब्राउज़र में, प्रोग्राम में हिस्सा लेने वाले पब्लिशर का पेज लोड होता है और उस पेज पर मौजूद विज्ञापन स्लॉट में Google विज्ञापन दिखाता है, तो मैच टैग लगाया जा सकता है. यह टैग, एल्गोरिदम के हिसाब से चुने गए बिडर से पिक्सल का अनुरोध करता है. Google की ओर से प्लेस किया गया पिक्सल मैचिंग टैग, बिडर के कुकी मैचिंग यूआरएल को अतिरिक्त पैरामीटर के साथ जोड़ता है. बिडर इन पैरामीटर का इस्तेमाल, अपनी मैच टेबल को भरने के लिए कर सकता है. https://ad.network.com/pixel के तौर पर तय किए गए कुकी मैचिंग यूआरएल के लिए, इसका स्ट्रक्चर इस तरह होता है:

<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />

बिड लगाने वालों को पिक्सल मैचिंग के अनुरोध मिलते हैं. उन्हें Google की कुकी मैचिंग सेवा पर रीडायरेक्ट करके जवाब देना होता है. इसका स्ट्रक्चर इस तरह होता है:

https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA

ध्यान दें कि ऊपर दिया गया रीडायरेक्ट यूआरएल, बिडर के ज़रिए शुरू किए गए कुकी मैचिंग वर्कफ़्लो के लिए मैच टैग में इस्तेमाल किए गए यूआरएल जैसा ही है. पिक्सल मैचिंग में, google_cm पैरामीटर को google_push पैरामीटर से बदल दिया जाता है. साथ ही, इसकी वैल्यू, अनुरोध में Google की ओर से दी गई वैल्यू के बराबर होनी चाहिए. बिडर के शुरू किए गए वर्कफ़्लो की तरह ही, इस्तेमाल के अन्य उदाहरणों को पूरा करने के लिए, अतिरिक्त पैरामीटर तय किए जा सकते हैं.

तीसरा चरण: Google, रीडायरेक्ट को प्रोसेस करता है और पिक्सल के साथ जवाब देता है

Google यह लॉग करता है कि उपयोगकर्ता के लिए मैच बनाया गया है. साथ ही, क्वेरी पैरामीटर के ज़रिए अनुरोध की गई किसी भी अतिरिक्त कार्रवाई को मैनेज करता है. आखिर में, Google 1x1 ट्रांसपैरंट पिक्सल के साथ जवाब देता है.

Pixel Matching के वर्कफ़्लो का डायग्राम

इस वर्कफ़्लो को इस डायग्राम में दिखाया गया है. इसमें अनुरोधों और जवाबों को ऐरो से दिखाया गया है. साथ ही, उनके साथ मौजूद डेटा आइटम को ब्रैकेट में दिखाया गया है.

Google मैच टैग के अनुरोध वाले पैरामीटर

पैरामीटर ब्यौरा
google_gid Google का यूज़र आईडी. अमेरिका के ऐसे राज्य के उपयोगकर्ताओं के लिए जहां निजता से जुड़ी पाबंदियां लागू नहीं हैं, यह जानकारी हमेशा Google के मैच टैग में दी जाएगी.
google_cver कुकी का वर्शन. यह हमेशा Google के मैच टैग में बताया जाएगा.
google_push इससे पता चलता है कि यह अनुरोध, पिक्सल मैचिंग वर्कफ़्लो शुरू कर रहा है. यह वैल्यू, बिडर के रीडायरेक्ट रिस्पॉन्स में मौजूद पैरामीटर के ज़रिए वापस मिलनी चाहिए.
gdpr_consent टीसी स्ट्रिंग, जो असली उपयोगकर्ता की सहमति को दिखाती है. ज़्यादा जानकारी के लिए, [ईयू में रहने वाले उपयोगकर्ताओं की सहमति लेने से जुड़ी ज़रूरी शर्तें](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) देखें. इसके अलावा, [Authorized Buyers के लिए IAB TCF v2.0 के दस्तावेज़](//support.google.com/authorizedbuyers/answer/9789378) में **टीसी स्ट्रिंग कैसे पास की जाएगी?** सेक्शन देखें.

बिडर के पिक्सल मैचिंग के रीडायरेक्ट पैरामीटर

पैरामीटर ब्यौरा
google_nid बिडर खाते के लिए नेटवर्क आईडी (एनआईडी). इस आईडी को Bidders रिसॉर्स के ज़रिए वापस पाया जा सकता है.
google_push इससे पता चलता है कि यह रीडायरेक्ट, पिक्सल मैचिंग के वर्कफ़्लो को पूरा कर रहा है. यहां, Google मैच टैग से मिली वैल्यू डालनी होगी.
google_hm

इसमें वह डेटा होता है जिसे बिडर, Google के होस्ट किए गए मैच टेबल में सेव करना चाहता है.
google_ula इस स्ट्रिंग का इस्तेमाल, उपयोगकर्ता को मौजूदा उपयोगकर्ता सूची में जोड़ने के लिए किया जाता है. वैल्यू का अनुमानित फ़ॉर्मैट userlistid[,timestamp] है:
  • userlistid: उपयोगकर्ता सूची का एक संख्यात्मक आईडी.
  • timestamp: POSIX फ़ॉर्मैट में एक वैकल्पिक टाइमस्टैंप. इससे पता चलता है कि उपयोगकर्ता को उपयोगकर्ता सूची में कब जोड़ा गया था.

उपयोगकर्ता को एक से ज़्यादा सूचियों में जोड़ने के लिए, इस यूआरएल पैरामीटर को दोहराया जा सकता है.
gdpr_consent टीसी स्ट्रिंग, जो असली उपयोगकर्ता की सहमति को दिखाती है. ज़्यादा जानकारी के लिए, [ईयू में रहने वाले उपयोगकर्ताओं की सहमति लेने से जुड़ी ज़रूरी शर्तें](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) देखें. इसके अलावा, [Authorized Buyers के लिए IAB TCF v2.0 के दस्तावेज़](//support.google.com/authorizedbuyers/answer/9789378) में **टीसी स्ट्रिंग कैसे पास की जाएगी?** लेख पढ़ें.

Google की ओर से शुरू किया गया: एकतरफ़ा पिक्सल मैचिंग

एकतरफ़ा पिक्सल मैचिंग, दोनों तरफ़ा वर्कफ़्लो से इस तरह अलग है कि Google के मैच टैग में, Google उपयोगकर्ता आईडी की जानकारी देने वाला पैरामीटर शामिल नहीं होता. हालांकि, यह Google के होस्ट किए गए मैच टेबल को पॉप्युलेट करता रहेगा. इसका इस्तेमाल उन मामलों में किया जा सकता है जहां बिडर को अपनी मैच टेबल में Google यूज़र आईडी होस्ट करने की अनुमति नहीं है. बदले गए वर्कफ़्लो का एक उदाहरण यहां दिया गया है.

पहला चरण: Google, मैच टैग सेट करता है

Google, एल्गोरिदम के हिसाब से चुने गए बिडर के लिए मैच टैग सेट करता है. मैच टैग में google_push पैरामीटर शामिल होता है. यहां एक उदाहरण दिया गया है:

<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />

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

उपयोगकर्ता का ब्राउज़र, बिडर के कुकी मैचिंग यूआरएल से पिक्सल का अनुरोध करता है. इसमें एचटीटीपी हेडर में बिडर की कुकी शामिल होती है.

बिडर के कुकी मैचिंग एंडपॉइंट को Google की कुकी मैचिंग सेवा पर रीडायरेक्ट करना होगा. इसमें google_hm पैरामीटर भी शामिल है, जिसमें वेब-सुरक्षित base64-encoded कुकी डेटा भरा गया है. रीडायरेक्ट यूआरएल कुछ ऐसा दिख सकता है:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA

Google को एक रीडायरेक्ट मिलेगा. इसमें आपके तय किए गए पैरामीटर शामिल होंगे. साथ ही, एचटीटीपी हेडर में Google की कुकी भी शामिल होगी. अगर ऑपरेशन पूरा हो जाता है, तो बिड के बाद के अनुरोधों में इस उपयोगकर्ता के लिए इंप्रेशन में, बिडर के होस्ट किए गए मैच डेटा को BidRequest.user.buyeruid में शामिल किया जाएगा. बिडर, होस्ट किए गए मैच डेटा का इस्तेमाल करके उपयोगकर्ता सूचियाँ भी भर सकते हैं.

आखिर में, Google उपयोगकर्ता के ब्राउज़र को 1x1 ट्रांसपैरंट पिक्सल (इमेज) भेजता है.

ओपन बिडिंग की मदद से, एक्सचेंज बिडर की ओर से शुरू की गई और Google की ओर से शुरू की गई कुकी मैचिंग वर्कफ़्लो का इस्तेमाल कर सकते हैं. इससे वे Google के यूज़र आईडी को अपनी कुकी से मैच कर पाते हैं. कुकी मैच असिस्ट (सीएमए), एक्सचेंज के लिए एक अतिरिक्त सुविधा है. इससे एक्सचेंज, अपने बिडर के साथ मैच टेबल बना सकते हैं.

  1. विज्ञापन दिखाते समय, Google का एल्गोरिदम विज्ञापन दिखाने के लिए उपलब्ध एक्सचेंज में से किसी एक को चुनता है. इसके बाद, वह कुकी मैच असिस्ट टैग को इस तरह से सेट करता है:

    <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>

  2. Google का सीएमए मैच टैग, एक्सचेंज के कुकी मैचिंग यूआरएल को पिक्सल अनुरोध भेजता है.

  3. एक्सचेंज का कुकी मैचिंग एंडपॉइंट, अनुरोध को स्वीकार करता है. यहां कुकी मैचिंग की एक्सचेंज की अपनी सेवा, यूज़र आईडी को उसके किसी एक बिडर से मैच करने के लिए ज़िम्मेदार होती है. नीचे दिए गए डायग्राम में, एक्सचेंज की कुकी मैचिंग सेवा, उपयोगकर्ता के ब्राउज़र को जवाब देती है. इसमें, बिडर के किसी एक एंडपॉइंट पर रीडायरेक्ट करने की जानकारी होती है.
  4. बिडर को अनुरोध मिलता है. साथ ही, एक्सचेंज की ओर से तय किए गए ऐसे पैरामीटर भी मिलते हैं जिनसे उपयोगकर्ता के आईडी को उसकी कुकी से मैच किया जा सकता है.

पाबंदियां

नए मैच के अनुरोधों की फ़्रीक्वेंसी को सीमित करना

बिडर की यह ज़िम्मेदारी है कि वे कुकी मैचिंग सेवा के लिए कॉल की संख्या को सीमित करें. ऐसा उन उपयोगकर्ताओं के लिए किया जाना चाहिए जिनकी Google पर होस्ट की गई मैच टेबल में नई एंट्री है. होस्ट किए गए मैच की टेबल में मौजूद एंट्री को 14 दिनों के बाद, खत्म माना जा सकता है. इसके बाद, इसे रीफ़्रेश किया जा सकता है.

पिक्सेल मैच के सभी अनुरोधों का जवाब देना

Pixel Matching वर्कफ़्लो का इस्तेमाल करने वाले बिडर से उम्मीद की जाती है कि वे Pixel Match के सभी अनुरोधों का जवाब दें. साथ ही, जवाब में google_push पैरामीटर शामिल करें. इससे Google को, इस्तेमाल पर नज़र रखकर नीतियां लागू करने में मदद मिलती है. अगर बिडर के जवाब देने की दर 90% से कम है, तो Google उसके खाते को भेजे जाने वाले पिक्सल मैच के अनुरोधों की संख्या को कम कर देगा.

एचटीटीपीएस एंडपॉइंट का इस्तेमाल करना

यह ज़रूरी है कि कुकी मैचिंग के सभी वर्कफ़्लो में इस्तेमाल किए गए एंडपॉइंट, HTTPS का इस्तेमाल करें.

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

कुकी मैचिंग के ऐसे अनुरोधों में असली उपयोगकर्ता की सहमति के बारे में जानकारी होनी चाहिए जिन पर Google की ईयू उपयोगकर्ता की सहमति से जुड़ी नीति लागू होती है. इस तरह के अनुरोधों में यह जानकारी देना ज़रूरी है कि सहमति इनमें से किसी एक तरीके से ली गई है:

उदाहरण

यहां दिए गए उदाहरणों में, कुकी मैचिंग सेवा का इस्तेमाल करके, कुछ खास लक्ष्यों को पूरा करने का तरीका बताया गया है. ध्यान दें कि जब तक किसी उपयोगकर्ता के बारे में यह न बताया गया हो कि वह अमेरिका के किसी ऐसे राज्य से है जहां निजता से जुड़ी पाबंदियां लागू हैं, तब तक यह माना जाता है कि वह उपयोगकर्ता ऐसे किसी राज्य से नहीं है.

बिडर के होस्ट की गई मैच टेबल में डेटा भरना

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

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />

अगर बिडर के कुकी मैचिंग यूआरएल को https://ad.network.com/pixel?id=1 पर सेट किया गया है और कुकी मैचिंग की प्रोसेस पूरी हो जाती है, तो बिडर के मैच टैग के जवाब में Google जो रीडायरेक्ट भेजता है वह इस तरह दिख सकता है:

https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

अगर उपयोगकर्ता के पास Google कुकी नहीं है, तो कुकी मैच करने की कार्रवाई पूरी नहीं होगी. ऐसे में, जवाब यह होगा:

https://ad.network.com/pixel?id=1&google_error=3

गड़बड़ी का कोड, गड़बड़ी की वजह पर निर्भर करता है. कुकी मैचिंग के वर्कफ़्लो के लिए, संभावित गड़बड़ी कोड के बारे में ज़्यादा जानने के लिए, रीडायरेक्ट यूआरएल पैरामीटर देखें.

किसी एक उपयोगकर्ता की सूची में जोड़ना

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

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />

सफल जवाब के लिए, जहां बिडर का कुकी मैचिंग यूआरएल https://ad.network.com/pixel है, Google का रीडायरेक्ट यूआरएल यह होगा:

https://ad.network.com/pixel?google_ula=12345,0

अगर कोई सामान्य गड़बड़ी होती है— उदाहरण के लिए, उपयोगकर्ता के लिए कोई Google कुकी मौजूद नहीं है— तो रीडायरेक्ट यूआरएल में google_error पैरामीटर शामिल होगा:

  • https://ad.network.com/pixel?google_error=3

अगर उपयोगकर्ता को सूची में जोड़ने से जुड़ी कोई गड़बड़ी होती है, तो आपको रीडायरेक्ट में google_ula दिखेगा. मैच टैग पैरामीटर के उलट, यह टाइमस्टैंप को स्टेटस कोड से बदलता है, ताकि ऑपरेशन के पूरा होने की जानकारी दी जा सके. उदाहरण के लिए, अगर अनुरोध इसलिए पूरा नहीं किया जा सका, क्योंकि बिडर खाते के पास बताई गई उपयोगकर्ता सूची का ऐक्सेस नहीं था, तो रीडायरेक्ट यूआरएल यह होगा:

https://ad.network.com/pixel?google_ula=12345,2

एक से ज़्यादा उपयोगकर्ता सूचियों में जोड़ना

बिडर यह तय कर सकते हैं कि किसी उपयोगकर्ता को एक से ज़्यादा उपयोगकर्ता सूचियों में जोड़ा जाना चाहिए. इसके लिए, उन्हें मैच टैग में एक से ज़्यादा google_ula पैरामीटर शामिल करने होंगे. असल में, यह इस तरह दिख सकता है:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />

हर उपयोगकर्ता सूची के लिए, कार्रवाई की स्थिति की जानकारी इसी तरह से दी जाती है. इसके लिए, रीडायरेक्ट में अलग-अलग google_ula पैरामीटर इस्तेमाल किए जाते हैं:

https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0

ऊपर दिए गए रीडायरेक्ट में, हम देख सकते हैं कि आईडी 45678 वाली उपयोगकर्ता सूची के लिए कार्रवाई पूरी हो गई है. हालांकि, आईडी 12345 वाली उपयोगकर्ता सूची के लिए कार्रवाई पूरी नहीं हुई, क्योंकि बिडर के पास इसे ऐक्सेस करने की अनुमति नहीं थी.

कुकी मैचिंग करने और उपयोगकर्ता को एक ही अनुरोध में उपयोगकर्ता सूची में जोड़ने के लिए, बिडर के मैच टैग में google_cm और google_ula शामिल होना चाहिए:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />

Google की ओर से तय किए गए रीडायरेक्ट यूआरएल में google_gid, google_cver, और google_ula शामिल होंगे. यह कुछ इस तरह दिख सकता है:

https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0

Google पर होस्ट की गई मैच टेबल में मैच सेव करना

अगर कोई बिडर, अपने कुकी डेटा को Google के होस्ट किए गए मैच टेबल में सेव करना चाहता है और Google User ID के साथ मैच को अपनी मैच टेबल में सेव नहीं करना चाहता है, तो उसके मैच टैग में google_hm पैरामीटर शामिल होना चाहिए. इसकी वैल्यू, वेब-सुरक्षित base64-encoded स्ट्रिंग होनी चाहिए. जिस उपयोगकर्ता के लिए बिडर का अनकोड किया गया कुकी डेटा Cookie number 1! है उसके लिए कोड की गई वैल्यू Q29va2llIG51bWJlciAxIQ== होगी. इसका इस्तेमाल, मैच टैग में किया जाएगा. जैसे:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />

अगर बिडर का कुकी मैचिंग यूआरएल https://cookie-monster.com/pixel है, तो Google का रीडायरेक्ट यूआरएल यह होगा:

https://cookie-monster.com/pixel

रीडायरेक्ट में google_gid पैरामीटर मौजूद नहीं है, क्योंकि मैच टैग में google_cm शामिल नहीं था. साथ ही, google_hm को सफल जवाबों में शामिल नहीं किया गया है. इस उपयोगकर्ता के लिए, आने वाले समय में इंप्रेशन के लिए की जाने वाली बिड के अनुरोधों में, बिडर को BidRequest.user.buyeruid में होस्ट किया गया मैच डेटा मिलेगा.

अगर बिडर ने मैच टैग का इस्तेमाल किया है, जिसमें google_hm की वैल्यू को base64 में एन्कोड नहीं किया गया है, तो रीडायरेक्ट यूआरएल ऐसा दिख सकता है:chocolate_chunk!

https://cookie-monster.com/pixel?google_hm=2

रीडायरेक्ट किए गए पिछले यूआरएल में google_hm वैल्यू 2 शामिल है. इससे पता चलता है कि वैल्यू को डिकोड नहीं किया जा सका, इसलिए ऑपरेशन पूरा नहीं हुआ.

उपयोगकर्ता सूचियों के साथ बिडर और Google-होस्ट की गई मैच टेबल

अगर कोई बिडर, Google के होस्ट किए गए उपयोगकर्ता की सूची के अलावा, अपनी सूची भी होस्ट करता है और उसे दोनों टेबल से मैच करने के लिए एक ही मैच टैग चाहिए, तो उसे उपयोगकर्ता को दी गई उपयोगकर्ता सूची में जोड़ना होगा. इसके लिए, उसके मैच टैग में google_cm, google_hm, और google_ula पैरामीटर शामिल होने चाहिए. अगर बिडर के कुकी का डेटा Cookie number 1! है, तो एन्कोड की गई वैल्यू Q29va2llIG51bWJlciAxIQ== होगी. इससे मैच टैग इस तरह का होगा:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />

अगर बिडर का कुकी मैचिंग यूआरएल https://cookie-monster.com/pixel है, तो Google का रीडायरेक्ट यूआरएल इस तरह दिखेगा:

https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0

रीडाइरेक्ट मिलने पर, बिडर google_gid में दिए गए Google User ID को अपनी मैच टेबल में मौजूद कुकी डेटा से मैच कर सकता है. इसके अलावा, वे यह भी पता लगा सकते हैं कि Google पर होस्ट की गई मैच टेबल और उपयोगकर्ता सूची के ऑपरेशन पूरे हो गए हैं. इस वजह से, बिडर ने उपयोगकर्ता की सूची के जिस आईडी को टारगेट करने के लिए प्रीटारगेटिंग कॉन्फ़िगर की है उसे अब उपयोगकर्ता से इंप्रेशन के लिए बिड अनुरोध मिलेंगे. इसी तरह, बिडिंग के इन अनुरोधों में बिडर को होस्ट किया गया मैच डेटा, BidRequest.user.buyeruid में मिलेगा.