GoogleAdsService.Search
आपके अनुरोध में page_size
की जानकारी देकर, पेजिंग की सुविधा देता है.
इससे, क्वेरी के नतीजे के सेट को कई जवाबों में बांट दिया जाता है. हर रिस्पॉन्स में, ज़्यादा से ज़्यादा page_size
ऑब्जेक्ट होते हैं. अगर
page_size
के बारे में नहीं बताया गया है,
तो यह अपने-आप 10,000 पंक्तियों पर सेट हो जाता है.
उदाहरण के लिए, इस क्वेरी के लिए:
SELECT
ad_group.id,
ad_group_criterion.type,
ad_group_criterion.criterion_id,
ad_group_criterion.keyword.text,
ad_group_criterion.keyword.match_type
FROM ad_group_criterion
WHERE ad_group_criterion.type = KEYWORD
अगर आपके खाते में 50,000 कीवर्ड हैं और page_size
को 1,000
पर सेट किया गया है, तो नतीजे के सेट में पहले जवाब में 1,000 GoogleAdsRow
ऑब्जेक्ट और एक next_page_token
शामिल होंगे.
अगली एक हज़ार लाइनों को फिर से पाने के लिए, उसी पेज साइज़ के साथ फिर से अनुरोध भेजें. हालांकि, अनुरोध के page_token
को रिस्पॉन्स के next_page_token
पर अपडेट करें. बाद के अनुरोधों में page_size
की वैल्यू हर बार अलग-अलग हो सकती है. ध्यान दें कि जवाब में पंक्तियों का आखिरी बैच next_page_token
को अपने-आप नहीं भरा जाता.
हमारी क्लाइंट लाइब्रेरी, पेजिंग को अपने-आप मैनेज करती हैं. आपको सिर्फ़ जवाब की पंक्तियों को दोहराना होगा. जब मौजूदा पेज की सभी लाइनें दिखती हैं, तो क्लाइंट लाइब्रेरी आपकी ओर से लाइनों का नया पेज अपने-आप फ़ेच कर लेती है. ऐसा तब तक होता है, जब तक पूरा डेटा सेट वापस नहीं मिल जाता. gRPC की जगह REST का इस्तेमाल करने पर, आपको हर नए पेज के लिए साफ़ तौर पर अनुरोध करना होगा.
Google Ads API पूरे डेटा सेट को अंदरूनी तौर पर कैश मेमोरी में सेव करता है, इसलिए बाद के अनुरोध, शुरुआती अनुरोध से ज़्यादा तेज़ होते हैं. अपने इस्तेमाल के उदाहरण के आधार पर, page_size
को 1 से 10,000 के बीच की किसी भी वैल्यू पर सेट किया जा सकता है. आम तौर पर, तेज़ परफ़ॉर्मेंस के लिए, कम दोतरफ़ा यात्रा के लिए बड़े page_size
का इस्तेमाल करें.
कैश मेमोरी में सेव किए गए डेटा का फ़ायदा पाने के लिए, बाद के अनुरोधों में आपकी क्वेरी बिलकुल वैसी ही होनी चाहिए ; खास तौर पर बेसिक ऐक्सेस के लिए, आपके कोटा पर अनुरोध नहीं किए जाएंगे. अगर क्वेरी अलग है और उसे उसी पेज के टोकन के साथ भेजा जाता है, तो एक गड़बड़ी दिखती है.