การวินิจฉัย

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

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ที่คุณต้องตรวจสอบสำหรับข้อมูลผู้ชมแต่ละประเภทมีดังนี้ ตั้งค่าช่องเหล่านี้เพียงช่องเดียว

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

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

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

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

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

นอกจากนี้ ให้ตรวจสอบ user_identifier_count, mobile_id_count หรือ pair_id_count เพื่อยืนยันจำนวนรวมของตัวระบุผู้ใช้ รหัสอุปกรณ์เคลื่อนที่ หรือรหัส PAIR ที่ได้รับ

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

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

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

เช่น หาก Event สำหรับ Conversion ออฟไลน์ของ Google Ads มีข้อมูล 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 เนื่องจาก Conversion ออฟไลน์ของ Google Ads ที่ถูกต้อง 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 ที่ระบุ จำนวนระเบียนที่ล้มเหลวเนื่องจากข้อผิดพลาดประเภทนั้น