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