מעקב אחרי ניתוחים של נתונים אופליין

משתמשים ב-Google Ads API כדי לאחזר אבחון של נתוני אופליין, שמכיל מידע על התקינות הכוללת של תהליכי ייבוא ההמרות והתאמות.

כדי לאחזר את נתוני האבחון העדכניים של נתוני אופליין בחשבון, אפשר להשתמש באחד מהמקורות הבאים:

• ‫offline_conversion_upload_client_summary מציג סיכום של נתוני האבחון של הייבוא ברמת החשבון.
• ‫offline_conversion_upload_conversion_action_summary מציג אבחון מצטבר של ייבוא ברמת פעולת ההמרה.

אבחון ברמת החשבון

כדי לאחזר נתוני אבחון של העלאת המרות ברמת החשבון, משתמשים בשאילתת GAQL הבאה:

SELECT
  customer.id,
  offline_conversion_upload_client_summary.alerts,
  offline_conversion_upload_client_summary.client,
  offline_conversion_upload_client_summary.daily_summaries,
  offline_conversion_upload_client_summary.job_summaries,
  offline_conversion_upload_client_summary.last_upload_date_time,
  offline_conversion_upload_client_summary.pending_event_count,
  offline_conversion_upload_client_summary.pending_rate,
  offline_conversion_upload_client_summary.status,
  offline_conversion_upload_client_summary.success_rate,
  offline_conversion_upload_client_summary.successful_event_count,
  offline_conversion_upload_client_summary.total_event_count
FROM offline_conversion_upload_client_summary

השאילתה הזו מחזירה שורות נפרדות של OfflineConversionUploadClientSummary לכל סוג של לקוח שנעשה בו שימוש בייבוא האחרון. לדוגמה, אם ייבאתם לאחרונה באמצעות Google Ads API וממשק המשתמש של Google Ads, התוצאות יכללו רשומות נפרדות לערכים client של GOOGLE_ADS_API ושל GOOGLE_ADS_WEB_CLIENT.

אבחון ברמת פעולת ההמרה

כדי לאחזר נתוני אבחון של העלאת המרות ברמה של פעולת ההמרה, משתמשים בשאילתת GAQL הבאה:

SELECT
  offline_conversion_upload_conversion_action_summary.conversion_action_name,
  offline_conversion_upload_conversion_action_summary.alerts,
  offline_conversion_upload_conversion_action_summary.client,
  offline_conversion_upload_conversion_action_summary.daily_summaries,
  offline_conversion_upload_conversion_action_summary.job_summaries,
  offline_conversion_upload_conversion_action_summary.last_upload_date_time,
  offline_conversion_upload_conversion_action_summary.pending_event_count,
  offline_conversion_upload_conversion_action_summary.status,
  offline_conversion_upload_conversion_action_summary.successful_event_count,
  offline_conversion_upload_conversion_action_summary.total_event_count
FROM offline_conversion_upload_conversion_action_summary
WHERE offline_conversion_upload_conversion_action_summary.conversion_action_id = < INSERT CONVERSION ACTION ID >

בדומה לניתוח הנתונים ברמת החשבון, השאילתה הזו מחזירה שורות נפרדות של OfflineConversionUploadConversionActionSummary לכל סוג של לקוח שנעשה בו שימוש בייבוא האחרון. לדוגמה, אם ייבאתם לאחרונה באמצעות Google Ads API וממשק המשתמש של Google Ads, התוצאות יכללו רשומות נפרדות לערכים client של GOOGLE_ADS_API ושל GOOGLE_ADS_WEB_CLIENT.

איך לפרש את הסיכומים האלה

לכל OfflineConversionUploadClientSummary או OfflineConversionUploadConversionActionSummary יש שדה status שמשקף את התקינות הכוללת של הייבוא עבור client. היא מכילה גם את הפרטים הבאים:

• המספר הכולל של האירועים שהתקבלו.
• מספר האירועים שעברו עיבוד בהצלחה.
• מספר האירועים בהמתנה (אירועים שעדיין נמצאים בתהליך עיבוד).
• שדה alerts, שמספק סיכום של השגיאות, מקובצות לפי OfflineConversionError.

כל השדות האלה מכילים מידע מהייבוא האחרון של יום מלא ביומן. המידע הזה יעזור לכם להעריך את תקינות הייבוא הנוכחי.

בנוסף, כל OfflineConversionUploadClientSummary או OfflineConversionUploadConversionActionSummary מכיל שני סוגים שונים של דוחות:

daily_summaries

A successful_count, failed_count, and pending_count of import requests from the last 7 days, grouped by import date.

job_summaries

הנתונים successful_count, failed_count ו-pending_count של 7 בקשות הייבוא האחרונות ביותר, מקובצים לפי job_id. ‫job_id הוא שדה אופציונלי של UploadClickConversionsRequest ושל UploadConversionAdjustmentsRequest. אתם יכולים להגדיר את הערך של job_id למספר לא שלילי שקטן מ-2^31, או לאפשר ל-Google Ads API להקצות מזהה עבודה שנוצר על ידי המערכת לבקשה שלכם. לא משנה באיזו אפשרות תבחרו, הפונקציה UploadClickConversionsResponse או UploadConversionAdjustmentsResponse מחזירה את הערך job_id.

תרחיש שבו כדאי להקצות job_id משלכם הוא כשמבצעים עבודה או תהליך אחד שמייבא מספר גדול של המרות באמצעות כמה בקשות. אם מגדירים את job_id בכל אחת מהבקשות האלה לאותו ערך, אפשר לאחזר רשומה אחת של העבודה מ-job_summaries. אם במקום זאת תאפשרו ל-Google Ads API להקצות ערך שנוצר על ידי המערכת לפרמטר job_id של כל בקשה, הפרמטר job_summaries יכיל רשומה נפרדת לכל בקשה, מה שיקשה על ניתוח המצב הכללי של העבודה.

איך משתמשים בסיכומים

כדי לוודא שתהליכי הייבוא מתעדים המרות ושיפורים כמו שצריך, כדאי לאחזר את הסיכומים של כל אחד מהחשבונות שלכם מדי פעם. אם הערך של status בסיכום כלשהו הוא לא EXCELLENT, אפשר להיעזר ברשימת השגיאות שמופיעה בקטע alerts כדי לשנות את תהליך הייבוא ולהפחית את השגיאות האלה או לבטל אותן.

לדוגמה:

• אם הסטטוס הוא NEEDS_ATTENTION, אז חלק משמעותי מפעולות הייבוא שלכם נכשל. בודקים את השגיאות בקטע alerts ומשנים את תהליך הייבוא כדי לצמצם את השגיאות האלה או לבטל אותן.

• אם הסטטוס הוא NO_RECENT_UPLOADS, סימן שלא בוצעו לאחרונה ייבואים אל Google Ads עבור client. אם זה לא צפוי, כדאי לבדוק את התהליכים שמבצעים ייבוא באמצעות הלקוח הזה.

  לדוגמה, אם הערך של status עבור GOOGLE_ADS_API הוא NO_RECENT_UPLOADS, יכול להיות שתהליך הייבוא שלכם שמשתמש ב-Google Ads API הפסיק לפעול לאחרונה.

• כדי לראות אם היה תאריך ייבוא או משימה ספציפיים ששלחו מספר גדול של אירועים שלא עברו עיבוד, בודקים את successful_count, failed_count ו-pending_count של daily_summaries ו-job_summaries. יכול להיות שיעברו עד 24 שעות עד שהאירועים במצב 'בהמתנה' יושלמו.

מידע נוסף על שיפור האבחון של נתונים ממקורות אופליין זמין במרכז העזרה.

הגבלות

כשמאחזרים סיכומי ייבוא, חשוב לזכור את הנקודות הבאות:

• ‫Google Ads API מחזיר אבחון של נתוני אופליין רק אם הערך של customer_id בבקשת searchStream או search הוא אותו לקוח שבו השתמשתם לאחרונה כדי לייבא המרות.

  לדוגמה, יכול להיות שחשבון לקוח שמוגדר בו מעקב המרות ברמת חשבון הניהול לא יכלול נתוני אבחון. עם זאת, אפשר לאחזר נתוני אבחון על ידי שליחת בקשה שבה הערך של customer_id זהה לערך של customer_id בחשבון הניהול שבו אתם משתמשים לייבוא.

• מערכת Google Ads מתייחסת לשגיאות CLICK_NOT_FOUND מייבוא של המרות משופרות לצורך שיוך ללידים כאזהרות. לכן, אם alerts מכיל רשומה של השגיאה הזו, הפעולות המתאימות עדיין נחשבות כמוצלחות ונכללות ב-successful_event_count.