הבדיקה היא שלב חשוב ביצירת שילוב מוצלח של Google Ads API, בין אם אתם רק מתחילים, מתחזקים אפליקציה או מוסיפים תכונות חדשות לשילוב קיים. במדריך הזה מוצגות כמה שיטות מומלצות לבדיקת השילוב של Google Ads API.
חשבונות בדיקה וחשבונות פעילים
חשבונות בדיקה זמינים למטרות פיתוח. באמצעות חשבונות בדיקה, אתם יכולים לוודא שקוד האפליקציה וההגדרות פועלים כמו שצריך.
עם זאת, לא את כל התכונות אפשר לבדוק בחשבון בדיקה.
אם המגבלות של חשבון הבדיקה מונעות מכם לבדוק תכונות מסוימות בשילוב, אתם יכולים להשתמש בחשבון בסביבת הייצור לצורך הפיתוח. כדי לשלוח קריאה לחשבון בסביבת הייצור, לפרויקט בענן של Google צריכה להיות לפחות רמת גישה של Explorer (Explorer, Basic או Standard). חשוב לזכור שגישת Explorer עדיין מגבילה שירותים מסוימים, כולל חיוב (BillingSetupService ו-AccountBudgetProposalService), תכנון, יצירת חשבונות והזמנות של משתמשים (ראו הגבלות על תכונות Explorer), שדורשים גישה בסיסית או רגילה. ניסיון לשלוח קריאה לחשבון בסביבת הייצור מפרויקט עם רמת גישה לבדיקה מחזיר את השגיאה AuthorizationError.CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION החל מ-v25, או את השגיאה AuthorizationError.ACTION_NOT_PERMITTED ב-v24 ולפני כן.
חשבונות ייצור לפיתוח שונים מחשבונות בדיקה בדרכים הבאות:
- הצגת מודעות שהמשתמשים יכולים לראות
- דרישה לכתובות URL תקינות
- לעמוד בדרישות של מדיניות הפרסום
בחשבונות פעילים מוצגות מודעות, ולכן הם יוצרים מדדים שמאפשרים לכם לבדוק דוחות ביצועים, וגם פותחים את כל התכונות האחרות של Google Ads API. עם זאת, צריך להיזהר כשמשתמשים בהם לפיתוח. מומלץ לבצע את הפעולות הבאות:
- מומלץ לתת גישה רק למשתמשים שצריכים אותה למטרות פיתוח.
- מגדירים תקציב יומי קבוע ונמוך לחשבון.
- השתמשו בחשבונות ייצור לצורכי פיתוח רק כשאי אפשר להשתמש בחשבונות בדיקה.
לכן, כדי לבצע בדיקה מלאה של השילוב, סביר להניח שתצטרכו גם פרטי כניסה לבדיקה וגם פרטי כניסה לסביבת הייצור.
פרטי הכניסה למטרת הבדיקה
כדי לצמצם את הסיכון לשינוי בטעות של חשבונות בסביבת הייצור כשמנסים לשנות חשבונות בסביבת הפיתוח, מומלץ להחזיק קבוצה של פרטי כניסה לבדיקה, בנפרד מפרטי הכניסה של האפליקציה בסביבת הייצור.
כדי ליצור קבוצה של פרטי כניסה לבדיקה:
- יוצרים חשבון אימייל (לדוגמה,
api.test@example.com) או חשבון שירות שישמשו רק למטרות בדיקה. - הוסיפו את המשתמש או את חשבון השירות הזה כמשתמש חוקי בחשבונות Google Ads שבהם אתם מריצים את הבדיקות. חשוב לוודא שאתם נותנים את רמות הגישה המתאימות לחשבון המשתמש או לחשבון השירות. אל תתנו למשתמש או לחשבון השירות הזה גישה לחשבונות ייצור.
- אם אתם משתמשים בתהליך אימות המשתמשים של OAuth 2.0, ולא בתהליך של חשבון השירות, אתם צריכים ליצור טוקן רענון לחשבון המשתמש לבדיקה.
- השתמשו בפרטי הכניסה החדשים האלה כשאתם בודקים את האפליקציה. אפשר להשתמש שוב במזהה הלקוח ובסוד הלקוח למטרות בדיקה, כי הם לא משפיעים על קביעת החשבונות ב-Google Ads שאפשר לגשת אליהם. חשוב לאחסן את כל פרטי הכניסה וטוקני הרענון באופן מאובטח, ואף פעם לא לשמור אותם במערכות לניהול גרסאות.
בקש אימות
אם אתם רק צריכים לבדוק אם בקשה תקינה – לדוגמה, כדי לוודא שהבקשה בנויה נכון ולא מפרה את המדיניות – אתם יכולים להשתמש בשדה validate_only, שזמין לבקשות GoogleAdsService.Search (שימו לב ש-GoogleAdsService.SearchStream לא תומך ב-validate_only) ולרוב הבקשות לשינוי נתונים. כדי לבדוק אם השדה הזה זמין לשיטה מסוימת, אפשר לעיין במאמרי העזרה.
API בארכיטקטורת REST
לבדיקות אד-הוק, למשל כדי לוודא שבקשה מניבה את הפלט הצפוי, השימוש ב-API בארכיטקטורת REST הוא בדרך כלל האפשרות הקלה ביותר. בדוגמאות ל-REST מוסבר איך להשתמש ב-curl כדי לשלוח בקשות ל-API בארכיטקטורת REST. אפשר גם לנסות לבדוק ב-REST explorer.