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

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

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

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.resource_name,
  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.

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

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

daily_summaries

successful_count ו-failed_count של בקשות העלאה מ-7 הימים האחרונים, מקובצות לפי date להעלאה.

job_summaries

successful_count ו-failed_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 של daily_summaries ו-job_summaries כדי לראות אם היו תאריך העלאה או משימה ספציפיים ששלחו מספר גדול של אירועים שלא עובדו בהצלחה.

הגבלות

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

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

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

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