ב-Google Ads API יש מגבלות על פעולות API, כמו מספר הפעולות שאפשר לשלוח בבקשת שינוי אחת. בטבלה הבאה מפורטות חלק מהמגבלות והמכסות החשובות שכדאי להכיר.
| סוג הבקשה, המגבלה וקוד השגיאה | ||
|---|---|---|
| פעולות עם רמת גישה של חוקר |
2,880 פעולות API ביום בחשבונות פעילים 15,000 פעולות API ביום בחשבונות בדיקה |
RESOURCE_EXHAUSTED
|
| פעולות עם רמת גישה בסיסית | 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 ופעולות mutate. המגבלות על פעולות 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 נספרת כפעולה אחת במסגרת מכסת הפעולות היומית של המשתמש.
דוגמאות לבקשות כאלה:
BatchJobService.ListMutateJobResultsConversionUploadService.UploadCallConversionsConversionUploadService.UploadClickConversionsOfflineUserDataJobService.AddOfflineUserDataJobOperationsOfflineUserDataJobService.CreateOfflineUserDataJobUserDataService.UploadUserData
בקשות שמחזירות חריגות ב-API
בקשות שנדחות עם השגיאה GoogleAdsFailure עדיין נספרות במכסת הפעולות היומית של המשתמש.
בקשות שנכשלות אבל לא מחזירות GoogleAdsFailure, למשל בקשות שנובעות משגיאה ברמת הרשת, לא ייספרו במסגרת מכסת הפעולות היומית של המשתמש, כי הבקשות לא יגיעו לשירות. דוגמה לכך היא כשל בקישוריות לרשת.
שירות לתכנון מילות מפתח
בגלל העלות והמורכבות, שיטות השירות הבאות של תכנון מילות מפתח כפופות למגבלות נפרדות מסוגים אחרים של בקשות.
מוגבל ל-1 בקשות לשנייה לכל מספר לקוח:
KeywordPlanIdeaService.GenerateKeywordIdeasKeywordPlanIdeaService.GenerateKeywordHistoricalMetricsKeywordPlanIdeaService.GenerateKeywordForecastMetrics
בקשות שמפירות את המגבלות האלה נדחות עם השגיאה:
RESOURCE_EXHAUSTED.שאילתה אחת לשנייה (QPS) מחושבת כ-60 בקשות ל-60 שניות.
מוגבל ל-2 בקשות לשנייה לכל CID:
חשוב לזכור את המגבלות האלה כשיוצרים תוכנית מילות מפתח.
| אובייקט של תוכנית למילות מפתח | מספר מקסימלי |
|---|---|
KeywordPlan לכל חשבון |
10,000 |
KeywordPlanAdGroup לכל KeywordPlan |
200 |
KeywordPlanAdGroupKeyword לכל KeywordPlan |
10,000 |
KeywordPlanCampaignKeyword (מילות מפתח שליליות) |
1,000 |
KeywordPlanCampaign לכל KeywordPlan |
1 |
שירות מדדי הקהלים
השיטות הבאות בתוך השיטות של AudienceInsightsService כפופות למגבלות מכסה ספציפיות.
מוגבל לכ-200 בקשות ביום לכל מספר לקוח:
מוגבל ל-2 בקשות לשנייה לכל קוד מפתח:
שירות העלאת המרות
מוגבל ל-2,000 המרות מסוג שיחה או קליק לכל בקשה:
בקשות שמפרות את המגבלות האלה נדחות עם השגיאה:
TOO_MANY_CONVERSIONS_IN_REQUEST.
שירות להעלאת התאמות של המרות
מוגבל ל-2,000 שינויים של ערכי המרות לכל בקשה:
בקשות שמפרות את המגבלות האלה נדחות עם השגיאה:
TOO_MANY_ADJUSTMENTS_IN_REQUEST.
כללים לקביעת ערכי המרות
מוגבל ל-100,000 כללים לקביעת ערכי המרות לכל חשבון.
בקשות שמפרות את המגבלה הזו נדחות עם השגיאה
ResourceCountLimitExceededError.ACCOUNT_LIMIT.
אם כבר קיים ConversionValueRuleSet עם attachment_type של CUSTOMER בחשבון, צריך להוסיף את כל הכללים החדשים לקביעת ערך המרות לאותו סט כדי שהם יהפכו לפעילים. אם לא קיים כלל כזה לקביעת ערך המרה, צריך ליצור אותו ולהוסיף לו את הכללים לקביעת ערך המרה, כמו שמתואר במאמר בנושא יצירת קבוצות של כללים.
שירותים שקשורים לחיוב ולתקציב החשבון
אפשר לבצע שינויים רק בחשבונות שמוגדר בהם חיוב חודשי.
בקשות שמפירות את ההגבלה הזו נדחות עם השגיאה:
MUTATE_NOT_ALLOWED.מותרת רק פעולה 1 בבקשות שינוי.
בקשות שמפירות את ההגבלה הזו נדחות עם השגיאה:
TOO_MANY_MUTATE_OPERATIONS.מומלץ להמתין לפחות 12 שעות בין שינויים בהזמנת תקציב לאותו חשבון. ביצוע שינויים לפני שעברו 12 שעות עלול לגרום לכשלים שלא ניתן לתקן, ואפשר לפתור אותם רק באמצעות הנציג של חשבון Google Ads.
הזמנות לחשבונות של לקוחות
אפשר להזמין משתמשים חדשים לחשבונות לקוח קיימים באמצעות CustomerUserAccessService. התכונה הזו שולחת אימיילים עם הזמנות למשתמשים אחרים, ולכן יש פוטנציאל לשימוש לרעה בה. לכן יש מגבלות על אופן הפעולה שלה:
משתמשים לא יכולים לקבל יותר מהזמנה אחת בהמתנה לאותו חשבון לקוח. אם נשלחת בקשה נוספת לשליחת הזמנה למשתמש שכבר יש לו הזמנה בהמתנה, השגיאה הבאה מוחזרת:
ACCESS_INVITATION_ERROR_EMAIL_ADDRESS_ALREADY_HAS_PENDING_INVITATION.בכל חשבון לקוח יכולות להיות עד 70 הזמנות בהמתנה בכל זמן נתון. אם נשלחת בקשה שגורמת לחריגה מהערך הזה, השגיאה הבאה מוחזרת:
ACCESS_INVITATION_ERROR_PENDING_INVITATIONS_LIMIT_EXCEEDED.
נתוני המשתמש
הנתונים של המשתמשים מנוהלים באמצעות 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.