ניתוחים

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

  1. שליחת בקשות לשליחת אירועים או לשליחה או להסרה של חברים בקהל.
  2. מצלמים את request_id מכל אחד מהמכשירים הבאים: IngestEventsResponse,‏ IngestAudienceMembersResponse או RemoveAudienceMembersResponse.
  3. שולחים בקשת RetrieveRequestStatus לכל request_id.
  4. כדאי לבדוק כל RetrieveRequestStatusResponse כדי לוודא שההעלאות פועלות בצורה תקינה ולזהות בעיות בנתונים.
  5. תיקון בעיות בנתונים.
  6. חוזרים לשלב 1 ופועלים לפי ההוראות עד שפותרים את כל הבעיות בהעלאות.

יצירת בקשות

ל-RetrieveRequestStatusRequest יש שדה request_id אחד. שולחים בקשה אחת לכל מזהה בקשה שתועד כשנשלחו בקשות להעברה.

בדיקת התשובות

השדה request_status_per_destination ב-RetrieveRequestStatusResponse מכיל רשומה נפרדת לכל יעד בבקשת ההעברה המתאימה.

לדוגמה, אם IngestAudienceMembersRequest כלל 3 רשומות ברשימה destinations לשליחת נתונים ל-3 קהלים שונים, תגובת הסטטוס תכלול 3 רשומות ב-request_status_per_destination (רשומה אחת לכל קהל).

בדיקת הסטטוס הכולל של היעד

בשלב הראשון, בודקים את השדה request_status כדי לראות אם ה-API של המרכז לניהול נתונים סיים לעבד את הנתונים של destination ב-RequestStatusPerDestination. אלה הערכים האפשריים של request_status:

  • PROCESSING: הנתונים של היעד עדיין נמצאים בתהליך עיבוד.
  • ‫SUCCESS: עיבוד הבקשה ליעד הסתיים ללא שגיאות.
  • FAILURE: כל הרשומות של היעד נכשלו בגלל שגיאות.
  • ‫PARTIAL_SUCCESS: חלק מהרשומות ליעד הצליחו, אבל אחרות נכשלו בגלל שגיאות.

בדיקת הסטטוס של אירוע או קהל לפי יעד

בודקים את שדה הסטטוס שמתאים לסוג הבקשה להעלאת נתונים. רק אחד מהשדות הבאים מוגדר בכל RequestStatusPerDestination:

סטטוס הטמעת הנתונים של אירועים

השדה events_ingestion_status יאוכלס אם הבקשה הייתה IngestEventsRequest.

בודקים את record_count של IngestEventStatus כדי לוודא שהמספר הכולל של הרשומות שהתקבלו תואם למה שציפיתם. המספר record_count כולל רשומות שהצליחו ורשומות שנכשלו.

סטטוס הטמעת הנתונים של חברי הקהל

השדה audience_members_ingestion_status יאוכלס אם הבקשה הייתה IngestAudienceMembersRequest. כאן מופיע השדה IngestAudienceMembersStatus שצריך לבדוק עבור כל סוג של נתוני קהל. רק אחד מהשדות האלה מוגדר.

user_data_ingestion_status

בודקים את record_count של IngestUserDataStatus כדי לוודא שהמספר הכולל של הרשומות שהתקבלו תואם לציפיות שלכם. record_count כולל רשומות שהצליחו ורשומות שנכשלו.

בודקים את הערך user_identifier_count כדי לוודא שמספר מזהי המשתמשים שהתקבל תואם לציפיות שלכם.

אם בבקשה היה מספר מספיק של רשומות, השדה upload_match_rate_range מכיל את טווח שיעור ההתאמה של הרשומות בבקשה.

mobile_data_ingestion_status

בודקים את record_count של IngestMobileDataStatus כדי לוודא שמספר הרשומות הכולל שהתקבל תואם לציפיות שלכם. המספר record_count כולל גם רשומות שהצליחו וגם רשומות שנכשלו.

בודקים את mobile_id_count כדי לוודא שמספר המזהים לנייד שהתקבלו תואם לציפיות שלכם.

pair_data_ingestion_status

בודקים את record_count של IngestPairDataStatus כדי לוודא שהמספר הכולל של הרשומות שהתקבלו תואם לציפיות שלכם. record_count כולל רשומות שהצליחו ורשומות שנכשלו.

בודקים את pair_id_count כדי לוודא שמספר מזהי ה-PAIR שקיבלתם תואם למה שציפיתם.

סטטוס ההסרה של חברי הקהל

השדה audience_members_removal_status יאוכלס אם הבקשה הייתה RemoveAudienceMembersRequest. הנה השדה RemoveAudienceMembersStatus שצריך לבדוק לכל סוג של נתוני קהל. רק אחד מהשדות האלה מוגדר.

user_data_removal_status
סטטוס ההסרה של נתוני משתמשים.
mobile_data_removal_status
סטטוס ההסרה של חבילת הגלישה.
pair_data_removal_status
סטטוס ההסרה של נתוני PAIR.

בודקים את record_count כדי לוודא שמספר הרשומות הכולל שקיבלתם תואם לציפיות שלכם. הדוח record_count כולל רשומות של פעולות מוצלחות וגם של פעולות שנכשלו.

בנוסף, כדאי לבדוק את user_identifier_count, mobile_id_count או pair_id_count כדי לוודא את המספר הכולל של מזהי משתמשים, מזהים לנייד או מזהי PAIR שהתקבלו.

בדיקת אזהרות ושגיאות

בנוסף לשדות הסטטוס של היעד וסוג הבקשה, RetrieveRequestStatusResponse מכיל פירוט של האזהרות והשגיאות שקשורות לבקשה.

  • שגיאה מציינת שה-API דחה את הרשומה באופן מוחלט.
  • אזהרה מציינת שה-API לא דחה את הרשומה, אבל הוא נאלץ להתעלם מחלקים מהנתונים של הרשומה.

לדוגמה, אם Event מכיל נתונים מוצפנים של UserIdentifier ושל AdIdentifiers כמו gclid, ואי אפשר לפענח את נתוני UserIdentifier, ה-API של המרכז לניהול נתונים עדיין מעבד את הרשומה באמצעות AdIdentifiers אבל מחזיר את האזהרה PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR.

עם זאת, אם Event לא מכיל את AdIdentifiers ואי אפשר לפענח את הנתונים של UserIdentifier, ה-API של המרכז לניהול נתונים דוחה את הרשומה כולה ומדווח על השגיאה PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR, כי Event תקין חייב לכלול לפחות אחד מהערכים ad_identifiers או user_data.

אלה שדות התגובה שמכילים מידע על אזהרות ושגיאות.

warning_info
רשימה של אובייקטים מסוג WarningCount. כל רכיב WarningCount מכיל רכיב reason עם סוג האזהרה, ורכיב record_count שמציין את מספר הרשומות שהוצגו לגביהן אזהרות מהסוג הזה.
error_info
רשימה של אובייקטים מסוג ErrorCount. כל ErrorCount מכיל reason עם סוג השגיאה ו-record_count שמציין את מספר הרשומות שנכשלו בגלל סוג השגיאה הזה.