אבחון

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

  1. שליחת בקשות לשליחת אירועים או לשליחה או להסרה של חברי קהל.

  2. בודקים את הסטטוס הכולל של כל בקשה. בקשה מוצלחת כוללת Status עם code ששווה ל-0 (ערך enum‏ OK, תגובת HTTP‏ 200 OK), ומחזירה IngestEventsResponse,‏ IngestAudienceMembersResponse או RemoveAudienceMembersResponse.

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

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

  3. ממתינים 30 דקות ואז שולחים בקשת RetrieveRequestStatus לכל request_id שהושלם בהצלחה.

    חוזרים על השלב הזה מעת לעת לכל request_id עד שסטטוס היעד של כל יעד מגיע ל-SUCCESS, PARTIAL_SUCCESS או FAILURE. צריך להשתמש באלגוריתם של השהיה מעריכית לפני ניסיון חוזר כדי להמתין בין כל בקשה.

  4. כדאי לבדוק כל RetrieveRequestStatusResponse כדי לוודא שההעלאות פועלות בצורה תקינה ולזהות בעיות בנתונים.

  5. לפתור בעיות בנתונים.

  6. חוזרים לשלב 1 ופועלים לפי ההוראות עד שפותרים את כל הבעיות בהעלאות.

שליחת בקשות

לRetrieveRequestStatusRequest נדרש ערך request_id יחיד. שולחים בקשת סטטוס נפרדת לכל מזהה בקשה ששמרתם מבקשת הטמעה מוצלחת.

שולחים את RetrieveRequestStatusRequest מדי פעם באמצעות אלגוריתם של השהיה מעריכית לפני ניסיון חוזר עד שערך request_status מגיע ל-SUCCESS, FAILURE או PARTIAL_SUCCESS לכל יעד בבקשה המקורית. התהליך עשוי להימשך עד 24 שעות, אבל יכול להיות ש-Data Manager API יסיים לעבד חלק מהבקשות תוך 30 דקות בלבד.

דוגמה לזמן המתנה ראשוני סביר ולתצורת ניסיונות חוזרים שמאזנים בין זמינות לבין שימוש במכסת המכסה:

הגדרה ערך
זמן ההמתנה לפני בקשת האבחון הראשונה (דקות) 30
מכפיל ההשהיה 1.3
השהיה לפני ניסיון חוזר מקסימלית (בדקות) 60 (שעה אחת)
משך הזמן הכולל המקסימלי (דקות) ‫1440 (24 שעות)

זוהי רצף של בקשות והזמן שחלף עם ההגדרה הזו:

תרשים

אסטרטגיית סקרים

נתונים

ניסיון הזמן שעבר מאז בקשת ההטמעה (hh:mm) השהיה לפני הניסיון הערות
1 00:30 ‫30.0 דקות קודם בודקים את הזמינות של הסטטוס
2 01:09 ‫39.0 דקות
3 01:59 ‫50.7 דקות
4 02:59 ‫60.0 דקות העיכוב מוגבל עכשיו לשעה אחת
5 03:59 ‫60.0 דקות
6 04:59 ‫60.0 דקות
7 05:59 ‫60.0 דקות
8 06:59 ‫60.0 דקות
9 07:59 ‫60.0 דקות
10 08:59 ‫60.0 דקות
11 09:59 ‫60.0 דקות
12 10:59 ‫60.0 דקות
13 11:59 ‫60.0 דקות סימון של 12 שעות
14 12:59 ‫60.0 דקות
15 13:59 ‫60.0 דקות
16 14:59 ‫60.0 דקות
17 15:59 ‫60.0 דקות
18 16:59 ‫60.0 דקות
19 17:59 ‫60.0 דקות
20 18:59 ‫60.0 דקות
21 19:59 ‫60.0 דקות
22 20:59 ‫60.0 דקות
23 21:59 ‫60.0 דקות
24 22:59 ‫60.0 דקות
25 23:59 ‫60.0 דקות הבקשה האחרונה לפני שהגעתם למקסימום הכולל של 24 שעות

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

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

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

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

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

כשלב ראשון, בודקים את השדה request_status כדי לראות אם Data Manager 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 שצריך לבדוק עבור כל סוג של נתוני קהל. מוגדר רק אחד מהשדות האלה.

composite_data_ingestion_status

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

בודקים את data_type_counts כדי לוודא שמספר המזהים תואם למה שציפיתם. הרשימה הזו כוללת פירוט של כל המזהים שהתקבלו (כמו כתובת אימייל, מספר טלפון, כתובת פיזית וכתובת IP) על ידי DataType.

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

google_user_id_data_ingestion_status

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

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

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 שקיבלתם תואם למה שציפיתם.

partner_provided_id_data_ingestion_status

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

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

ppid_data_ingestion_status

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

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

user_data_ingestion_status

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

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

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

user_id_data_ingestion_status

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

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

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

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

composite_data_removal_status
סטטוס ההסרה של נתונים מורכבים
google_user_id_data_removal_status
סטטוס ההסרה של נתוני מזהה משתמש ב-Google
mobile_data_removal_status
סטטוס ההסרה של חבילת הגלישה.
pair_data_removal_status
סטטוס ההסרה של נתוני PAIR.
partner_provided_id_data_removal_status
סטטוס ההסרה של נתוני מזהים שסופקו על ידי שותף
ppid_data_removal_status
סטטוס ההסרה של נתוני PPID.
user_data_removal_status
סטטוס ההסרה של נתוני המשתמש.
user_id_data_removal_status
סטטוס ההסרה של נתוני User-ID

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

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

אם מדובר בנתונים מורכבים, בודקים את data_type_counts כדי לוודא שמספר המזהים תואם לציפיות שלכם. הרשימה הזו כוללת פירוט של כל המזהים שהתקבלו (כמו כתובת אימייל, מספר טלפון, כתובת פיזית וכתובת IP) על ידי DataType.

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

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

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

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

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

אלה שדות התגובה שמכילים מידע על אזהרות ושגיאות. השדות האלה מתמלאים כשהסטטוס הכולל של היעד מגיע לערך SUCCESS,‏ PARTIAL_SUCCESS או FAILURE.

warning_info

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

בודקים את warning_info גם אם הסטטוס הכולל של היעד הוא SUCCESS.

error_info

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