कुकी मैचिंग

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

कॉन्सेप्ट

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

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

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

टेबल मैच करें

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

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

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

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

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

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

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

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

YouTube पर शुरुआत करना

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

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

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

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

बिडिंग करने वाले लोग विकल्प के तौर पर अपने कुकी मैचिंग यूआरएल को कॉन्फ़िगर कर सकते हैं, ताकि वे %%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 पर होस्ट किए गए एंडपॉइंट के साथ कुकी मैचिंग इंटिग्रेशन होता है. इसे लागू करने के लिए, बिड करने वाले के तय किए गए पैरामीटर के साथ-साथ Pixel मैचिंग पैरामीटर को इस क्रम में लागू करना ज़रूरी होता है: 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 User ID दिखाता है, उसे इस तरह से बनाया जा सकता है:

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

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

दूसरा चरण: Google, रीडायरेक्ट के साथ जवाब देता है. इसमें, मिलते-जुलते वीडियो से जुड़ा डेटा भी शामिल होता है

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

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

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

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

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

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

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

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

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

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

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

पैरामीटर ब्यौरा
google_nid बिड करने वाले के खाते का नेटवर्क आईडी (NID). यह आईडी, बिड करने वाले संसाधन की मदद से फिर से हासिल किया जा सकता है.
google_cm Google की कुकी मैचिंग सेवा को यह बताता है कि इसे कुकी मैचिंग की प्रोसेस पूरी करनी चाहिए. पैरामीटर की वैल्यू को नज़रअंदाज़ कर दिया जाता है और ऐसा किया जा सकता है.
google_sc यह पैरामीटर अब काम नहीं करता. अगर कोई उपयोगकर्ता मौजूद नहीं है, तो उपयोगकर्ता के लिए Google की कुकी सेट करता है. पैरामीटर की वैल्यू को नज़रअंदाज़ कर दिया जाता है और ऐसा किया जा सकता है. अगर कोई कुकी मौजूद नहीं है, तो पैरामीटर को हटाने से गड़बड़ी होगी.
google_no_sc यह पैरामीटर अब काम नहीं करता. इससे Google की कुकी मैचिंग सेवा को पता चलता है कि अगर कोई कुकी मौजूद नहीं है, तो उसे उपयोगकर्ता के लिए कुकी सेट नहीं करनी चाहिए. पैरामीटर की वैल्यू को नज़रअंदाज़ कर दिया जाता है और ऐसा किया जा सकता है.
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 टीसीएफ़ वर्शन 2.0 से जुड़े दस्तावेज़ में, ईयू उपयोगकर्ता की सहमति से जुड़ी ज़रूरी शर्तें देखें या कुकी मैच ज़रूरी शर्तों पर

उदाहरण: gdpr=1
gdpr_consent एक टीसी स्ट्रिंग, जो असली उपयोगकर्ता की सहमति के बारे में बताती है. ज़्यादा जानकारी के लिए, नीचे ईयू उपयोगकर्ता की सहमति से जुड़ी ज़रूरी शर्तें देखें या Authorized Buyers IAB टीसीएफ़ v2.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 यूज़र आईडी शामिल नहीं होता है. फ़िलहाल, यह सुविधा कुछ ही ट्रैफ़िक के लिए चालू है. हालांकि, जून 2020 में इसे पूरी तरह से चालू कर दिया जाएगा.
google_hm

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

  • 1 - अनुमति नहीं है: ग्राहक को अब तक होस्ट की गई मैच टेबल की एंट्री लिखने के लिए अनुमति नहीं मिली है.
  • 2 - डिकोड करने में गड़बड़ी: पैरामीटर वैल्यू को डिकोड नहीं किया जा सका.
  • 3 - पेलोड बहुत बड़ा है: पैरामीटर वैल्यू को डिकोड किया गया है. इसे 24 बाइट से ज़्यादा डेटा में बांटा गया है.
  • 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, FinestDSP का विज्ञापन दिखाता है और टैग जेन को देता है.
  6. मैच टैग, Google की कुकी मैच सेवा को कॉल करता है. इससे, google_nid और google_cm पैरामीटर के बारे में जानकारी मिलती है.
  7. कुकी मैच सेवा, जेन की Google कुकी को पढ़ती है. साथ ही, जेन के ब्राउज़र को google_user_id और google_cver पैरामीटर सेट का इस्तेमाल करके, FinestDSP के कुकी मैचिंग यूआरएल पर रीडायरेक्ट भेजती है.
  8. जेन का ब्राउज़र, FinestDSP के कुकी मैच यूआरएल पर रीडायरेक्ट को लोड करता है.
  9. FinestDSP का कुकी मैचिंग एंडपॉइंट, रीडायरेक्ट के अनुरोध को प्रोसेस करता है. इनमें Google के सेट किए गए यूआरएल पैरामीटर और एचटीटीपी हेडर में जेन के लिए उनकी कुकी शामिल होती हैं. FinestDSP अब अपनी मैच टेबल में मौजूद google_user_id में अपनी कुकी की मैपिंग को स्टोर कर सकता है.
  10. FinestDSP, न दिखने वाले 1x1 पिक्सल के ज़रिए रीडायरेक्ट पर जवाब देती है.
दूसरी स्थिति: मौजूदा मैपिंग वाला उपयोगकर्ता

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

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

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

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

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

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

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

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

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

चौथा चरण: रिपोर्ट के यूआरएल की जानकारी देने पर Google, 'सफलता या गड़बड़ी' रीडायरेक्ट करने पर पिक्सल दिखाता है

अगर कुकी मैचिंग की कार्रवाई पूरी होती है—या बिड करने वाले के खाते के लिए, कुकी मैचिंग रिपोर्ट का कोई यूआरएल नहीं दिया गया है, तो Google डिफ़ॉल्ट रूप से 1x1 पारदर्शी पिक्सल दिखाएगा और वर्कफ़्लो यहां खत्म हो जाएगा. बाद के बोली अनुरोधों में, इस उपयोगकर्ता के इंप्रेशन में, Google प्रोटोकॉल के लिए BidRequest.hosted_match_data में बोली लगाने वाले का होस्ट किया गया मैच डेटा शामिल होगा. इसके अलावा, Google के OpenRTB को लागू करने के लिए, 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 बिड करने वाले के खाते का नेटवर्क आईडी (NID). यह आईडी, बिड करने वाले संसाधन की मदद से फिर से हासिल किया जा सकता है.
google_sc यह पैरामीटर अब काम नहीं करता. अगर कोई उपयोगकर्ता मौजूद नहीं है, तो उपयोगकर्ता के लिए Google की कुकी सेट करता है. पैरामीटर की वैल्यू को नज़रअंदाज़ कर दिया जाता है और ऐसा किया जा सकता है. अगर कोई कुकी मौजूद नहीं है, तो पैरामीटर को हटाने से गड़बड़ी होगी.
google_no_sc यह पैरामीटर अब काम नहीं करता. इससे Google की कुकी मैचिंग सेवा को पता चलता है कि अगर कोई कुकी मौजूद नहीं है, तो उसे उपयोगकर्ता के लिए कुकी सेट नहीं करनी चाहिए. पैरामीटर की वैल्यू को नज़रअंदाज़ कर दिया जाता है और ऐसा किया जा सकता है.
google_hm

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

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

उदाहरण: gdpr=1
gdpr_consent एक टीसी स्ट्रिंग, जो असली उपयोगकर्ता की सहमति के बारे में बताती है. ज़्यादा जानकारी के लिए, नीचे ईयू उपयोगकर्ता की सहमति से जुड़ी ज़रूरी शर्तें देखें या Authorized Buyers IAB टीसीएफ़ v2.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 यूज़र आईडी शामिल नहीं होता है. फ़िलहाल, यह सुविधा कुछ ही ट्रैफ़िक के लिए चालू है. हालांकि, जून 2020 में इसे पूरी तरह से चालू कर दिया जाएगा.

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

दो-तरफ़ा Pixel मैचिंग, 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

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

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

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

Pixel मैचिंग के वर्कफ़्लो का डायग्राम

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

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

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

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

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

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

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

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

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

पहला चरण: Google, मिलता-जुलता टैग डालता है

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

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

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

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

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

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

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

आखिर में, Google उपयोगकर्ता के ब्राउज़र को 1x1 पारदर्शी पिक्सल दिखाता है.

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

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

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

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

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

ज़रूरी शर्तें

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

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

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

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

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

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

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

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

  • टीसीएफ़ के 2 वर्शन: इसमें gdpr और gdpr_consent पैरामीटर शामिल हैं. ज़्यादा जानकारी के लिए, Authorized Buyers IAB टीसीएफ़ के 2.0 वर्शन का दस्तावेज़ देखें.
  • process_consent: इस बात का एलान करना कि बिड करने वाले ने उपयोगकर्ता की ज़रूरी सहमति ले ली है.

उदाहरण

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

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

बिडिंग करने वाला कोई भी व्यक्ति, कुकी मैचिंग वर्कफ़्लो का इस्तेमाल करके, मैच टेबल में जानकारी अपने-आप भर सकता है. इसके लिए, वह अपने मैच टैग में सिर्फ़ 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 पैरामीटर शामिल होना चाहिए. ऐसे उपयोगकर्ता के लिए जहां बिड करने वाले का कोड में बदला गया कुकी डेटा 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 को सफल रिस्पॉन्स में शामिल नहीं किया गया है. आने वाले समय में, इस उपयोगकर्ता के लिए इंप्रेशन के लिए बिड करने के अनुरोधों में, बिडिंग करने वाले को होस्ट किया गया मैच डेटा, Google के आरटीबी प्रोटोकॉल के लिए BidRequest.hosted_match_data में या Google के OpenRTB को लागू करने के लिए BidRequest.user.buyeruid मिलेगा.

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

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

ऊपर दिए गए दूसरे वेबलिंक में 2 की google_hm वैल्यू शामिल है. इससे पता चलता है कि वैल्यू को डिकोड नहीं किया जा सका था, इसलिए कार्रवाई नहीं हुई.

उपयोगकर्ता सूचियों के साथ, बिड करने वाले और 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 की होस्ट की गई मैच टेबल और उपयोगकर्ता सूची ऑपरेशन सफल रहे. इस वजह से, किसी उपयोगकर्ता सूची आईडी को टारगेट करने के लिए कॉन्फ़िगर किए गए, बिड करने वाले को पहले से टारगेट करने पर, अब बिडिंग करने वाले को उपयोगकर्ता से इंप्रेशन के लिए बिड अनुरोध मिल सकेंगे. इसी तरह, इन बिड के अनुरोधों में, बिडिंग करने वाले को Google के आरटीबी प्रोटोकॉल के लिए BidRequest.hosted_match_data में या Google के OpenRTB को लागू करने के लिए BidRequest.user.buyeruid में होस्ट किया गया मैच डेटा मिलेगा.