การวินิจฉัย

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

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 ชั่วโมง)

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

เพิ่มค่า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
• audience_members_ingestion_status
• audience_members_removal_status

สถานะการนำเข้าเหตุการณ์

ระบบจะป้อนข้อมูลในฟิลด์ 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 เพื่อยืนยันว่าจํานวน User-ID ที่ได้รับ ตรงกับที่คุณคาดไว้

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

ระบบจะป้อนข้อมูลในฟิลด์ 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

สถานะการนำข้อมูลรหัสผู้ใช้ออก

ตรวจสอบ 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 อย่างน้อย 1 รายการ

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

warning_info

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

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

error_info

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