การวินิจฉัย

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

  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 ไม่ยอมรับบัญชีปลายทางหรือส่วนหัวของคำขอ แต่ Data Manager API จะระบุปลายทางจากคำขอส่งผ่านข้อมูลเดิมที่เชื่อมโยงกับ request_id และยืนยันว่าผู้เรียกมีสิทธิ์เข้าถึง operating_account ใน Destination แต่ละรายการ

หากต้องการตรวจสอบสถานะของคำขอ ข้อมูลเข้าสู่ระบบที่ใช้ใน RetrieveRequestStatusRequest ต้องเป็นไปตามข้อกำหนดต่อไปนี้สำหรับ operating_account ของปลายทางแต่ละแห่งจากคำขอส่งผ่านข้อมูลต้นฉบับ

  • เส้นทางการเข้าถึงที่เหมือนกัน: ข้อมูลเข้าสู่ระบบต้องมีสิทธิ์เข้าถึงแต่ละ operating_account โดยใช้เส้นทางการเข้าถึงที่เหมือนกันทุกประการที่ระบุไว้ใน คำขอส่งผ่านข้อมูลเดิม

    ตัวอย่างเช่น หากคำขอส่งผ่านข้อมูลสำหรับ operating_account ของ Google Ads ระบุบัญชีดูแลจัดการหลักเป็น login_account ข้อมูลเข้าสู่ระบบก็ต้องมีสิทธิ์เข้าถึง operating_account ผ่านบัญชีดูแลจัดการเดียวกันนั้นด้วย แม้ว่าบัญชี Google ที่เชื่อมโยงกับข้อมูลเข้าสู่ระบบจะมีสิทธิ์เข้าถึงบัญชี operating_account ย่อยโดยตรง แต่คำขอจะดำเนินการไม่สำเร็จและแสดงข้อผิดพลาด PERMISSION_DENIED หากบัญชีดังกล่าวไม่มีสิทธิ์เข้าถึงผ่านบัญชีดูแลจัดการ login_account ที่ระบุไว้ในระหว่างการนำเข้า

  • ระดับการเข้าถึงที่เพียงพอ: บัญชี Google ที่เชื่อมโยงกับ ข้อมูลเข้าสู่ระบบต้องมีระดับการเข้าถึงหรือบทบาทที่มีสิทธิ์ในการส่งผ่านข้อมูล ไปยัง operating_account

    เช่น ใน Google Ads บัญชี Google ต้องมีระดับการเข้าถึง ผู้ดูแลระบบหรือมาตรฐาน คำขอที่มีข้อมูลเข้าสู่ระบบสำหรับบัญชีที่มีระดับการเข้าถึงแบบอ่านอย่างเดียวจะดำเนินการไม่สำเร็จพร้อมข้อผิดพลาด PERMISSION_DENIED

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

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

ต่อไปนี้คือตัวอย่างการกำหนดค่าเวลารอเริ่มต้นและการลองใหม่ที่สมเหตุสมผลซึ่งสร้างสมดุลระหว่างความพร้อมใช้งานและการใช้โควต้า

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

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 เพื่อยืนยันว่าจำนวน Mobile ID ที่ได้รับตรงกับที่คุณคาดหวัง

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
สถานะการนำออกสำหรับข้อมูลรหัสผู้ใช้

ตรวจสอบ 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

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

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

error_info

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