Google Ads API אוכף מגבלות על פעולות API, כמו מספר הפעולות שאפשר לשלוח בבקשת שינוי אחת. הטבלה הבאה מציגה סיכום של חלק מהמגבלות והמכסות החשובות שצריך לשים לב אליהן.
סוג הבקשה, הגבלה וקוד שגיאה | |||
---|---|---|---|
בקשות עם חלוקה לדפים | 10,000 שורות לדף |
INVALID_PAGE_SIZE
|
|
פעולות עם גישה בסיסית | 15,000 פעולות API ביום |
RESOURCE_EXHAUSTED
|
|
בקשות שינוי | 10,000 פעולות לכל בקשה |
TOO_MANY_MUTATE_OPERATIONS
|
|
בקשות לשירות תכנון | QPS אחד |
RESOURCE_EXHAUSTED
|
|
בקשות של שירות העלאת המרות | 2,000 המרות לכל בקשה |
TOO_MANY_CONVERSIONS_IN_REQUEST
|
|
בקשות שירות לחיוב ותקציב חשבון | פעולה אחת לכל בקשת שינוי |
TOO_MANY_MUTATE_OPERATIONS
|
מגבלות יומיות על פעולות API
מגבלות השימוש היומיות ב-API מבוססות על מספר הפעולות ב-API שבוצעו לכל קוד מפתח. פעולות API הן הסכום הכולל של בקשות אחזור ופעולות שינוי. המגבלות על פעולות 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
תקין) לא נספרות כחלק ממכסת הפעולות היומית של המשתמש.
עם זאת, בקשות חלוקה לדפים שמכילות אסימון דף שפג תוקפו או לא בתוקף יובילו לחריגה ממכסת הפעולות היומית.
בקשות עם חלוקה לדפים, כמו בקשות חיפוש, כפופות גם למגבלת Page size cannot exceed 10,000 rows
, והן נדחות אם יש הפרה של המגבלה הזו, עם השגיאה: INVALID_PAGE_SIZE
.
לפרטים נוספים על החלוקה לדפים, קראו את המאמר דפדוף בתוצאות.
סוגים אחרים של בקשות
בקשה שאינה בקשה Get
, Mutate
, Search
או SearchStream
נספרת כפעולה אחת במסגרת מכסת הפעולות היומית של המשתמש.
דוגמאות לבקשות כאלה:
BatchJobService.ListMutateJobResults
ConversionUploadService.UploadCallConversions
ConversionUploadService.UploadClickConversions
OfflineUserDataJobService.AddOfflineUserDataJobOperations
OfflineUserDataJobService.CreateOfflineUserDataJob
UserDataService.UploadUserData
בקשות שמחזירות חריגים באמצעות ה-API
בקשות שנדחות עם הערך GoogleAdsFailure
עדיין נספרות כחלק ממכסת הפעולות היומית של המשתמש.
בקשות שנכשלו אבל לא מחזירות GoogleAdsFailure
, למשל משגיאה ברמת הרשת, לא ייחשבו כחלק ממכסת הפעולות היומית של המשתמש כי הן אף פעם לא יגיעו לשירות. דוגמה לכשל בקישוריות רשת.
שירותי תכנון
בגלל העלות והמורכבות, שיטות שירות התכנון המפורטות בהמשך כפופות למגבלות נפרדות מסוגים אחרים של בקשות.
מוגבל לבקשה אחת לשנייה לכל CID או קוד מפתח:
KeywordPlanService.GetKeywordPlan
KeywordPlanService.GenerateHistoricalMetrics
KeywordPlanService.GenerateForecastMetrics
בקשות שמפירות את המגבלות האלה יידחו עם השגיאה:
RESOURCE_EXHAUSTED
.1 QPS מחושב כ-60 בקשות לכל 60 שניות.
חשוב לזכור את המגבלות האלה כשיוצרים תוכנית לשימוש במילות מפתח.
אובייקט של תוכנית מילות מפתח | מספר מקסימלי |
---|---|
KeywordPlan לכל חשבון |
10,000 |
KeywordPlanAdGroup לכל KeywordPlan |
200 |
KeywordPlanAdGroupKeyword לכל KeywordPlan |
10,000 |
KeywordPlanCampaignKeyword (מילות מפתח שליליות) |
1,000 |
KeywordPlanCampaign לכל KeywordPlan |
1 |
שירות העלאת המרות
מוגבל ל-2,000 המרות מסוג שיחה או קליקים עם כל בקשה:
בקשות שמפירות את המגבלות האלה יידחו עם השגיאה:
TOO_MANY_CONVERSIONS_IN_REQUEST
.
שירות העלאת שינויים בערכי המרות
מוגבל ל-2,000 התאמות של ערכי המרות לכל בקשה:
בקשות שמפירות את המגבלות האלה יידחו עם השגיאה:
TOO_MANY_ADJUSTMENTS_IN_REQUEST
.
שירותים לחיוב ולתקציב חשבון
אפשר לבצע שינויים רק בחשבונות שהוגדרו לחיוב חודשי.
בקשות שמפירות את המגבלה הזו יידחו עם השגיאה:
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
צריכה להיות ספציפית למשתמש יחיד.
כדי לאכוף את זה, מוחזרת השגיאה OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS
או UserDataError.TOO_MANY_USER_IDENTIFIERS
כשיש יותר מ-20 user_identifiers
בקבוצה של UserData
.
סוגים נוספים של מגבלות
שדה חוזר, כמו רשימת פעולות, שיש בו יותר מדי פריטים בבקשה, עלול לגרום לשגיאה: REQUEST_SIZE_LIMIT_EXCEEDED
.
הודעת השגיאה הזו יכולה גם לנבוע מבעיות אחרות.
אם נתקלים במגבלה הזו ומבצעים בקשות שמשתמשות בשדה חוזר, כדאי לנסות לצמצם את מספר הפריטים בשדה החוזר על ידי פריסה של רשימת פעולות בבקשת שינוי.
כשמבצעים שאילתת GAQL, מספר הפריטים המקסימלי בתנאי IN
הוא 20,000. אם חורגים מהמגבלה, תוחזר השגיאה FILTER_HAS_TOO_MANY_VALUES
.