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