סווגנו את השגיאות לפי הקטגוריות הכלליות הבאות:
- אימות
- ניתן לנסות שוב
- אימות
- קשור לסנכרון
הקטגוריות האלה לא כוללות את כל השגיאות האפשריות, וחלקן עשויות להתאים ליותר מקטגוריה אחת, אבל בכל זאת הן יכולות לשמש כנקודת התחלה לבניית הטיפול בשגיאות באפליקציה שלכם. ראו את המאמר שגיאות נפוצות לפרטים נוספים על שגיאה מסוימת.
שגיאות אימות
המונח 'אימות' מציין אם משתמש העניק לאפליקציה הרשאה לגשת ל-Google Ads בשמו. האימות מנוהל באמצעות פרטי כניסה שנוצרו באמצעות תהליך OAuth2.
הסיבה הנפוצה ביותר לשגיאת אימות שנובעת מגורמים שלא בשליטתכם היא שהמשתמש המאומת ביטל את ההרשאה שהוא נתן לאפליקציה שלכם לפעול בשמו. לדוגמה, אם האפליקציה מנהלת חשבונות Google Ads נפרדים עבור לקוחות עצמאיים ומאמתת בנפרד את החשבון של כל לקוח בזמן ניהול החשבון של אותו לקוח, הלקוח יכול לבטל את הגישה לאפליקציה בכל שלב. בהתאם למועד שבו הגישה שלכם בוטלה, יכול להיות שה-API יחזיר שגיאת AuthenticationError.OAUTH_TOKEN_REVOKED ישירות, או שהאובייקטים המובנים של פרטי הכניסה בספריות הלקוח עשויים לגרום לחריגת אסימון שבוטלה. בשני המקרים, אם לאפליקציה יש ממשק משתמש עבור הלקוחות שלכם, יכול להיות שהם יבקשו מהם להפעיל מחדש את תהליך OAuth2 כדי לאשר מחדש לאפליקציה לפעול בשמם.
שגיאות הניתנות לניסיון חוזר
שגיאות מסוימות, למשל TRANSIENT_ERROR
או INTERNAL_ERROR,
יכולות להצביע על בעיה זמנית שאפשר לפתור באמצעות ניסיון חוזר של
הבקשה לאחר השהיה קצרה.
בבקשות שיוזמים משתמשים, אחת האסטרטגיה היא לציין באופן מיידי שגיאה בממשק המשתמש, ולתת למשתמש אפשרות להפעיל ניסיון חוזר. לחלופין, האפליקציה תוכל לנסות שוב את הבקשה באופן אוטומטי, וכך לחשוף את השגיאה בממשק המשתמש רק אחרי שתגיעו למספר המקסימלי של ניסיונות חוזרים או לזמן ההמתנה הכולל של המשתמש.
במקרה של בקשות שנשלחות בקצה העורפי, האפליקציה צריכה לנסות שוב את הבקשה באופן אוטומטי, עד למספר המקסימלי של ניסיונות חוזרים.
כדי לבצע ניסיון חוזר של בקשות, צריך להשתמש במדיניות של השהיה מעריכית לפני ניסיון חוזר (exponential backoff). לדוגמה, אם השהיתם תחילה 5 שניות לפני הניסיון החוזר הראשון, תוכלו להשהות 10 שניות אחרי הניסיון השני ו-20 שניות לאחר הניסיון השלישי. השהיה מעריכית לפני ניסיון חוזר (exponential backoff) עוזרת לוודא שאתם לא קוראים ל-API באגרסיביות רבה מדי.
שגיאות אימות
שגיאות אימות מציינות שקלט לפעולה לא היה קביל.
לדוגמה, PolicyViolationError,
DateError,
DateRangeError,
StringLengthError, ו-UrlFieldError.
שגיאות אימות מתרחשות בדרך כלל בבקשות ביוזמת משתמש, שבהן המשתמש הזין קלט לא חוקי. במקרים כאלה, צריך להציג למשתמש הודעת שגיאה מתאימה על סמך השגיאה הספציפית ב-API שקיבלתם. בנוסף, לפני שמבצעים קריאה ל-API אפשר לוודא שהקלט של המשתמשים מכיל טעויות נפוצות, וכך האפליקציה תוכל להגיב בצורה טובה יותר לייעל את השימוש ב-API. בבקשות מהקצה העורפי, האפליקציה יכולה להוסיף את הפעולה שנכשלה לתור כדי שנציג אנושי יבדוק אותה.
שגיאות שקשורות לסנכרון
באפליקציות רבות של Google Ads יש מסד נתונים מקומי שבו מאוחסנות האובייקטים שלהן ב-Google Ads. אחד האתגרים בגישה הזו הוא שמסד הנתונים המקומי לא מסונכרן עם האובייקטים בפועל ב-Google Ads. לדוגמה, משתמש עשוי למחוק קבוצת מודעות ישירות ב-Google Ads, אבל האפליקציה ומסד הנתונים המקומי לא מודעים לשינוי וממשיכים לבצע קריאות ל-API כאילו קבוצת המודעות קיימת. הבעיות בסנכרון יכולות לבטא מגוון שגיאות כמו DUPLICATE_CAMPAIGN_NAME, DUPLICATE_ADGROUP_NAME, AD_NOT_UNDER_ADGROUP, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD והרבה שגיאות אחרות.
כשמדובר בבקשות ביוזמת המשתמש, אחת השיטות היא להתריע בפני המשתמש על בעיה אפשרית בסנכרון, להפעיל מיד משימה שמאחזרת את המחלקה הרלוונטית של האובייקטים ב-Google Ads ומעדכנת את מסד הנתונים המקומי, ואז לבקש מהמשתמש לרענן את ממשק המשתמש.
בבקשות עורפיות, שגיאות מסוימות מספקות מספיק מידע כדי שהאפליקציה תוכל לתקן את מסד הנתונים המקומי באופן אוטומטי ומצטבר. לדוגמה, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD צריך לגרום לאפליקציה לסמן את המודעה כהוסרה במסד הנתונים המקומי. שגיאות שאי אפשר לטפל בהן בדרך הזו עלולות לגרום לאפליקציה להפעיל משימת סנכרון מלאה יותר או להתווסף לתור לבדיקה של מפעיל אנושי.