סרטון: שיטות מומלצות שהוצגו בסדנה של 2019
במדריך הזה מפורטות כמה שיטות מומלצות שאפשר ליישם כדי לשפר את היעילות והביצועים של האפליקציות.
תחזוקה שוטפת
כדי לוודא שהאפליקציה פועלת ללא הפרעות:
חשוב לוודא שכתובת האימייל של המפתח במרכז ה-API תמיד עדכנית. זהו הכינוי שבו אנחנו משתמשים כדי ליצור איתך קשר. אם לא נוכל ליצור איתך קשר בנוגע לעמידה בתנאים ובהגבלות של ה-API, יכול להיות שנבטל את הגישה שלך ל-API בלי ליידע אותך מראש. אל תשתמשו בכתובת אימייל אישית שמשויכת לחשבון פרטי או לחשבון לא מפוקח. כדי לראות את מרכז ה-API, צריך להתחבר לחשבון הניהול.
כדי לקבל מידע על בעיות כמו שינויים במוצרים, השבתה לצורך תחזוקה, תאריכי הוצאה משימוש וכו', אפשר להירשם ל
צוות Google Ads API עוקב אחרי הפורום באופן קבוע, ולכן זה המקום האידיאלי לפרסם בו שאלות לגבי ה-API.
- חשוב לוודא שהאפליקציה עומדת בתנאים ובהגבלות של Google Ads API. אם יהיה צורך בכך, צוות הבדיקה והתאימות של האסימון ייצור איתך קשר באמצעות כתובת האימייל שלך. אם יש לך שאלות או חששות לגבי התנאים וההגבלות, אפשר להשיב לאימייל שצוות הבדיקה שלח לך כשבדק את הבקשה שלך לטוקן מפתח כדי ליצור קשר עם הצוות.
אופטימיזציה
כדי לבצע אופטימיזציה של האפליקציה, אפשר להריץ פעולות בקבוצות, ואם מתאים, לשלוח אובייקטים דלילים.
פעולות אצווה
שליחת בקשה ל-API כרוכה במספר עלויות קבועות, כמו זמן האחזור של הרשת (round-trip), עיבוד של סדרות וביטול סדרות, וקריאות למערכות קצה עורפיות. כדי להקטין את ההשפעה של העלויות הקבועות האלה ולשפר את הביצועים הכוללים, רוב שיטות השינוי ב-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 בחשבונות ולהשוות אותם למסד הנתונים המקומי.
שגיאות ביומן
כדי להקל על ניפוי הבאגים והמעקב, צריך לרשום ביומן את כל השגיאות. לפחות, צריך לרשום ביומן את מזהה הבקשה, את הפעולות שגרמו לשגיאה ואת השגיאה עצמה. מידע נוסף שאפשר לרשום ביומן כולל מזהה לקוח, שירות API, זמן האחזור של בקשה הלוך ושוב, מספר הניסיונות החוזרים והבקשה והתגובה הגולמיות.
מעקב אחרי מגמות
חשוב לעקוב אחרי מגמות בשגיאות API כדי לזהות בעיות באפליקציה ולטפל בהן. אפשר ליצור פתרון משלכם או להשתמש באחד מהכלים המסחריים הרבים שזמינים, שיכולים להשתמש ביומנים שלכם כדי ליצור לוחות בקרה אינטראקטיביים ולשלוח התראות אוטומטיות.
פיתוח
מומלץ להשתמש בחשבונות בדיקה במהלך הפיתוח.
שימוש בחשבונות בדיקה
חשבונות בדיקה הם חשבונות Google Ads שלא מציגים מודעות בפועל. אתם יכולים להשתמש בחשבון בדיקה כדי להתנסות ב-Google Ads API ולבדוק שהקישוריות של האפליקציה, הלוגיקה של ניהול הקמפיינים או עיבודים אחרים פועלים כמצופה. אין צורך לקבל אישור לשימוש בקוד המפתח בחשבון בדיקה, כך שאפשר להתחיל לפתח באמצעות Google Ads API מיד אחרי שמבקשים קוד מפתח, עוד לפני שהאפליקציה נבדקת.