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

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

סוג הבקשה, המגבלה וקוד השגיאה
פעולות עם רמת הגישה Test ‫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
בקשות לשירות תכנון ‫1 QPS RESOURCE_EXHAUSTED
בקשות של שירות העלאת ההמרות ‫2,000 המרות לכל בקשה TOO_MANY_CONVERSIONS_IN_REQUEST
בקשות שירות בנושא חיוב ותקציב חשבון פעולה אחת לכל בקשה לשינוי נתונים TOO_MANY_MUTATE_OPERATIONS

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

מגבלות השימוש היומי ב-API מבוססות על מספר פעולות ה-API שבוצעו על ידי הפרויקט שלכם ב-Google Cloud. פעולות API הן הסכום הכולל של בקשות Search ו-SearchStream, פעולות שינוי נפרדות ובקשות אחרות לשירות. המגבלות על פעולות יומיות ב-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 נפרדות עם הפרופיל הנכון של משתמש הקצה.

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

לדוגמה, אם למשתמש יש 30 כתובות אימייל, אפשר לשלוח שני UserData אובייקטים שמשתפים third_party_user_id משותף (לשים את thirdPartyUserId בתוספת אימיילים 1 עד 19 באובייקט הראשון כדי לא לחרוג מהמגבלה של 20 מזהים, ואת 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.

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