पहले से टारगेट किए गए कॉन्फ़िगरेशन

बिडिंग करने वाले लोग, pretargetingConfigs संसाधन का इस्तेमाल सिर्फ़ ऐसे इंप्रेशन के लिए बिड रिक्वेस्ट पाने के लिए कर सकते हैं जो उनके टारगेटिंग (विज्ञापन के लिए सही दर्शक चुनना) की शर्तों से मेल खाते हों.एक बार में आपके पास पहले से टारगेट करने के ज़्यादा से ज़्यादा 10 कॉन्फ़िगरेशन हो सकते हैं.

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

सबसे सही तरीके

बोली अनुरोध प्राप्त करने के लिए, आपको कम से कम एक प्री-टारगेटिंग कॉन्फ़िगरेशन बनाना होगा. प्री-टारगेटिंग कॉन्फ़िगरेशन को मैनेज करने के लिए यहां कुछ सलाह दी गई है:

स्कोप

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

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

लॉजिक

टॉप लेवल के टारगेटिंग फ़ील्ड में मौजूद वैल्यू, लॉजिकल OR की मदद से प्रोसेस की जाती हैं. इसका मतलब है कि आपको ऐसे बिड रिक्वेस्ट मिल सकते हैं जिनमें टॉप-लेवल वाले फ़ील्ड में कम से कम एक वैल्यू दी गई हो. उदाहरण के लिए, अगर आपके प्री-टारगेटिंग कॉन्फ़िगरेशन में languageCodes वैल्यू en, de, और sv हैं, तो आपको बिडिंग के अनुरोध मिल सकते हैं. इनमें en, de या sv को शामिल की गई भाषा के तौर पर चुना जा सकता है.

अलग-अलग फ़ील्ड को लॉजिकल AND का इस्तेमाल करके प्रोसेस किया जाता है. आपको सिर्फ़ ऐसे बिड रिक्वेस्ट मिलते हैं जो आपके सेट किए गए हर प्री-टारगेटिंग फ़ील्ड के कम से कम एक वैल्यू से मैच होते हों. उदाहरण के लिए, अगर आपके कॉन्फ़िगरेशन में languageCodes वैल्यू en, de, sv और includedPlatforms की वैल्यू PERSONAL_COMPUTER है, तो आपको सिर्फ़ ऐसे बिड रिक्वेस्ट मिलेंगे जिनकी भाषा en, de या sv हो और डिवाइस टाइप PERSONAL_COMPUTER हो.

प्री-टारगेटिंग फ़ील्ड में लॉजिकल AND होने की वजह से, विरोधाभासी शर्तें शामिल नहीं की जा सकतीं. उदाहरण के लिए, NumericTargetingDimensions मानदंड में includedIds और excludedIds में एक ही वैल्यू शामिल करने से गड़बड़ी होती है.

ओवरलैप

बिड रिक्वेस्ट कई प्री-टारगेटिंग कॉन्फ़िगरेशन के लिए स्वीकार किए जा सकते हैं.

अलग-अलग तरह की इन्वेंट्री को टारगेट करने के लिए, ज़्यादा से ज़्यादा 10 प्री-टारगेटिंग कॉन्फ़िगरेशन बनाए जा सकते हैं. पहले से टारगेट करने के कॉन्फ़िगरेशन ओवरलैप हो सकते हैं, इसलिए एक ही बिड के अनुरोध को कई प्री-टारगेटिंग कॉन्फ़िगरेशन के लिए मंज़ूरी मिल सकती है. इस मामले में, बिड अनुरोध के billing_id फ़ील्ड में हर लागू कॉन्फ़िगरेशन का billingId शामिल होता है. अगर बिड रिक्वेस्ट में एक से ज़्यादा बिलिंग आईडी मिलते हैं, तो आपको बिड रिस्पॉन्स के billing_id फ़ील्ड में यह बताना होगा कि किस बिलिंग आईडी पर बिडिंग की जा रही है.

भौगोलिक आईडी

कुछ भौगोलिक आईडी, नीति के उल्लंघन की वजह से टारगेट नहीं किए जा सकते. उदाहरण के लिए, कम आबादी वाले कुछ इलाकों को टारगेट नहीं किया जा सकता, क्योंकि इससे हमारी निजता नीति का उल्लंघन हो सकता है. हमारी नीतियां बदल सकती हैं. अगर आपने प्री-टारगेटिंग कॉन्फ़िगरेशन के geoTargeting में किसी ऐसे भौगोलिक आईडी की जानकारी दी है जो बाद की तारीख में अमान्य हो जाती है, तो वह आईडी उस समय invalidGeoIds फ़ील्ड में दिखता है. invalidGeoIds से कम वाले भौगोलिक आईडी से, टारगेटिंग (विज्ञापन के लिए सही दर्शक चुनना) पर कोई असर नहीं पड़ता. अगर invalidGeoIds में कोई जी-ग्राफ़िक आईडी मान्य हो जाता है, तो उसे आपके प्री-टारगेटिंग कॉन्फ़िगरेशन के geoTargeting फ़ील्ड में जोड़ दिया जाता है.

geo-table.csv फ़ाइल में टारगेट किए जा सकने वाले भौगोलिक आईडी की सूची होती है. साथ ही, आईडी को जोड़ने और हटाने पर, इसे समय-समय पर अपडेट किया जाता है.

बिड रिक्वेस्ट की संख्या

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

यहां ऐसे मामलों के बारे में बताया गया है जिनमें maximumQps के साथ, पहले से टारगेट करने के कॉन्फ़िगरेशन लेवल पर ज़्यादा से ज़्यादा क्यूपीएस को मैनेज करना फ़ायदेमंद हो सकता है:

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

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