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

אפשר להשתמש ב-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, המשמעות היא שלא התקבלו לאחרונה העלאות של client ב-Google Ads. אם זה לא אמור להיות כך, צריך לבדוק את התהליכים שמבצעים העלאות באמצעות הלקוח הזה.

  לדוגמה, אם הערך של 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.