แนวทางปฏิบัติแนะนําในการรายงาน

สร้างรายงานใหม่ใน UI ก่อน

รายงานอยู่ภายใต้ข้อจำกัดและข้อกำหนดหลายประการเกี่ยวกับประเภทการรายงาน ตัวกรอง มิติข้อมูล และเมตริก ระบบจะบังคับใช้ข้อจำกัดเหล่านี้ใน API โดยแสดงผลข้อผิดพลาด HTTP 400 เพื่อหลีกเลี่ยงข้อผิดพลาดเมื่อสร้างรายงาน เราขอแนะนำให้คุณสร้างรายงานใหม่ใน UI ของ Display & Video 360 ก่อน

หลังจากสร้างรายงานแล้ว ให้คลิกฟีเจอร์"ลองใช้ API นี้" ในหน้าเอกสารอ้างอิงเพื่อดำเนินการ queries.get จากทรัพยากร Query คุณจะใช้ JSON ที่แสดงผลเพื่อสร้างรายงานในอนาคตได้

ใช้เมตริกและตัวกรองสำหรับประเภทรายงานโดยเฉพาะ

ค่าเมตริกและตัวกรองบางค่าจะใช้กับรายงานบางประเภทโดยเฉพาะ นอกเหนือจากการสร้างรายงานใน UI ก่อนแล้ว คุณยังระบุเมตริกและตัวกรองที่เป็นของค่า ReportType บางรายการตามค่า Bid Manager API ได้อีกด้วย

ต่อไปนี้คือวิธีระบุค่าเมตริกและตัวกรอง Bid Manager API ที่เกี่ยวข้อง ตารางนี้ไม่ใช่รายการตัวกรองและเมตริกทั้งหมดที่สามารถใช้ในรายงานประเภทเหล่านี้ได้ ค่าบางค่าไม่สามารถใช้ร่วมกันได้ ในรายงานเดียว

ReportType ตัวกรองและเมตริกที่เกี่ยวข้อง
INVENTORY_AVAILABILITY
  • ตัวกรองที่มีคำนำหน้า FILTER_TRUEVIEW_IAR
YOUTUBE
  • ตัวกรองที่มีคำนำหน้า FILTER_TRUEVIEW โดยยกเว้นตัวกรองที่มีคำนำหน้า FILTER_TRUEVIEW_IAR
  • เมตริกที่มีคํานําหน้า METRIC_TRUEVIEW
GRP
  • เมตริกที่มีคํานําหน้า METRIC_GRP
YOUTUBE_PROGRAMMATIC_GUARANTEED
  • ตัวกรองที่มีคำนำหน้า FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED
  • เมตริกที่มีคํานําหน้า METRIC_PROGRAMMATIC_GUARANTEED
REACH
  • เมตริกที่มีคํานําหน้า METRIC_UNIQUE_REACH
UNIQUE_REACH_AUDIENCE
  • เมตริกที่มีคํานําหน้า METRIC_UNIQUE_REACH

บันทึกและใช้รายงานซ้ำ

เราขอแนะนำให้คุณสร้างและบันทึกรายงานสำหรับข้อความค้นหาที่คุณใช้เป็นประจำ เนื่องจากการแทรกและลบรายงานเดิมหลายครั้งจะทำให้เสียทรัพยากร การใช้ชุดค่า Range เช่น PREVIOUS_DAY หรือ LAST_7_DAYS ในช่อง dataRange ช่วยให้ใช้งานรายงานซ้ำได้ง่ายขึ้น

ตั้งเวลารายงาน

รายงานเฉพาะกิจหรือรายงานแบบครั้งเดียวอาจทำให้ใช้ทรัพยากรสิ้นเปลือง เนื่องจากมีการเรียกใช้รายงานแบบเดี่ยวๆ และอาจดำเนินการกับชุดข้อมูลที่ไม่สมบูรณ์ รายงานที่ตั้งเวลาไว้จะใช้ทรัพยากรการรายงานให้เกิดประโยชน์สูงสุด เนื่องจากรายงานจะทำงานเป็นกลุ่มและรับประกันได้ว่าจะไม่มีการดำเนินการใดๆ จนกว่าข้อมูลของวันก่อนหน้าจะประมวลผลเสร็จ ดูรายละเอียดได้ที่ช่องการตั้งเวลาที่ใช้ได้

รวมรายงานที่คล้ายกัน

หากคุณสร้างรายงานที่มีเมตริกและช่วงวันที่เหมือนกันสำหรับผู้ลงโฆษณาหรือพาร์ทเนอร์รายต่างๆ เป็นประจำ เราขอแนะนำให้คุณรวมรายงานเข้าด้วยกันเพื่อเพิ่มปริมาณรายงาน

คุณรวมรายงานที่คล้ายกันได้โดยเพิ่มตัวกรองของรายงานทั้งหมดต่อท้าย และเพิ่มตัวกรองทุกประเภทเป็นมิติข้อมูล หลังจากสร้างแล้ว คุณสามารถแบ่งแถวของรายงานผลลัพธ์ตามค่าตัวกรองเดิมเพื่อสร้างรายงานต้นฉบับ

พิจารณาโควต้าการรายงาน

การใช้งานฟีเจอร์การรายงาน Display & Video 360 อย่างมีความรับผิดชอบจะมีการบังคับใช้ผ่านโควต้าการใช้งานระดับผลิตภัณฑ์ต่อไปนี้

การดำเนินการรายงานเฉพาะกิจต่อวัน

จำกัดจำนวนรายงานเฉพาะกิจที่ผู้ใช้จัดทำได้ในช่วงเวลา 24 ชั่วโมง หากต้องการใช้งานไม่เกินโควต้านี้ ให้ทำดังนี้

รายงานที่ตั้งเวลาไว้ซึ่งใช้งานอยู่

จำกัดจำนวนรายงานที่ผู้ใช้กำหนดไว้ได้ในช่วงเวลาหนึ่งๆ หากต้องการใช้งานไม่เกินโควต้านี้ ให้ทำดังนี้

รายงานที่เกิดขึ้นพร้อมกัน

จำกัดจำนวนรายงานที่ผู้ใช้เรียกใช้พร้อมกันได้ หากต้องการใช้งานไม่เกินโควต้านี้ ให้ทำดังนี้

  • ตั้งเวลารายงานที่ทำงานเป็นประจำ
  • ปิดใช้งานสคริปต์ API ที่ไม่จำเป็น
  • ติดตามว่ารายงานจะเสร็จสิ้นเมื่อใดด้วยการสำรวจโดยใช้ตรรกะ Backoff แบบเอ็กซ์โปเนนเชียล

หากคุณเพิ่มประสิทธิภาพการใช้การรายงานแล้ว แต่ยังคงใช้งานเกินโควต้าที่กำหนดไว้ โปรดติดต่อทีมสนับสนุนของ Display & Video 360 โดยใช้แบบฟอร์มติดต่อ

ใช้ Exponential Backoff เมื่อทำการหยั่งสัญญาณเพื่อดูสถานะรายงาน

คาดการณ์ไม่ได้ว่าจะใช้เวลานานเท่าใดในการเรียกใช้รายงาน ระยะเวลาอาจเป็นได้ตั้งแต่วินาทีไปจนถึงชั่วโมง ขึ้นอยู่กับหลายปัจจัย ซึ่งรวมถึงช่วงวันที่และปริมาณข้อมูลที่จะประมวลผล เป็นต้น นอกจากนี้ เวลาที่แสดงของรายงานกับจำนวนแถวที่แสดงในรายงานก็ไม่มีความสัมพันธ์กัน คุณจึงต้องเรียกข้อมูลแหล่งข้อมูลรายงานเป็นประจำโดยใช้เมธอด queries.reports.get และตรวจสอบว่าได้อัปเดตช่อง metadata.status.state ของทรัพยากรเป็น DONE หรือ FAILED เพื่อดูว่าระบบทำงานเสร็จแล้วหรือไม่ นี่คือกระบวนการที่เรียกว่า "แบบสำรวจ"

แม้ว่าการสำรวจความคิดเห็นจะมีความจำเป็น แต่การใช้งานที่ไม่มีประสิทธิภาพก็อาจทำให้หมดโควต้าอย่างรวดเร็วเมื่อต้องเรียกใช้รายงานที่ใช้เวลานาน ดังนั้นเราขอแนะนำให้คุณใช้ Exponential Backoff เพื่อจำกัดการลองใหม่และประหยัดโควต้า

Exponential Backoff

Exponential Backoff เป็นกลยุทธ์การจัดการข้อผิดพลาดมาตรฐานสำหรับแอปพลิเคชันเครือข่ายที่ไคลเอ็นต์จะส่งคำขอซ้ำเป็นระยะๆ ในระยะเวลาที่เพิ่มขึ้น หากใช้งานอย่างถูกต้อง Exponential Backoff จะเพิ่มประสิทธิภาพในการใช้แบนด์วิดท์ ลดจำนวนคำขอที่จำเป็นต่อการได้รับการตอบสนองที่สำเร็จ และเพิ่มอัตราการส่งข้อมูลคำขอในสภาพแวดล้อมที่ทำงานพร้อมกันให้สูงสุด

ขั้นตอนการใช้ Exponential Backoff อย่างง่ายมีดังนี้

  1. ส่งคำขอ queries.reports.get ไปยัง API
  2. ดึงออบเจ็กต์รายงาน หากช่อง metadata.status.state ไม่ใช่ DONE หรือ FAILED แสดงว่ารายงานยังเรียกใช้ไม่เสร็จ คุณควรทำการสำรวจต่อ
  3. รอ 5 วินาที + ตัวเลขมิลลิวินาทีแบบสุ่ม แล้วลองส่งคำขออีกครั้ง
  4. ดึงออบเจ็กต์รายงาน หากช่อง metadata.status.state ไม่ใช่ DONE หรือ FAILED แสดงว่ารายงานยังเรียกใช้ไม่เสร็จ คุณควรทำการสำรวจต่อ
  5. โปรดรอ 10 วินาที + ตัวเลขมิลลิวินาทีแบบสุ่ม แล้วลองส่งคำขออีกครั้ง
  6. ดึงออบเจ็กต์รายงาน หากช่อง metadata.status.state ไม่ใช่ DONE หรือ FAILED แสดงว่ารายงานยังเรียกใช้ไม่เสร็จ คุณควรทำการสำรวจต่อ
  7. โปรดรอ 20 วินาที + จำนวนมิลลิวินาทีที่สุ่มขึ้นมา แล้วลองส่งคำขออีกครั้ง
  8. ดึงออบเจ็กต์รายงาน หากช่อง metadata.status.state ไม่ใช่ DONE หรือ FAILED แสดงว่ารายงานยังเรียกใช้ไม่เสร็จ คุณควรทำการสำรวจต่อ
  9. โปรดรอ 40 วินาที + จำนวนมิลลิวินาทีที่สุ่มขึ้นมา แล้วลองส่งคำขออีกครั้ง
  10. ดึงออบเจ็กต์รายงาน หากช่อง metadata.status.state ไม่ใช่ DONE หรือ FAILED แสดงว่ารายงานยังเรียกใช้ไม่เสร็จ คุณควรทำการสำรวจต่อ
  11. โปรดรอ 80 วินาที + ตัวเลขมิลลิวินาทีแบบสุ่ม แล้วลองส่งคำขออีกครั้ง
  12. ใช้รูปแบบนี้ต่อไปจนกว่าจะมีการอัปเดตออบเจ็กต์รายงานหรือถึงระยะเวลาสูงสุด

หากรายงานทำงานเสร็จแล้วและลงท้ายด้วยสถานะ DONE คุณจะเรียกข้อมูลไฟล์รายงานที่สร้างขึ้นจาก Google Cloud Storage ได้ตามเส้นทางที่ระบุไว้ในช่อง metadata.googleCloudStoragePath