סרטון: שיחה על שיטות מומלצות מהסדנה של 2019
במדריך הזה מפורטות כמה שיטות מומלצות שאפשר ליישם כדי לשפר את היעילות ואת הביצועים של האפליקציות.
תחזוקה שוטפת
כדי להבטיח שהאפליקציה תפעל ללא הפרעה:
חשוב לוודא שכתובת האימייל ליצירת קשר עם המפתח במרכז ממשק ה-API תמיד עדכנית. זהו הכינוי שבו נשתמש כדי ליצור איתך קשר. אם לא נצליח ליצור איתכם קשר בנוגע לעמידה בתנאים ובהגבלות של ה-API, יכול להיות שנסיר את הגישה שלכם ל-API ללא הודעה מוקדמת. הימנעו משימוש בכתובת אימייל אישית שמקושרת לחשבון פרטי או לחשבון לא במעקב. כדי להציג את מרכז ה-API, צריך להיות מחוברים לחשבון הניהול.
כדי לקבל עדכונים על בעיות כמו שינויים במוצרים, זמן השבתה לתחזוקה, תאריכי הוצאה משימוש וכו', כדאי להירשם לניוזלטר שלנו.
הצוות של Google Ads API עוקב אחרי הפורום באופן קבוע, כך שזהו המקום האידיאלי לפרסם בו שאלות בנושא API.
- חשוב לוודא שהאפליקציה עומדת בתנאים ובהגבלות (T&C) של Google Ads API. אם יהיה צורך, צוות בדיקת האסימונים ותאימות ייצור איתכם קשר באמצעות כתובת האימייל ליצירת קשר. אם יש לכם שאלות או חששות לגבי התנאים וההגבלות, תוכלו לפנות לצוות הבדיקה על ידי מענה לאימייל שנשלח אליכם במהלך בדיקת הבקשה שלכם לקבלת אסימון למפתחים.
אופטימיזציה
כדי לבצע אופטימיזציה של האפליקציה, אפשר להריץ פעולות באצווה, ואם הדבר רלוונטי, לשלוח אובייקטים דלילים.
פעולות אצווה
שליחת בקשה ל-API כרוכה במספר עלויות קבועות, כמו זמן אחזור הלוך ושוב ברשת, עיבוד שרשור (serialization) וביטול שרשור (deserialization) וקריאות למערכות בקצה העורפי. כדי לצמצם את ההשפעה של העלויות הקבועות האלה ולשפר את הביצועים הכוללים, רוב השיטות של שינוי ב-API תוכננו לקבל מערך של פעולות. אם תקבצו כמה פעולות בכל בקשה, תוכלו לצמצם את מספר הבקשות שתשלחו ואת העלויות הקבועות המשויכות אליהן. אם אפשר, כדאי להימנע משליחת בקשות עם פעולה אחת בלבד.
לדוגמה, נניח שאתם מוסיפים 50,000 מילות מפתח לקמפיין במספר קבוצות של מודעות. במקום לשלוח 50,000 בקשות עם מילת מפתח אחת בכל אחת, כדאי לשלוח 100 בקשות עם 500 מילות מפתח בכל אחת, או אפילו 10 בקשות עם 5,000 מילות מפתח בכל אחת. יש מגבלות על מספר הפעולות שמותר לבצע בבקשה, לכן יכול להיות שתצטרכו לשנות את גודל האצווה כדי להשיג ביצועים אופטימליים.
שליחת אובייקטים דלילים
כששולחים אובייקטים ל-API, צריך לבצע סריאליזציה לאחור של השדות, לאמת אותם ולאחסן אותם במסד הנתונים. העברת אובייקטים מלאים כשרוצים לעדכן רק כמה שדות עלולה להוביל לזמן עיבוד ארוך יותר ולפגיעה בביצועים.
כדי לצמצם את הבעיה הזו, Google Ads API תומך בעדכונים דלילים, שמאפשרים לאכלס רק את השדות באובייקט שצריך לשנות או שדרושים. עדכונים דלילים עוברים עיבוד מהר יותר, ויש פחות סיכוי שיגרמו לשגיאות.
שדות שלא נמצאים ב-update_mask (שנקרא גם FieldMask) לא משתנים.
לדוגמה, אפליקציה שמעדכנת הצעות מחיר ברמת מילת המפתח יכולה להפיק תועלת משימוש בעדכונים דלילים, כי צריך לאכלס רק את השדות של מזהה קבוצת המודעות, מזהה הקריטריון והצעות המחיר.
טיפול בשגיאות וניהול שלהן
במהלך הפיתוח, סביר להניח שתתקלו בשגיאות. בקטע הזה מתוארים שיקולים ואסטרטגיות להטמעת ניהול שגיאות באפליקציה. בנוסף לקטע הזה, אפשר לעיין במדריך לפתרון בעיות כדי לקבל מידע נוסף על ניהול שגיאות.
הבחנה בין מקורות הבקשות
חלק מהאפליקציות הן בעיקר אינטראקטיביות, והן מריצות קריאות ל-API ישירות בתגובה לפעולות שהמשתמשים מפעילים בממשק המשתמש. אחרים פועלים בעיקר אופליין, ומפעילים קריאות API כחלק מתהליך קצה עורפי תקופתי. הרבה אפליקציות משלבות בין השניים. כשמדברים על ניהול שגיאות, כדאי להבחין בין הסוגים השונים של הבקשות.
בבקשות שמשתמשים מתחילים, הדאגה העיקרית שלכם צריכה להיות לספק חוויה טובה למשתמשים. כדאי להשתמש בשגיאה הספציפית שהתרחשה כדי לספק למשתמש כמה שיותר הקשר בממשק המשתמש. מציעים שלבים פשוטים שאפשר לבצע כדי לפתור את השגיאה (אפשר לעיין בהצעות שבהמשך).
לבקשות שמתחילות בקצה העורפי, מטמיעים מנהלים לסוגים השונים של השגיאות שהאפליקציה עשויה להיתקל בהן. תמיד צריך לכלול טיפול כברירת מחדל כדי לטפל בשגיאות נדירות או בשגיאות שלא נתקלת בהן בעבר. גישה טובה לטיפול שמוגדר כברירת מחדל היא להוסיף את הפעולה והשגיאה שנכשלו לתור, כדי שמפעיל אנושי יוכל לבדוק אותן ולהחליט איך לטפל בהן.
הבחנה בין סוגי שגיאות
חשוב להכיר את ההבדלים בין סוגי השגיאות ב-Google Ads API כדי ליצור טיפול יעיל בשגיאות. חלק מסוגי השגיאות הנפוצים ביותר הם:
פרטים נוספים זמינים במאמרים סוגי שגיאות ושגיאות נפוצות.
סנכרון הקצוות העורפיים
אם למשתמשים באפליקציה יש גישה ידנית לחשבונות Google Ads, הם עשויים לבצע שינויים שלא ידועים לאפליקציה, וכתוצאה מכך מסד הנתונים המקומי של האפליקציה לא יסתנכרן. כפי שצוין במדריך שלנו בנושא סוגים של שגיאות, אפשר לטפל בשגיאות שקשורות לסנכרון באופן תגובתי כשהן מתרחשות, אבל אפשר גם לנסות למנוע אותן באופן יזום. אחת מהאסטרטגיות היזום היא להריץ בכל לילה משימה לסנכרון של כל החשבונות, לאחזר את האובייקטים של Google Ads בחשבונות ולהשוות אותם למסד הנתונים המקומי.
רישום שגיאות ביומן
כדי לאפשר ניפוי באגים ומעקב, צריך לרשום ביומן את כל השגיאות. לכל הפחות, צריך לתעד ביומן את מזהה הבקשה, את הפעולות שגרמו לשגיאה ואת השגיאה עצמה. מידע נוסף שצריך לתעד ביומן כולל מזהה לקוח, שירות API, זמן אחזור של בקשה הלוך ושוב, מספר הניסיונות החוזרים והבקשה והתגובה הגולמיות.
מעקב אחר מגמות
חשוב לעקוב אחרי מגמות בשגיאות API כדי לזהות בעיות באפליקציה ולטפל בהן. כדאי לפתח פתרון משלכם או להשתמש באחד מהכלים המסחריים הרבים שזמינים, שיכולים להשתמש ביומנים שלכם כדי ליצור לוחות בקרה אינטראקטיביים ולשלוח התראות אוטומטיות.
פיתוח
שימוש בחשבונות בדיקה במהלך הפיתוח.
שימוש בחשבונות בדיקה
חשבונות בדיקה הם חשבונות Google Ads שלא מציגים בפועל מודעות. אפשר להשתמש בחשבון בדיקה כדי להתנסות ב-Google Ads API ולבדוק שהקישוריות של האפליקציה, הלוגיקה לניהול הקמפיינים או עיבוד אחר פועלים כצפוי. אין צורך לאשר את קוד המפתח כדי להשתמש בו בחשבון לבדיקה, כך שתוכלו להתחיל לפתח באמצעות Google Ads API מיד אחרי ששולחים בקשה לקבלת קוד מפתח, גם לפני שהאפליקציה נבדקת.