การวินิจฉัย

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

  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

กลyุทธ์การโพลลิ่ง

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

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

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