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