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