การวินิจฉัย

นี่คือเวิร์กโฟลว์ที่แนะนำในการยืนยันประสิทธิภาพของการอัปโหลดเหตุการณ์และกลุ่มเป้าหมาย รวมถึงระบุปัญหาเกี่ยวกับข้อมูล

  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 ใช้อัลกอริทึม Exponential Backoff เพื่อรอระหว่างคำขอแต่ละรายการ

  4. ตรวจสอบRetrieveRequestStatusResponseแต่ละรายการเพื่อยืนยัน ว่าการอัปโหลดทำงานได้อย่างถูกต้องและระบุปัญหาเกี่ยวกับข้อมูล

  5. แก้ไขปัญหาเกี่ยวกับข้อมูล

  6. กลับไปที่ขั้นตอนที่ 1 แล้วทำซ้ำจนกว่าจะแก้ไขปัญหาทั้งหมดเกี่ยวกับการอัปโหลด

ส่งคำขอ

RetrieveRequestStatusRequest ต้องมีค่า request_id เดียว ส่งคำขอสถานะแยกต่างหากสำหรับรหัสคำขอแต่ละรายการที่คุณ บันทึกจากคำขอการส่งผ่านข้อมูลที่สำเร็จ

ส่ง RetrieveRequestStatusRequest เป็นระยะ โดยใช้อัลกอริทึม Exponential Backoff จนกว่า request_status จะถึง SUCCESS, FAILURE หรือ PARTIAL_SUCCESS สำหรับปลายทางทุกแห่งในคำขอ เดิม การดำเนินการนี้อาจใช้เวลาถึง 24 ชั่วโมง แม้ว่า Data Manager API อาจประมวลผลคำขอบางรายการเสร็จภายในเวลาเพียง 30 นาทีก็ตาม

ตัวอย่างการกำหนดค่าเวลาในการรอเริ่มต้นและการลองใหม่ที่เหมาะสม ซึ่งจะช่วยรักษาสถานะการทำงานและโควต้าการใช้งานมีดังนี้

การตั้งค่า ค่า
เวลารอก่อนคำขอการวินิจฉัยครั้งแรก (นาที) 30
ตัวคูณ Backoff 1.3
Backoff สูงสุด (นาที) 60 (1 ชั่วโมง)
เวลารวมสูงสุด (นาที) 1440 (24 ชั่วโมง)

ต่อไปนี้คือลำดับคำขอและเวลาที่ผ่านไปด้วยการกำหนดค่านี้

กราฟของฟังก์ชัน

กลยุทธ์การสำรวจ

ข้อมูล

ความพยายาม เวลาตั้งแต่ส่งคำขอส่งผ่านข้อมูล (hh:mm) หน่วงเวลาก่อนพยายาม หมายเหตุ
1 00:30 30.0 นาที ก่อนอื่นให้ตรวจสอบความพร้อมใช้งานของสถานะ
2 01:09 39.0 นาที
3 01:59 50.7 นาที
4 02:59 60.0 นาที ตอนนี้การหน่วงเวลาจะจำกัดไว้ที่ 1 ชั่วโมง
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 ชั่วโมง

เพิ่มค่าแบบสุ่มเล็กน้อยของ jitter ลงในดีเลย์การหยุดชั่วคราว เพื่อป้องกันปัญหา "thundering herd" ที่ไคลเอ็นต์จำนวนมากพยายามอีกครั้งพร้อมกัน

ตรวจสอบคำตอบ

request_status_per_destination ใน RetrieveRequestStatusResponse มีรายการแยกต่างหากสำหรับ แต่ละปลายทางในคำขอส่งผ่านข้อมูลที่เกี่ยวข้อง

เช่น หาก IngestAudienceMembersRequest มีรายการ 3 รายการในรายการ destinations เพื่อส่งข้อมูลไปยังกลุ่มเป้าหมาย 3 กลุ่ม ที่แตกต่างกัน การตอบกลับสถานะจะมีรายการ 3 รายการใน request_status_per_destination (1 รายการต่อกลุ่มเป้าหมาย)

ตรวจสอบสถานะปลายทางโดยรวม

ขั้นตอนแรก ให้ตรวจสอบฟิลด์ 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 ตั้งค่าช่องใดช่องหนึ่งเท่านั้น

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 ที่ได้รับ ตรงกับที่คุณคาดไว้

ppid_data_ingestion_status

ตรวจสอบrecord_countของ IngestPpidDataStatus เพื่อยืนยันว่าจำนวนระเบียนทั้งหมดที่ได้รับตรงกับที่คุณคาดไว้ record_count รวมทั้งบันทึกที่สำเร็จและไม่สำเร็จ

ตรวจสอบ ppid_count เพื่อยืนยันว่าจำนวน PPID ที่ได้รับ ตรงกับที่คุณคาดไว้

user_id_data_ingestion_status

ตรวจสอบrecord_countของ IngestUserIdDataStatus เพื่อยืนยันว่าจำนวนระเบียนทั้งหมดที่ได้รับตรงกับที่คุณคาดไว้ record_count รวมทั้งบันทึกที่สำเร็จและไม่สำเร็จ

ตรวจสอบ user_id_count เพื่อยืนยันว่าจำนวน User-ID ที่ได้รับ ตรงกับที่คุณคาดไว้

composite_data_ingestion_status

ตรวจสอบrecord_countของ IngestCompositeDataStatus เพื่อยืนยันว่า จำนวนระเบียนทั้งหมดที่ได้รับตรงกับที่คุณคาดไว้ โดย record_countจะรวมทั้งระเบียนที่สำเร็จและไม่สำเร็จ

ตรวจสอบdata_type_countsเพื่อยืนยันว่าจํานวนตัวระบุ ตรงกับที่คุณคาดไว้ รายการนี้แสดงรายละเอียดของตัวระบุทั้งหมดที่ได้รับ (เช่น อีเมล หมายเลขโทรศัพท์ ที่อยู่จริง และที่อยู่ IP) โดย DataType

หากคำขอมีจำนวนระเบียนเพียงพอ upload_match_rate_range จะมีอัตราการจับคู่ ช่วงสำหรับระเบียนในคำขอ

สถานะการนำสมาชิกในกลุ่มเป้าหมายออก

ระบบจะป้อนข้อมูลในฟิลด์ audience_members_removal_status หากคำขอเป็นRemoveAudienceMembersRequest ต่อไปนี้คือฟิลด์ RemoveAudienceMembersStatus ที่ต้องตรวจสอบสำหรับข้อมูลกลุ่มเป้าหมายแต่ละประเภท ตั้งค่าช่องใดช่องหนึ่งเท่านั้น

user_data_removal_status
สถานะการนำข้อมูลผู้ใช้ออก
mobile_data_removal_status
สถานะการนำออกสำหรับอินเทอร์เน็ตมือถือ
pair_data_removal_status
สถานะการนำข้อมูล PAIR ออก
ppid_data_removal_status
สถานะการนำออกสำหรับข้อมูล PPID
user_id_data_removal_status
สถานะการนำออกสำหรับข้อมูลรหัสผู้ใช้
composite_data_removal_status
สถานะการนำออกสำหรับข้อมูลแบบผสม

ตรวจสอบ record_count เพื่อยืนยันว่าจำนวนระเบียนทั้งหมด ที่ได้รับตรงกับที่คุณคาดไว้ record_count ประกอบด้วยทั้งระเบียนที่สำเร็จและไม่สำเร็จ

นอกจากนี้ ให้ตรวจสอบuser_identifier_count, mobile_id_count, pair_id_count, ppid_count หรือ user_id_count เพื่อยืนยันจำนวนทั้งหมดของ ตัวระบุที่ได้รับ

สำหรับข้อมูลแบบผสม ให้ตรวจสอบ data_type_counts เพื่อยืนยันว่าจำนวนตัวระบุตรงกับที่คุณคาดไว้ รายการนี้แสดงรายละเอียดของตัวระบุทั้งหมดที่ได้รับ (เช่น อีเมล หมายเลขโทรศัพท์ ที่อยู่จริง และ ที่อยู่ IP) โดย DataType

ตรวจสอบคำเตือนและข้อผิดพลาด

นอกเหนือจากฟิลด์สถานะสำหรับปลายทางและประเภทคำขอแล้ว RetrieveRequestStatusResponse ยังมีรายละเอียดของคำเตือนและข้อผิดพลาดสำหรับคำขอด้วย

  • ข้อผิดพลาดบ่งชี้ว่า API ปฏิเสธระเบียนโดยสมบูรณ์
  • คำเตือนบ่งชี้ว่า API ไม่ได้ปฏิเสธระเบียน แต่ต้อง ละเว้นส่วนต่างๆ ของข้อมูลระเบียน

เช่น หาก Event มีข้อมูลที่เข้ารหัส UserIdentifier และ AdIdentifiers เช่น gclid และถอดรหัสข้อมูล UserIdentifier ไม่ได้ API ของ Data Manager จะยังคงประมวลผล ระเบียนโดยใช้ 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 อย่างน้อย 1 รายการ

ฟิลด์การตอบกลับที่มีข้อมูลคำเตือนและข้อผิดพลาดมีดังนี้ ระบบจะป้อนข้อมูลในช่องเหล่านี้เมื่อสถานะปลายทางโดยรวม เปลี่ยนเป็นSUCCESS PARTIAL_SUCCESS หรือ FAILURE

warning_info

รายการออบเจ็กต์ WarningCount แต่ละ WarningCount จะมี reason ที่มีประเภทคำเตือน และ record_count ที่ระบุจำนวนระเบียนที่มีคำเตือนประเภทนั้น

ตรวจสอบ warning_info แม้ว่าสถานะของจุดหมายโดยรวมจะเป็น SUCCESS

error_info

รายการออบเจ็กต์ ErrorCount ErrorCountแต่ละรายการ จะมี reason ที่มีประเภทข้อผิดพลาด และ record_count ที่ระบุ จำนวนระเบียนที่ล้มเหลวเนื่องจากข้อผิดพลาดประเภทนั้น