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