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

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

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

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

מגבלות השימוש היומיות ב-API מבוססות על מספר הפעולות ב-API שבוצעו בפרויקט בענן שלכם ב-Google Cloud. פעולות API הן הסכום הכולל של בקשות Search ו-SearchStream, פעולות mutate נפרדות ובקשות שירות אחרות. המגבלות על פעולות ה-API היומיות תלויות ברמת הגישה ל-API של הפרויקט בענן ב-Google Cloud. במדריך לרמות גישה ולשימוש מותר מפורטות מגבלות הפעולה הספציפיות של ה-API לכל רמת גישה.

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

מגבלות של gRPC

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

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

בקשות שמפירות את המגבלה הזו לא ייצרו את השגיאה GoogleAdsError, אלא את השגיאה RESOURCE_EXHAUSTED (קוד gRPC‏ 8 / HTTP‏ 429). אפשר לעיין ברשימת קודי השגיאה וההודעות של gRPC.

בקשות לשינוי נתונים

בנוסף לכך שבקשת mutate נספרת במכסת הפעולות היומית של המשתמש, היא לא יכולה להכיל יותר מ-10,000 פעולות mutate לכל בקשה. בקשות שמפרות את המגבלה הזו נדחות ומוצגת השגיאה: TOO_MANY_MUTATE_OPERATIONS.

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

בקשות חיפוש

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

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

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

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

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

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

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

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

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

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

הכלי לתכנון מילות מפתח

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

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

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

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

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

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

שירות להעלאת שינויים בערכי המרות

כללים לקביעת ערכי המרות

אם כבר קיים בחשבון ConversionValueRuleSet עם attachment_type של CUSTOMER, כדי שהכללים החדשים לקביעת ערך המרה יהיו פעילים, צריך להוסיף אותם לאותו סט. אם לא קיים כלל כזה לקביעת ערך המרה, צריך ליצור אותו ולהוסיף לו את הכללים לקביעת ערכי המרות, כמו שמתואר במאמר יצירת קבוצות של כללים.

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

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

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

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

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

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

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

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

  • משתמשים לא יכולים לקבל יותר מהזמנה אחת בהמתנה לאותו חשבון לקוח. אם נשלחת בקשה נוספת לשלוח הזמנה למשתמש שכבר יש לו הזמנה בהמתנה, תוחזר השגיאה הבאה: EMAIL_ADDRESS_ALREADY_HAS_PENDING_INVITATION.

  • בחשבונות לקוח יכולות להיות עד 70 הזמנות שממתינות לאישור בו-זמנית. אם נשלחת בקשה שחורגת מהערך הזה, מוחזרת השגיאה הבאה: 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 לפרופיל הנכון של משתמש הקצה.

אם אתם מסתמכים על פרטים אישיים מזהים כמו כתובות אימייל או מספרי טלפון מגובבים, ודאו שהם מנורמלים ומגובבים בהתאם לדרישות של Google Ads API (SHA-256, אותיות קטנות, ללא רווחים) כדי למנוע כשלים בקישור.

לדוגמה, אם למשתמש יש 30 כתובות אימייל, אפשר לשלוח שני אובייקטים מסוג UserData עם third_party_user_id משותף (כדי לא לחרוג מהמגבלה של 20 מזהים, שמים את thirdPartyUserId וכתובות אימייל 1 עד 19 באובייקט הראשון, ואת thirdPartyUserId וכתובות אימייל 20 עד 30 באובייקט השני):

{
  "userIdentifiers": [
    { "thirdPartyUserId": "user123" },
    { "hashedEmail": "SHA256_OF_EMAIL_1" },
    // Hashed emails 2 through 18 are omitted here.
    { "hashedEmail": "SHA256_OF_EMAIL_19" }
  ]
}

{
  "userIdentifiers": [
    { "thirdPartyUserId": "user123" },
    { "hashedEmail": "SHA256_OF_EMAIL_20" },
    // Hashed emails 21 through 29 are omitted here.
    { "hashedEmail": "SHA256_OF_EMAIL_30" }
  ]
}

המגבלה הכוללת ל-user_identifiers בכל הפעולות ב-AddOfflineUserDataJobOperationsRequest יחיד היא 100,000 (OfflineUserDataJob יכול לקבל כמה קריאות של AddOfflineUserDataJobOperationsRequest, עד למקסימום מומלץ של 1,000,000 פעולות לכל משימה). בהעלאות סינכרוניות באמצעות UploadUserDataRequest (UserDataService.UploadUserData), כל בקשה מוגבלת ל-10 פעולות לכל היותר ול-100 user_identifiers בכל הבקשה.

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

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

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

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

הקודם
סקירה כללית
הבא
מגבלות מערכת