कुकी मैचिंग

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

कॉन्सेप्ट

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

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

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

मैच टेबल

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

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

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

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

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

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

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

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

बिडर को कुकी से मैच करने वाले यूआरएल पर रीडायरेक्ट किया जाता है. इसमें, पहले चरण में बताए गए पैरामीटर और दूसरे चरण में Google के दिए गए पैरामीटर शामिल होते हैं. इसके अलावा, उन्हें एचटीटीपी हेडर में भी अपनी कुकी मिलेगी. अगर ऑपरेशन पूरा हो गया है, तो अपनी मैच टेबल होस्ट करने वाला बिडर, अपनी कुकी को जवाब में शामिल 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 को खोजता है और जेन से जुड़ी वह कुकी ढूंढता है जो एक हफ़्ते पहले बनाई गई थी (स्थिति 1 में).
  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 की ओर से डाला गया पिक्सल मैचिंग टैग, बिडर के कुकी मैचिंग यूआरएल को अन्य पैरामीटर के साथ जोड़ता है. बिडर इन पैरामीटर का इस्तेमाल अपनी मैच टेबल को पॉप्युलेट करने के लिए कर सकता है. 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 टीसीएफ़ के 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 टीसीएफ़ के 2.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 दिनों के बाद खत्म हो सकती है. इसके बाद, उसे रीफ़्रेश किया जा सकता है.

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

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

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

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

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