במדריך הזה מפורטות כמה שיטות מומלצות שאפשר ליישם כדי לשפר את היעילות והביצועים של האפליקציות.
תחזוקת האפליקציה
כדי לוודא שהאפליקציה תפעל ללא הפרעות, צריך:
חשוב לוודא שרשימת הבעלים והעורכים של הפרויקט ב-Google Cloud מעודכנת. ניצור קשר עם המשתמשים האלה במקרה של מצבי חירום או בנושאים שקשורים לתאימות לתנאים ולהגבלות של ה-API. אם לא נצליח ליצור איתכם קשר בנוגע לעמידה בתנאים ובהגבלות של ה-API, יכול להיות שנשנמך או נבטל את הגישה שלכם ל-API.
כדי לקבל עדכונים על בעיות כמו שינויים במוצר, זמני השבתה לצורך תחזוקה ותאריכי הוצאה משימוש, הירשמו לבלוג ה-API ולבלוג המוצר שלנו.
חשוב לוודא שהאפליקציה עומדת בתנאים ובהגבלות של Google Ads API. אם יהיה צורך, צוות התאימות של ה-API יפנה לבעלים ולעורכים של הפרויקט ב-Google Cloud שיש להם גישה ל-API. אם יש לכם שאלות או חששות לגבי התנאים וההגבלות, אתם יכולים לפנות לצוות התאימות. כדי לעשות את זה, אתם צריכים להשיב לאימייל שהם שלחו לכם כשהם בדקו את הבקשה שלכם לגישה ל-API.
אופטימיזציה
כדי לבצע אופטימיזציה של האפליקציה, אפשר להריץ פעולות אצווה, ואם מתאים, לשלוח אובייקטים דלילים.
פעולות אצווה
שליחת בקשה ל-API כרוכה במספר עלויות קבועות, כמו זמן האחזור של הרשת הלוך ושוב, עיבוד של סריאליזציה ודה-סריאליזציה וקריאות למערכות עורפיות. כדי לצמצם את ההשפעה של העלויות הקבועות האלה ולשפר את הביצועים הכוללים, רוב שיטות ה-mutate ב-API מיועדות לקבל מערך של פעולות. אם תקבצו כמה פעולות בכל בקשה, תוכלו לצמצם את מספר הבקשות שאתם שולחים ואת העלויות הקבועות שמשויכות אליהן. אם אפשר, כדאי להימנע מבקשות עם פעולה אחת בלבד.
לדוגמה, נניח שאתם מוסיפים 50,000 מילות מפתח לקמפיין בכמה קבוצות של מודעות. במקום לשלוח 50,000 בקשות עם מילת מפתח אחת בכל בקשה, שלחו 100 בקשות עם 500 מילות מפתח בכל בקשה, או אפילו 10 בקשות עם 5,000 מילות מפתח בכל בקשה. יש מגבלות על מספר הפעולות שמותרות בבקשה, ולכן יכול להיות שתצטרכו לשנות את גודל האצווה כדי להשיג ביצועים אופטימליים.
שליחת אובייקטים חסכוניים (sparse)
כששולחים אובייקטים ל-API, צריך לבצע דה-סריאליזציה של השדות, לאמת אותם ולאחסן אותם במסד הנתונים. העברת אובייקטים מלאים כשרוצים לעדכן רק כמה שדות עלולה להוביל לזמן עיבוד נוסף ולפגיעה בביצועים. כדי לפתור את הבעיה הזו, Google Ads API תומך בעדכונים חלקיים, ומאפשר לכם לאכלס רק את השדות באובייקט שאתם צריכים לשנות או שנדרשים.
עדכונים חלקיים מעובדים מהר יותר ויש פחות סיכוי שהם יגרמו לשגיאות. שדות שלא נמצאים ב-update_mask (שנקרא גם FieldMask) לא משתנים.
לדוגמה, אפליקציה שמעדכנת הצעות מחיר ברמת מילת המפתח יכולה להפיק תועלת משימוש בעדכונים חלקיים, כי רק השדות של מזהה קבוצת המודעות, מזהה הקריטריון והצעות המחיר צריכים להיות מאוכלסים.
טיפול בשגיאות וניהול שגיאות
במהלך הפיתוח, סביר להניח שתיתקלו בשגיאות. בקטע הזה מפורטים שיקולים ואסטרטגיות לשילוב של ניהול שגיאות באפליקציה. בנוסף לקטע הזה, אפשר לעיין במדריך לפתרון בעיות לקבלת מידע נוסף על ניהול שגיאות.
הבחנה בין מקורות של בקשות
חלק מהאפליקציות הן אינטראקטיביות בעיקר, והן שולחות קריאות ל-API ישירות בתגובה לפעולות שהמשתמשים מבצעים בממשק המשתמש. אחרים עובדים בעיקר במצב אופליין, ושולחים קריאות ל-API כחלק מתהליך תקופתי בבק-אנד. באפליקציות רבות משלבים בין שתי האפשרויות. כשחושבים על ניהול שגיאות, כדאי להבחין בין סוגי הבקשות השונים האלה.
בבקשות שמופעלות על ידי משתמשים, הדבר הכי חשוב הוא לספק חוויית משתמש טובה. כדאי להשתמש בשגיאה הספציפית שהתרחשה כדי לספק למשתמש כמה שיותר הקשר בממשק המשתמש. לספק שלבים ברורים לפתרון השגיאה (ראו את ההצעות הבאות).
עבור בקשות שמופעלות בשרת העורפי, צריך להטמיע אמצעי טיפול בסוגים השונים של שגיאות שהאפליקציה עלולה להיתקל בהן. תמיד צריך לכלול handler שמוגדר כברירת מחדל כדי לטפל בשגיאות נדירות או בשגיאות שלא נתקלתם בהן בעבר. גישה טובה לטיפול בשגיאות שמתרחשות כברירת מחדל היא להוסיף את הפעולה שנכשלה ואת השגיאה לתור, כדי שאופרטור אנושי יבדוק אותן ויקבע פתרון מתאים.
הבחנה בין סוגי שגיאות
כשמפתחים טיפול חזק בשגיאות, חשוב להכיר את ההבדלים בין סוגי השגיאות ב-Google Ads API. אלה כמה מסוגי השגיאות הנפוצים ביותר:
לפרטים נוספים, אפשר לעיין בקטעים סוגי שגיאות ושגיאות נפוצות.
סנכרון של קצוות עורפיים
אם למשתמשים באפליקציה יש גישה ידנית לחשבונות Google Ads, הם יכולים לבצע שינויים שהאפליקציה לא מודעת אליהם, וכתוצאה מכך מסד הנתונים המקומי של האפליקציה לא יהיה מסונכרן. כמו שצוין במדריך סוגי שגיאות, אתם יכולים לטפל בשגיאות שקשורות לסנכרון באופן תגובתי כשהן מתרחשות, אבל אתם יכולים גם לנסות למנוע אותן באופן יזום. אסטרטגיה פרואקטיבית אחת היא להפעיל משימת סנכרון תקופתית כדי להתאים בין מסד הנתונים המקומי לבין האובייקטים של Google Ads בחשבונות שלכם. במבני חשבונות גדולים, כדי לא לחרוג מהמכסות היומיות, מומלץ לא לשלוף את כל האובייקטים מכל חשבון מדי לילה. במקום זאת, אפשר להריץ שאילתה על ChangeStatus או לסנן לפי ישויות ששונו לאחרונה כדי לסנכרן את השינויים באופן מצטבר.
שגיאות ביומן
כדי להקל על ניפוי הבאגים והמעקב, צריך לתעד את כל השגיאות ביומן. לפחות, צריך לרשום ביומן את מזהה הבקשה, את הפעולות שגרמו לשגיאה ואת השגיאה עצמה. מידע נוסף שכדאי לרשום ביומן כולל את מזהה הלקוח, שירות ה-API, זמן האחזור של הבקשה (round-trip), מספר הניסיונות החוזרים והבקשה והתגובה הגולמיות שעברו סניטציה (חשוב להקפיד להסתיר פרטי כניסה רגישים כמו אסימוני OAuth ופרטים אישיים מזהים).
מעקב אחרי מגמות
חשוב לעקוב אחרי מגמות בשגיאות ב-API כדי לזהות בעיות באפליקציה ולטפל בהן. כדאי לפתח פתרון משלכם או להשתמש באחד מהכלים המסחריים הרבים שזמינים, שיכולים להשתמש ביומנים שלכם כדי ליצור לוחות בקרה אינטראקטיביים ולשלוח התראות אוטומטיות.
פיתוח
השתמשו בחשבונות בדיקה במהלך הפיתוח.
שימוש בחשבונות בדיקה
חשבונות בדיקה הם חשבונות Google Ads שלא מוצגות בהם מודעות בפועל. אתם יכולים להשתמש בחשבון בדיקה כדי להתנסות ב-Google Ads API ולבדוק שהקישוריות של האפליקציה, הלוגיקה של ניהול הקמפיינים או תהליכים אחרים פועלים כמו שצריך. כדי להשתמש בפרויקט בענן של Google בחשבון בדיקה, צריך רק גישת בדיקה. כך תוכלו להתחיל לפתח באמצעות Google Ads API באופן מיידי, בזמן שאתם ממתינים ש-Google תבדוק את הבקשה שלכם לרמות גישה גבוהות יותר ל-API.