מגבלות ומכסות ל-API

ב-Google Ads API יש מגבלות על פעולות API, כמו מספר הפעולות שאפשר לשלוח בבקשת שינוי אחת. בטבלה הבאה מפורטות חלק מהמגבלות והמכסות החשובות שכדאי להכיר.

סוג הבקשה, המגבלה וקוד השגיאה
פעולות עם רמת גישה בסיסית ‫15,000 פעולות API ביום RESOURCE_EXHAUSTED
בקשות לשינוי ‫10,000 פעולות לכל בקשה TOO_MANY_MUTATE_OPERATIONS
בקשות לשירותי תכנון ‫1 QPS RESOURCE_EXHAUSTED
בקשות שירות בנושא העלאת המרות ‫2,000 המרות לכל בקשה TOO_MANY_CONVERSIONS_IN_REQUEST
בקשות שירות בנושא חיוב ותקציב חשבון פעולה אחת לכל בקשת שינוי TOO_MANY_MUTATE_OPERATIONS

מגבלות יומיות על פעולות API

המגבלות היומיות על השימוש ב-API מבוססות על מספר פעולות ה-API שבוצעו לכל אסימון מפתח. פעולות API הן הסכום הכולל של בקשות get ופעולות שינוי. המגבלות על פעולות API יומיות תלויות ברמת הגישה של קוד המפתח. במדריך לרמות גישה ולשימוש מותר מפורטות המגבלות הספציפיות על פעולות API לכל רמת גישה.

בקשות שמפירות את המגבלות האלה נדחות עם השגיאה: RESOURCE_EXHAUSTED.

מגבלות של gRPC

כל ספריות הלקוח של Google Ads API משתמשות ב-gRPC כדי ליצור בקשות ותגובות. כברירת מחדל, גודל ההודעה ב-gRPC הוא 4MB, אבל בספריות הלקוח שלנו גודל ההודעה המקסימלי מוגדר ל-64MB כדי לשפר את היעילות.

התשובות לא יכולות לחרוג מהמגבלה הזו. לדוגמה, בקשת חיפוש שכוללת הרבה שדות עשויה ליצור תגובה שגודלה עולה על 64MB. כדי לא לחרוג מהמגבלה הזו, אפשר לצמצם את מספר השדות שנבחרו או להשתמש בסטרימינג. במקרה של שינויים, כדאי לשלוח פחות פעולות בכל בקשה.

בקשות שמפירות את המגבלה הזו לא ייצרו GoogleAdsError, אבל ייצרו שגיאת gRPC‏ 429 Resource Exhausted. אפשר לעיין ברשימת קודי השגיאה וההודעות של gRPC.

בקשות לשינוי

בנוסף לספירה במסגרת מכסת הפעולות היומית של המשתמש, בקשת שינוי לא יכולה להכיל יותר מ-10,000 פעולות לכל בקשה.

בקשות שמפירות את המגבלה הזו נדחות עם השגיאה: TOO_MANY_MUTATE_OPERATIONS.

בהמשך מפורטות מגבלות נוספות ושיקולים נוספים לגבי שירותים ספציפיים וסוגים ספציפיים של בקשות.

בקשות חיפוש

בקשת Search או SearchStream נספרת כפעולה אחת במכסת הפעולות היומית של המשתמש. בקשה אחת של SearchStream נספרת כפעולת API אחת, ללא קשר למספר האצוות.

בקשות עם מספור עמודים

בקשות עם מספור עמודים (לדוגמה, בקשות שמכילות next_page_token תקין) לא נספרות במכסת הפעולות היומית של המשתמש. עם זאת, בקשות עימוד שמכילות טוקן דף לא חוקי או שפג תוקפו ייצרו חריגה וייכללו במכסת הפעולות היומית.

פרטים נוספים על חלוקה לדפים זמינים במאמר בנושא חלוקה לדפים של תוצאות.

סוגים אחרים של בקשות

בקשה שלא משויכת ל-Get, ל-Mutate, ל-Search או ל-SearchStream נספרת כפעולה אחת במסגרת מכסת הפעולות היומית של המשתמש.

דוגמאות לבקשות כאלה:

בקשות שמחזירות חריגות ב-API

בקשות שנדחות עם השגיאה GoogleAdsFailure עדיין נספרות במסגרת המכסה היומית של המשתמש.

בקשות שנכשלות אבל לא מחזירות GoogleAdsFailure, כמו בקשות שנובעות משגיאה ברמת הרשת, לא ייספרו במכסת הפעולות היומית של המשתמש כי הבקשות לא יגיעו לשירות. דוגמה לכך היא כשל בקישוריות לרשת.

שירות לתכנון מילות מפתח

בגלל העלות והמורכבות, שיטות השירות הבאות של תכנון מילות מפתח כפופות למגבלות נפרדות מסוגים אחרים של בקשות.

חשוב לזכור את המגבלות האלה כשיוצרים תוכנית למילות מפתח.

אובייקט של תוכנית למילות מפתח מספר מקסימלי
KeywordPlan לכל חשבון 10,000
KeywordPlanAdGroup לכל KeywordPlan 200
KeywordPlanAdGroupKeyword לכל KeywordPlan 10,000
KeywordPlanCampaignKeyword (מילות מפתח שליליות) 1,000
KeywordPlanCampaign לכל KeywordPlan 1

שירות מדדי הקהלים

השיטות הבאות בתוך השיטות של AudienceInsightsService כפופות למגבלות מכסה ספציפיות.

שירות העלאת המרות

שירות להעלאת התאמות של המרות

שירותים שקשורים לחיוב ולתקציב החשבון

  • אפשר לבצע שינויים רק בחשבונות שמוגדר בהם חיוב חודשי.

    בקשות שמפירות את המגבלה הזו נדחות עם השגיאה: MUTATE_NOT_ALLOWED.

  • מותר לבצע רק פעולה אחת בבקשות שינוי.

    בקשות שמפירות את המגבלה הזו נדחות עם השגיאה: TOO_MANY_MUTATE_OPERATIONS.

  • מומלץ להמתין לפחות 12 שעות בין שינויים בהזמנת תקציב לאותו חשבון. ביצוע שינויים לפני שעברו 12 שעות עלול לגרום לכשלים שלא ניתן לתקן, ואפשר לפתור אותם רק באמצעות הנציג של חשבון Google Ads.

הזמנות לחשבונות של לקוחות

אפשר להזמין משתמשים חדשים לחשבונות לקוח קיימים באמצעות CustomerUserAccessService. התכונה הזו שולחת הזמנות באימייל למשתמשים אחרים, ולכן יש פוטנציאל לשימוש לרעה בה. לכן יש מגבלות על אופן הפעולה שלה:

נתוני משתמשים

הנתונים של המשתמשים מנוהלים בהתאם לUserDataService ולOfflineUserDataJobService. בפעולת יצירה או הסרה נתונה של UserData, כל קבוצה של user_identifiers צריכה להיות ספציפית למשתמש יחיד.

כדי לאכוף את זה, אם יש יותר מ-20 user_identifiers בקבוצת UserData, מוחזרת שגיאה מסוג OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS או UserDataError.TOO_MANY_USER_IDENTIFIERS.

מותר לכם להשתמש בעד 100,000 מזהי משתמשים, לא משנה כמה פעולות תבצעו.

סוגים אחרים של מגבלות

שדה חוזר, כמו רשימת פעולות, שמכיל יותר מדי פריטים בבקשה עלול לגרום לשגיאה: REQUEST_SIZE_LIMIT_EXCEEDED. הודעת השגיאה הזו יכולה להופיע גם בגלל בעיות אחרות.

אם נתקלתם במגבלה הזו ואתם שולחים בקשות שמשתמשות בשדה חוזר, נסו לצמצם את מספר הפריטים בשדה החוזר באמצעות פריסת רשימה של פעולות בבקשת שינוי.

כשמבצעים שאילתת GAQL, המספר המקסימלי של פריטים בסעיף IN הוא 20,000. אם תחרגו מהמגבלה הזו, תוחזר שגיאת FILTER_HAS_TOO_MANY_VALUES.