कुकी मैचिंग

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

कॉन्सेप्ट

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

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

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

टेबल मैच करें

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

Google की ओर से होस्ट की जाने वाली मैच टेबल

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

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

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

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

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

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

शुरू करें

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

  • कुकी मैचिंग नेटवर्क आईडी (एनआईडी): यह एक स्ट्रिंग आईडी है, जो कुकी मैचिंग और इससे जुड़े अन्य ऑपरेशन के लिए, बिडर खाते की यूनीक पहचान करता है.
  • कुकी मैचिंग यूआरएल: किसी एंडपॉइंट का बेस यूआरएल, जो कुकी मैचिंग वर्कफ़्लो के हिस्से के तौर पर, आने वाले अनुरोधों को स्वीकार और मैनेज करेगा. बिडिंग करने वाले इस यूआरएल में मैक्रो जोड़ सकते हैं, ताकि वे कुकी मैचिंग वर्कफ़्लो में, यूआरएल में पास किए गए पैरामीटर के क्रम को कंट्रोल कर सकें.
  • मैच टैग: बिड लगाने वाले व्यक्ति या कंपनी की ओर से शुरू किए गए कुकी मैचिंग वर्कफ़्लो के लिए, आपको उपयोगकर्ता के ब्राउज़र में यह टैग डालना होगा. इसे विज्ञापनों के साथ दिखाया जा सकता है या विज्ञापनों के बाहर की वेब प्रॉपर्टी पर दिखाया जा सकता है.
  • कुकी मैचिंग रिपोर्ट का यूआरएल (ज़रूरी नहीं): एकतरफा कुकी मैचिंग वर्कफ़्लो में, यह एक वैकल्पिक यूआरएल है. इसे एंडपॉइंट की जानकारी देने के लिए दिया जा सकता है. एंडपॉइंट को एचटीटीपी 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 पर होस्ट किए गए एंडपॉइंट के साथ कुकी मैचिंग इंटिग्रेशन है. इसे लागू करने के लिए, बिडर के तय किए गए पहले से सेट पैरामीटर के साथ-साथ, पिक्सल मैचिंग पैरामीटर की ज़रूरत होती है. इन पैरामीटर को इस क्रम में सेट करना होगा: 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 User-ID और उसके वर्शन नंबर की जानकारी देने वाले क्वेरी पैरामीटर शामिल होंगे. साथ ही, बिड करने वाले को अनुरोध के हेडर में मौजूद कुकी भी मिलेगी. आम तौर पर, https://ad.network.com/pixel के तौर पर तय किए गए कुकी मैचिंग यूआरएल के लिए, ऊपर दिए गए सिंपल मैच टैग का रीडायरेक्ट यूआरएल कुछ ऐसा दिख सकता है:

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

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

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

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

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

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

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

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

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

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

पैरामीटर ब्यौरा
google_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 टीसीएफ़ के 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: दोनों तरफ़ Pixel मैचिंग अनुरोध के हिस्से के तौर पर, Google सर्वर पर रीडायरेक्ट करते समय, अमान्य google_push पैरामीटर पास किया गया था. आपके रीडायरेक्ट को google_push को वही वैल्यू सेट करनी होगी जो पिक्सल के शुरुआती अनुरोध में आपको दी गई थी.
  • 6: मैच टैग में अमान्य एनआईडी दिया गया था.
  • 7: एक अमान्य कुकी का पता चला.
  • 8: अब काम नहीं करता. कोई कुकी नहीं मिली.
  • 9: कोई कुकी नहीं मिली. टेस्ट कुकी सेट करने की कोशिश की गई.
  • 10: google_redir पैरामीटर का इस्तेमाल, google_hm की जानकारी दिए बिना किया गया था या google_cm के साथ किया गया था.
  • 15: अनुरोध किसी ऐसे इलाके से आया है जहां 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_gid और google_cver पैरामीटर सेट के साथ, FinestDSP के कुकी मैचिंग यूआरएल पर रीडायरेक्ट करती है.
  8. जेन का ब्राउज़र, FinestDSP के कुकी मैच यूआरएल पर रीडायरेक्ट करता है.
  9. FinestDSP का कुकी मैचिंग एंडपॉइंट, रीडायरेक्ट अनुरोध को प्रोसेस करता है. इसमें, Google सेट किए गए यूआरएल पैरामीटर और एचटीटीपी हेडर में, जेन के लिए उनकी कुकी शामिल होती है. 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 को खोजता है और जेन से जुड़ी उस कुकी का पता लगाता है जो एक हफ़्ते पहले बनाई गई थी (पहली स्थिति में).
  5. कुकी से जुड़ी जानकारी के आधार पर, FinestDSP का बिडिंग लॉजिक, इंप्रेशन पर बिडिंग करता है और नीलामी जीतता है.
  6. जेन को अपनी दिलचस्पी के मुताबिक विज्ञापन दिख सकता है. यह विज्ञापन, FinestDSP के पास मौजूद जानकारी के आधार पर दिखाया जाएगा.

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

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

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

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

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

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

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

पैरामीटर ब्यौरा
google_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 टीसीएफ़ के 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: दोनों तरफ़ Pixel मैचिंग अनुरोध के हिस्से के तौर पर, Google सर्वर पर रीडायरेक्ट करते समय, अमान्य google_push पैरामीटर पास किया गया था. आपके रीडायरेक्ट को google_push को उसी वैल्यू पर सेट करना चाहिए जो आपको शुरुआती पिक्सल अनुरोध में दी गई थी.
  • 6: मैच टैग में अमान्य एनआईडी दिया गया था.
  • 7: एक अमान्य कुकी का पता चला.
  • 8: अब काम नहीं करता. कोई कुकी नहीं मिली.
  • 9: कोई कुकी नहीं मिली. टेस्ट कुकी सेट करने की कोशिश की गई.
  • 10: google_redir पैरामीटर का इस्तेमाल, google_hm की जानकारी दिए बिना किया गया था या google_cm के साथ किया गया था.
  • 15: अनुरोध किसी ऐसे इलाके से आया है जहां Google के लिए, मैच टेबल को होस्ट करना ज़रूरी है. इसलिए, इस रिस्पॉन्स में Google उपयोगकर्ता आईडी शामिल नहीं है. फ़िलहाल, यह सुविधा सिर्फ़ कुछ ट्रैफ़िक के लिए चालू है. हालांकि, जून 2020 में इसे पूरी तरह से चालू कर दिया जाएगा.

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

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

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

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

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

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

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

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

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

पैरामीटर ब्यौरा
google_nid बिडर खाते के लिए नेटवर्क आईडी (एनआईडी). इस आईडी को बिडर रिसॉर्स से हासिल किया जा सकता है.
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 टीसीएफ़ 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" />

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

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

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

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

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

  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 के अनुरोधों की संख्या को कम कर देगा.

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

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

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

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