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