ב-Google Ads API יש מגבלות על פעולות API, כמו מספר הפעולות שאפשר לשלוח בבקשה לשינוי נתונים אחת. בטבלה הבאה מפורטות חלק מהמגבלות והמכסות החשובות שכדאי להכיר.
| סוג הבקשה, המגבלה וקוד השגיאה | ||
|---|---|---|
| פעולות עם רמת גישה של חוקר |
2,880 פעולות API ביום בחשבונות פעילים 15,000 פעולות API ביום בחשבונות בדיקה |
RESOURCE_EXHAUSTED
|
| פעולות עם רמת גישה בסיסית | 15,000 פעולות API ביום בחשבונות בדיקה ובחשבונות פעילים |
RESOURCE_EXHAUSTED
|
| בקשות לשינוי נתונים |
10,000 פעולות שינוי לכל בקשה 100 פעולות לכל בקשה |
TOO_MANY_MUTATE_OPERATIONS
|
| בקשות לשירותי תכנון | 1 QPS |
RESOURCE_EXHAUSTED
|
| בקשות שירות בנושא העלאת המרות | 2,000 המרות לכל בקשה |
TOO_MANY_CONVERSIONS_IN_REQUEST
|
| בקשות שירות בנושא חיובים ותקציב החשבון | פעולה אחת לכל בקשה לשינוי נתונים |
TOO_MANY_MUTATE_OPERATIONS
|
מגבלות יומיות על פעולות API
מגבלות השימוש היומיות ב-API מבוססות על מספר פעולות ה-API שבוצעו על ידי הפרויקט שלכם ב-Google Cloud. פעולות API הן הסכום הכולל של בקשות get ופעולות שינוי. המגבלות על פעולות יומיות ב-API תלויות ברמת הגישה ל-API של הפרויקט שלכם ב-Google Cloud. במדריך רמות הגישה והשימוש המותר מפורטות מגבלות ספציפיות על פעולות API לכל רמת גישה.
בקשות שחורגות מהמגבלות האלה נדחות עם השגיאה:
RESOURCE_EXHAUSTED.
מגבלות של gRPC
כל ספריות הלקוח של Google Ads API משתמשות ב-gRPC כדי ליצור בקשות ותגובות. כברירת מחדל, גודל ההודעה ב-gRPC הוא 4MB, אבל בספריות הלקוח שלנו הגודל המקסימלי של ההודעה מוגדר ל-64MB כדי לשפר את היעילות.
התשובות לא יכולות לחרוג מהמגבלה הזו. לדוגמה, בקשת חיפוש שכוללת הרבה שדות עשויה ליצור תגובה שגודלה עולה על 64MB. כדי לא להגיע למגבלה הזו, אפשר לצמצם את מספר השדות שנבחרו או להשתמש בסטרימינג. במקרה של שינויים, כדאי לשלוח פחות פעולות בכל בקשה.
בקשות שמפירות את המגבלה הזו לא ייצרו GoogleAdsError, אבל ייצרו שגיאת gRPC 429 Resource
Exhausted. אפשר לעיין ברשימת קודי השגיאה וההודעות של gRPC.
בקשות לשינוי נתונים
בנוסף לכך שבקשת mutate נספרת במכסת הפעולות היומית של המשתמש, היא לא יכולה להכיל יותר מ-10,000 פעולות לכל בקשה.
בקשות שמפירות את המגבלה הזו נדחות עם השגיאה:
TOO_MANY_MUTATE_OPERATIONS.
בהמשך מפורטות מגבלות נוספות ושיקולים לגבי שירותים ספציפיים וסוגי בקשות ספציפיים.
בקשות חיפוש
בקשת Search או SearchStream נספרת כפעולה אחת במכסת הפעולות היומית של המשתמש. בקשת SearchStream אחת נספרת כפעולת API אחת, ללא קשר למספר האצוות.
בקשות עם מספור עמודים
בקשות עם חלוקה לדפים (לדוגמה, בקשות שמכילות next_page_token תקין) לא נספרות במכסת הפעולות היומית של המשתמש.
עם זאת, בקשות לעימוד שמכילות טוקן דף לא חוקי או שפג תוקפו ייצרו חריגה וייכללו במכסת הפעולות היומית.
פרטים נוספים על חלוקה לדפים זמינים במאמר בנושא חלוקה לדפים של תוצאות.
סוגים אחרים של בקשות
בקשה שלא משויכת ל-Get, ל-Mutate, ל-Search או ל-SearchStream נספרת כפעולה אחת במכסת הפעולות היומית של המשתמש.
דוגמאות לבקשות כאלה:
BatchJobService.ListMutateJobResultsConversionUploadService.UploadCallConversionsConversionUploadService.UploadClickConversionsOfflineUserDataJobService.AddOfflineUserDataJobOperations
בקשות שמחזירות חריגות ב-API
בקשות שנדחות עם GoogleAdsFailure עדיין נספרות במכסת הפעולות היומית של המשתמש.
בקשות שנכשלו אבל לא מחזירות GoogleAdsFailure, כמו שגיאה ברמת הרשת, לא ייספרו במכסת הפעולות היומית של המשתמש כי הבקשות לא יגיעו לשירות. דוגמה לכך היא כשל בחיבור לרשת.
שירות לתכנון מילות מפתח
בגלל העלות והמורכבות, השיטות הבאות של שירות תכנון מילות מפתח כפופות למגבלות נפרדות מסוגים אחרים של בקשות.
מוגבל לבקשה אחת לשנייה לכל מספר לקוח:
בקשות שמפירות את המגבלות האלה נדחות עם השגיאה:
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 בקשות ביום לכל מספר לקוח:
AudienceInsightsService.GenerateAudienceCompositionInsightsAudienceInsightsService.GenerateSuggestedTargetingInsights- מוגבל ל-2 בקשות לשנייה לכל פרויקט בענן של Google:
AudienceInsightsService.GenerateTargetingSuggestionMetrics
שירות העלאת המרות
מוגבל ל-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.מותר לבצע רק פעולה אחת בבקשות שינוי.
בקשות שמפירות את המגבלה הזו נדחות עם השגיאה:
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 בפעולה create או remove מתייחס למשתמש קצה יחיד. השדה user_identifiers באובייקט UserData יחיד מוגבל ל-20 מזהים לכל היותר. חריגה מהמגבלה הזו באובייקט UserData יחיד תגרום לשגיאה OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS או UserDataError.TOO_MANY_USER_IDENTIFIERS.
טיפול במשתמשים עם יותר מ-20 מזהים
אם למשתמש קצה יחיד יש יותר מ-20 מזהים שצריך להעלות, צריך לפצל את המזהים האלה בין כמה אובייקטים של UserData. כדי לוודא ש-Google יכולה לשייך את כל המזהים האלה לאותו משתמש קצה, כל אובייקט UserData של המשתמש צריך לכלול לפחות user_identifier משותף, כמו אותו hashed_email, hashed_phone_number או third_party_user_id. Google משתמשת במזהים המשותפים האלה כדי לקשר ולמזג את המידע מפעולות UserData נפרדות עם הפרופיל הנכון של משתמש הקצה.
אם אתם מסתמכים על PII כמו כתובות אימייל או מספרי טלפון מגובבים, חשוב לוודא שהם מנורמלים ומגובבים בהתאם לדרישות של Google Ads API (SHA-256, אותיות קטנות, ללא רווחים) כדי למנוע כשלים בקישור.
לדוגמה, אם למשתמש יש 30 כתובות אימייל, אפשר לשלוח שני אובייקטים של UserData.
UserData 1: {third_party_user_id: "user123",hashed_email: "email1@...", ...hashed_email: "email19@..."}UserData 2: {third_party_user_id: "user123",hashed_email: "email20@...", ...hashed_email: "email30@..."}
המגבלה הכוללת ל-user_identifiers בכל הפעולות ב-OfflineUserDataJob נשארת 100,000.
סוגים אחרים של מגבלות
שדה חוזר, כמו רשימת פעולות, שמכיל יותר מדי פריטים בבקשה, עלול לגרום לשגיאה:
REQUEST_SIZE_LIMIT_EXCEEDED. יכול להיות שבעיות אחרות גורמות לאותה הודעת שגיאה.
אם נתקלתם במגבלה הזו ואתם שולחים בקשות שמשתמשות בשדה חוזר, נסו לצמצם את מספר הפריטים בשדה החוזר באמצעות פריסת רשימת פעולות בבקשה לשינוי נתונים.
כשמבצעים שאילתת GAQL, המספר המקסימלי של פריטים בסעיף IN הוא 20,000. אם חורגים מהמגבלה הזו, מוחזרת שגיאה מסוג FILTER_HAS_TOO_MANY_VALUES.