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

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

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

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

כדי לאחזר אבחון של העלאת המרות ברמת החשבון, משתמשים בשאילתת 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_id,
  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 = <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
בקשות ייבוא של successful_count, failed_count ו-pending_count מ-7 הימים האחרונים, מקובצות לפי ייבוא 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.