במדריך הזה מפורטות כמה שיטות מומלצות שאפשר ליישם כדי לשפר את היעילות והביצועים של האפליקציות.
תחזוקת האפליקציה
כדי לוודא שהאפליקציה תפעל ללא הפרעות, צריך:
חשוב לוודא שהרשימה של הבעלים והעורכים של הפרויקט ב-Google Cloud מעודכנת. ניצור קשר עם המשתמשים האלה במקרה של מצבי חירום או בנושאים שקשורים לתאימות לתנאים ולהגבלות של ה-API. אם לא נוכל ליצור איתך קשר בנוגע לתאימות לתנאים ולהגבלות של ה-API, יכול להיות שנשנמך את רמת הגישה שלך ל-API או נבטל אותה.
כדי לקבל מידע על בעיות כמו שינויים במוצרים, השבתה לצורך תחזוקה ותאריכי הוצאה משימוש, מומלץ להירשם לבלוג בנושא API ולבלוג בנושא מוצרים.
חשוב לוודא שהאפליקציה שלכם עומדת בדרישות התנאים וההגבלות של Google Ads API. במקרה הצורך, צוות התאימות ל-API יפנה לבעלים ולעורכים של הפרויקט שלכם ב-Google Cloud עם גישה ל-API. אם יש לכם שאלות או חששות לגבי התנאים וההגבלות, אתם יכולים להשיב לאימייל שצוות התאימות שלח לכם כשבדק את הבקשה שלכם לגישה ל-API.
אופטימיזציה
כדי לבצע אופטימיזציה של האפליקציה, אפשר להריץ פעולות אצווה, ואם מתאים, לשלוח אובייקטים דלילים.
פעולות אצווה
שליחת בקשה ל-API כרוכה במספר עלויות קבועות, כמו זמן האחזור של הרשת הלוך ושוב, עיבוד של סריאליזציה ודה-סריאליזציה וקריאות למערכות backend. כדי לצמצם את ההשפעה של העלויות הקבועות האלה ולשפר את הביצועים הכוללים, רוב שיטות המוטציה ב-API מיועדות לקבל מערך של פעולות. על ידי איגוד של כמה פעולות בכל בקשה, אפשר לצמצם את מספר הבקשות שאתם שולחים ואת העלויות הקבועות שמשויכות להן. אם אפשר, כדאי להימנע משליחת בקשות עם פעולה אחת בלבד.
לדוגמה, נניח שאתם מוסיפים 50,000 מילות מפתח לקמפיין בכמה קבוצות של מודעות. במקום לשלוח 50,000 בקשות עם מילת מפתח אחת בכל בקשה, אפשר לשלוח 100 בקשות עם 500 מילות מפתח בכל בקשה, או אפילו 10 בקשות עם 5,000 מילות מפתח בכל בקשה. יש מגבלות על מספר הפעולות שמותרות בבקשה, ולכן יכול להיות שתצטרכו לשנות את גודל האצווה כדי להשיג ביצועים אופטימליים.
שליחת אובייקטים דלילים
כששולחים אובייקטים ל-API, צריך לבצע דה-סריאליזציה של השדות, לאמת אותם ולאחסן אותם במסד הנתונים. העברת אובייקטים מלאים כשרוצים לעדכן רק כמה שדות עלולה להוביל לזמן עיבוד נוסף ולפגיעה בביצועים. כדי לפתור את הבעיה הזו, Google Ads API תומך בעדכונים דלילים, שמאפשרים לכם לאכלס רק את השדות באובייקט שאתם צריכים לשנות או שנדרשים.
עדכונים דלילים מעובדים מהר יותר ופחות סביר שיגרמו לשגיאות. שדות שלא נמצאים ב-update_mask (שנקרא גם FieldMask) לא משתנים.
לדוגמה, אפליקציה שמעדכנת הצעות מחיר ברמת מילת המפתח יכולה להפיק תועלת משימוש בעדכונים חלקיים, כי רק השדות של מזהה קבוצת המודעות, מזהה הקריטריון והצעות המחיר צריכים להיות מאוכלסים.
טיפול בשגיאות וניהול שלהן
במהלך הפיתוח, סביר להניח שתיתקלו בשגיאות. בקטע הזה מפורטים שיקולים ואסטרטגיות לשילוב של ניהול שגיאות באפליקציה. בנוסף לקטע הזה, אפשר לעיין במדריך לפתרון בעיות כדי לקבל מידע נוסף על ניהול שגיאות.
הבחנה בין מקורות הבקשות
חלק מהאפליקציות הן אינטראקטיביות בעיקר, והן שולחות קריאות ל-API ישירות בתגובה לפעולות שהמשתמשים מבצעים בממשק המשתמש. אחרים פועלים בעיקר במצב אופליין, ושולחים קריאות ל-API כחלק מתהליך תקופתי של קצה עורפי. הרבה אפליקציות משלבות בין השניים. כשחושבים על ניהול שגיאות, כדאי להבחין בין סוגי הבקשות השונים האלה.
במקרה של בקשות שהמשתמשים יזמו, הדאגה העיקרית שלכם צריכה להיות לספק חוויה טובה למשתמשים. כדאי להשתמש בשגיאה הספציפית שהתרחשה כדי לספק למשתמש כמה שיותר הקשר בממשק המשתמש. לספק שלבים ברורים לפתרון השגיאה (ראו את ההצעות הבאות).
עבור בקשות שמופעלות בשרת העורפי, צריך להטמיע פונקציות לטיפול בסוגים השונים של שגיאות שהאפליקציה עלולה להיתקל בהן. חשוב תמיד לכלול handler שמוגדר כברירת מחדל כדי לטפל בשגיאות נדירות או בשגיאות שלא נתקלתם בהן בעבר. גישה טובה לטיפול בשגיאות שמתרחשות כברירת מחדל היא להוסיף את הפעולה שנכשלה ואת השגיאה לתור, כדי שאופרטור אנושי יבדוק אותן ויקבע פתרון מתאים.
הבחנה בין סוגי שגיאות
חשוב להכיר את ההבדלים בין סוגי השגיאות ב-Google Ads API כשמפתחים טיפול אמין בשגיאות. כמה מסוגי השגיאות הנפוצים ביותר:
פרטים נוספים זמינים במאמרים בנושא סוגי שגיאות ושגיאות נפוצות.
סנכרון של קצה העורף
אם למשתמשים באפליקציה שלכם יש גישה ידנית לחשבונות Google Ads, הם עשויים לבצע שינויים שהאפליקציה לא מודעת להם, ולגרום למסד הנתונים המקומי של האפליקציה לצאת מסינכרון. כמו שצוין במדריך סוגי שגיאות, אפשר לטפל בשגיאות שקשורות לסנכרון באופן תגובתי כשהן מתרחשות, אבל אפשר גם לנסות למנוע אותן באופן יזום. אחת מהאסטרטגיות הפרואקטיביות היא להפעיל משימת סנכרון תקופתית כדי להשוות בין מסד הנתונים המקומי לבין אובייקטים של Google Ads בחשבונות שלכם. במבני חשבונות גדולים, כדי לא לחרוג מהמכסות היומיות, מומלץ לא לשלוף את כל האובייקטים מכל החשבונות מדי לילה. במקום זאת, אפשר להריץ שאילתה על ChangeStatus או לסנן ישויות שהשתנו לאחרונה כדי לסנכרן את השינויים באופן מצטבר.
שגיאות ביומן
כדי לאפשר ניפוי באגים ומעקב, צריך לרשום ביומן את כל השגיאות. לפחות, צריך לרשום ביומן את מזהה הבקשה, את הפעולות שגרמו לשגיאה ואת השגיאה עצמה. מידע נוסף שצריך לרשום ביומן כולל את מזהה הלקוח, שירות ה-API, זמן האחזור של הבקשה (round-trip), מספר הניסיונות החוזרים והבקשה והתשובה הגולמיות שעברו סניטציה (חשוב להקפיד להסתיר פרטי כניסה רגישים כמו טוקנים של OAuth, טוקנים של מפתחים אם הם עדיין כלולים בכותרות של בקשות מדור קודם וכל פרט מידע אישי).
מעקב אחרי מגמות
חשוב לעקוב אחרי מגמות בשגיאות API כדי לזהות בעיות באפליקציה ולטפל בהן. אפשר ליצור פתרון משלכם או להשתמש באחד מהכלים המסחריים הרבים שזמינים, שיכולים להשתמש ביומנים שלכם כדי ליצור לוחות בקרה אינטראקטיביים ולשלוח התראות אוטומטיות.
פיתוח
מומלץ להשתמש בחשבונות בדיקה במהלך הפיתוח.
שימוש בחשבונות בדיקה
חשבונות בדיקה הם חשבונות Google Ads שלא מציגים בפועל מודעות. אתם יכולים להשתמש בחשבון בדיקה כדי להתנסות ב-Google Ads API ולבדוק שהקישוריות של האפליקציה, הלוגיקה של ניהול הקמפיינים או עיבודים אחרים פועלים כמו שצריך. כדי להשתמש בפרויקט בענן ב-Google Cloud בחשבון בדיקה, צריך רק גישת בדיקה. כך תוכלו להתחיל לפתח באמצעות Google Ads API באופן מיידי, בזמן שאתם מחכים ש-Google תבדוק את הבקשה שלכם לרמות גישה גבוהות יותר ל-API.