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