कुकी मैचिंग

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

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

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

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

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

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

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

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

पाबंदियां

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

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

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

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