การวินิจฉัย

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

  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 และทำซ้ำจนกว่าคุณจะแก้ไขปัญหาทั้งหมดเกี่ยวกับการอัปโหลด

ส่งคำขอ

A RetrieveRequestStatusRequest ต้องมีค่า single 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 จำนวนเล็กน้อยแบบสุ่มลงในการหน่วงเวลา Backoff เพื่อป้องกันปัญหา "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
สถานะการนำข้อมูล User ID ออก
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 ไม่ได้ 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 อย่างน้อย 1 รายการ

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

warning_info

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

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

error_info

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