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

Data Manager API का इस्तेमाल करते समय, इन सबसे सही तरीकों को ध्यान में रखें.

सभी यूज़र आइडेंटिफ़ायर भेजें

UserData की मदद से ऑडियंस सेगमेंट के सदस्यों या इवेंट का डेटा भेजते समय, ज़्यादा से ज़्यादा user_identifiers शामिल करें. इसमें एक ही तरह के कई आइडेंटिफ़ायर भेजना भी शामिल है.

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

अनुरोधों को ऑप्टिमाइज़ करना

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

उदाहरण के लिए, अगर आपको किसी ऑडियंस में 10,000 सदस्यों को जोड़ना है, तो सभी 10,000 सदस्यों को एक ही IngestAudienceMembersRequest में audience_members सूची में जोड़ें. ऑडियंस सेगमेंट के हर सदस्य को जोड़ने के लिए अलग-अलग अनुरोध भेजने के बजाय, एक ही अनुरोध में सभी 10,000 सदस्यों को बैच करना ज़्यादा असरदार होता है.

एक साथ कई अनुरोध भेजना

डेटा डालने में लगने वाले कुल समय को कम करने के लिए, IngestionService को एक साथ कई अनुरोध भेजें. हमारा सुझाव है कि आप एक साथ ज़्यादा से ज़्यादा 10 अनुरोध भेजें. इससे, हर मिनट अनुरोध भेजने की सीमा को पार करने की संभावना कम हो जाती है.

एक साथ कई अनुरोध भेजे जा सकते हैं. भले ही, अनुरोधों में एक ही destinations हो.

क्लाइंट साइड पर डेटा की पुष्टि करना

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

बार-बार दोतरफ़ा यात्रा और अस्वीकार किए गए अनुरोधों से बचने के लिए, डेटा भेजने से पहले उसकी पुष्टि करें और उसे साफ़ करें:

• हैश करने से पहले, खाली वैल्यू हटाएं: SHA-256 हैश की गिनती करने से पहले, email_address और phone_number जैसे फ़ील्ड की जांच करें. इससे यह पता चलेगा कि उनमें कोई खाली स्ट्रिंग या सिर्फ़ व्हाइटस्पेस वाली स्ट्रिंग तो नहीं है. खाली स्ट्रिंग को हैश करने से एक मान्य हैश जनरेट होता है, जो सिंटैक्स की जांच में पास हो जाता है. हालांकि, इससे मैच रेट पर असर पड़ता है.

• अधूरे कंपाउंड ऑब्जेक्ट हटाना: पक्का करें कि कंपाउंड ऑब्जेक्ट को किसी रिकॉर्ड में जोड़ने से पहले, उनमें सभी ज़रूरी फ़ील्ड मौजूद हों. उदाहरण के लिए, अगर किसी AddressInfo ऑब्जेक्ट में उसके चार ज़रूरी फ़ील्ड (given_name, family_name, region_code या postal_code) में से कोई भी फ़ील्ड मौजूद नहीं है, तो REQUIRED_FIELD_MISSING गड़बड़ियों से बचने के लिए, पूरे address आइडेंटिफ़ायर को छोड़ दें.

• एन्कोडिंग और सादे टेक्स्ट वाले फ़ील्ड की पुष्टि करें: पुष्टि करें कि हैश किए गए फ़ील्ड, रॉ सादे टेक्स्ट को भेजने के बजाय, एलान किए गए encoding से मैच करते हों. साथ ही, पक्का करें कि जिन फ़ील्ड को सादे टेक्स्ट के तौर पर रखना ज़रूरी है (जैसे कि mobile_ids) उन्हें हैश न किया गया हो.

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

  अगर JSON का इस्तेमाल करके अनुरोध भेजे जाते हैं, तो पक्का करें कि टाइमस्टैंप स्ट्रिंग में टाइमज़ोन ऑफ़सेट के साथ आरएफ़सी 3339 फ़ॉर्मैट का इस्तेमाल किया गया हो.

• फ़ोन नंबर को सही फ़ॉर्मैट में रखना: पक्का करें कि फ़ोन नंबर में देश का कोड शामिल हो. साथ ही, हैश करने से पहले E.164 फ़ॉर्मैट का इस्तेमाल करें.

• खाली या तय साइज़ से बड़े रिकॉर्ड हटाएं: user_identifiers को हर रिकॉर्ड की सीमा (10 आइडेंटिफ़ायर) पर कैप करें. साथ ही, खाली कस्टम पैरामीटर हटाएं और ऐसे किसी भी रिकॉर्ड को हटा दें जिसमें कोई मान्य आइडेंटिफ़ायर न हो.

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

• अनुरोधों की जांच करने के लिए validateOnly का इस्तेमाल करें: डेटा को शामिल किए या हटाए बिना, फ़ास्ट-फ़ेल गड़बड़ियों का पता लगाने के लिए, validateOnly को true पर सेट करके अनुरोध भेजें. सिर्फ़ पुष्टि करने के लिए किया गया अनुरोध पूरा होने का मतलब यह नहीं है कि एसिंक्रोनस प्रोसेसिंग के दौरान गड़बड़ियां नहीं होंगी. इसलिए, सामान्य अनुरोध भेजने के बाद, अनुरोध की स्थिति और गड़बड़ी की जानकारी देखना जारी रखें.

नॉर्मलाइज़ेशन और हैशिंग के नियमों के बारे में ज़्यादा जानने के लिए, उपयोगकर्ता के डेटा को फ़ॉर्मैट करना लेख पढ़ें.

अनुरोध की स्थिति और गड़बड़ी की जानकारी देखना

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

हर IngestAudienceMembersResponse या IngestEventsResponse से request_id को कैप्चर और इकट्ठा करें. साथ ही, अनुरोध की स्थिति और गड़बड़ी की जानकारी देखने के लिए, अनुरोध आईडी का इस्तेमाल करें.

कोटा पर नज़र रखना और उससे जुड़ी सूचनाएं पाना

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

प्रोडक्शन में डिप्लॉय करना

लोकल टेस्टिंग से प्रोडक्शन वर्कलोड पर स्विच करते समय, ऐप्लिकेशन के डिफ़ॉल्ट क्रेडेंशियल का इस्तेमाल करें. इसके लिए, अटैच किए गए सर्विस खाते या Workload Identity Federation का इस्तेमाल करें. इससे, बिना इंटरैक्ट किए और सुरक्षित तरीके से पुष्टि की जा सकेगी.

अलग-अलग प्रोडक्शन एनवायरमेंट के लिए, पुष्टि करने की सुविधा को कॉन्फ़िगर करने के बारे में जानने के लिए, प्रोडक्शन में डिप्लॉय करें लेख पढ़ें.