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

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

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

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

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

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

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

ReportType ตัวกรองและเมตริกที่เกี่ยวข้อง
YOUTUBE
  • ตัวกรองที่มีคำนำหน้า FILTER_TRUEVIEW
  • เมตริกที่มีคำนำหน้า 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 ที่ไม่จำเป็น
  • ติดตามเมื่อรายงานเสร็จสิ้นด้วยการสำรวจโดยใช้ตรรกะ Exponential 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