Trang này được dịch bởi Cloud Translation API.

Các phương pháp báo cáo hay nhất

Trước tiên, hãy tạo báo cáo mới trong giao diện người dùng

Các báo cáo phải tuân theo một số hạn chế và yêu cầu liên quan đến các loại báo cáo, bộ lọc, phương diện và chỉ số. Những giới hạn này được thực thi trong API, trả về lỗi HTTP 400. Để tránh lỗi khi tạo báo cáo, trước tiên bạn nên tạo báo cáo mới trong giao diện người dùng Display & Video 360.

Sau khi tạo báo cáo, hãy nhấp vào tính năng"Dùng thử API này" trên trang tài liệu tham khảo để thực hiện queries.get của tài nguyên Query. Bạn có thể sử dụng JSON được trả về để tạo các báo cáo trong tương lai.

Sử dụng các chỉ số và bộ lọc dành riêng cho loại báo cáo

Một số giá trị chỉ số và bộ lọc dành riêng cho một số loại báo cáo nhất định. Ngoài việc xây dựng báo cáo trong giao diện người dùng trước tiên, bạn cũng có thể xác định các chỉ số và bộ lọc thuộc một số giá trị ReportType nhất định theo giá trị của API Trình quản lý giá thầu.

Dưới đây là một số cách để xác định bộ lọc API Trình quản lý giá thầu và các giá trị chỉ số có liên quan. Bảng này không phải là danh sách đầy đủ gồm các bộ lọc và chỉ số có thể dùng trong các loại báo cáo này. Không phải giá trị nào cũng có thể sử dụng cùng nhau trong một báo cáo.

`ReportType`	Bộ lọc và chỉ số có liên quan
`INVENTORY_AVAILABILITY`	Bộ lọc có tiền tố `FILTER_TRUEVIEW_IAR`.
`YOUTUBE`	Các bộ lọc có tiền tố `FILTER_TRUEVIEW`, không bao gồm những bộ lọc có tiền tố `FILTER_TRUEVIEW_IAR`. Chỉ số có tiền tố `METRIC_TRUEVIEW`.
`GRP`	Chỉ số có tiền tố `METRIC_GRP`.
`YOUTUBE_PROGRAMMATIC_GUARANTEED`	Bộ lọc có tiền tố `FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED`. Chỉ số có tiền tố `METRIC_PROGRAMMATIC_GUARANTEED`.
`REACH`	Chỉ số có tiền tố `METRIC_UNIQUE_REACH`.
`UNIQUE_REACH_AUDIENCE`	Chỉ số có tiền tố `METRIC_UNIQUE_REACH`.

Lưu và sử dụng lại báo cáo

Bạn nên tạo và lưu báo cáo cho những truy vấn bạn chạy thường xuyên, vì việc chèn và xoá cùng một báo cáo nhiều lần làm lãng phí tài nguyên. Việc sử dụng các giá trị Range đã đặt (chẳng hạn như PREVIOUS_DAY hoặc LAST_7_DAYS) trong trường dataRange sẽ giúp báo cáo dễ sử dụng lại hơn.

Lập lịch báo cáo

Báo cáo đặc biệt hoặc báo cáo một lần có thể lãng phí tài nguyên vì được chạy riêng lẻ và có thể được thực thi trên một tập dữ liệu chưa hoàn chỉnh. Báo cáo theo lịch tận dụng tối đa các tài nguyên báo cáo vì chúng được chạy hàng loạt và đảm bảo sẽ không thực thi cho đến khi dữ liệu của ngày trước đó đã xử lý xong. Hãy xem các trường có thể sử dụng lịch hẹn để biết thông tin chi tiết.

Kết hợp các báo cáo tương tự

Nếu thường xuyên tạo các báo cáo có các chỉ số và phạm vi ngày giống nhau cho các nhà quảng cáo hoặc đối tác khác nhau, bạn nên kết hợp các báo cáo đó để tối ưu hoá lượng báo cáo.

Bạn có thể kết hợp các báo cáo tương tự bằng cách thêm bộ lọc của tất cả báo cáo và thêm tất cả các loại bộ lọc làm phương diện. Sau khi tạo, bạn có thể chia các hàng của báo cáo thu được theo các giá trị bộ lọc ban đầu để tạo báo cáo gốc.

Xem xét hạn mức báo cáo

Việc sử dụng tính năng báo cáo Display & Video 360 một cách có trách nhiệm được thực thi thông qua hạn mức sử dụng trên toàn sản phẩm sau đây.

Số lần thực thi báo cáo đặc biệt mỗi ngày

Giới hạn số lượng báo cáo đặc biệt mà một người dùng có thể chạy trong khoảng thời gian 24 giờ. Để không vượt quá hạn mức này:

Kết hợp các báo cáo tương tự để giảm số lượng báo cáo.
Lên lịch báo cáo đặc biệt định kỳ để giảm cụ thể khối lượng báo cáo đặc biệt.
Huỷ kích hoạt các tập lệnh API không cần thiết.

Báo cáo đang hoạt động được lập lịch

Giới hạn số lượng báo cáo mà người dùng có thể đã chủ động lên lịch vào một thời điểm nhất định. Để không vượt quá hạn mức này:

Kết hợp các báo cáo được lập lịch tương tự để giảm tổng số lượng báo cáo được lập lịch.
Tắt báo cáo gửi theo lịch không cần thiết.
Huỷ kích hoạt các tập lệnh API không cần thiết.

Báo cáo đồng thời

Giới hạn số lượng báo cáo mà một người dùng có thể chạy cùng lúc. Để không vượt quá hạn mức này:

Lên lịch chạy báo cáo thường xuyên.
Huỷ kích hoạt các tập lệnh API không cần thiết.
Theo dõi thời điểm hoàn tất báo cáo của bạn bằng cách thăm dò ý kiến sử dụng logic thời gian đợi luỹ thừa.

Nếu bạn đã tối ưu hoá việc triển khai tính năng báo cáo nhưng vẫn thấy vượt quá hạn mức đã đặt, hãy liên hệ với bộ phận hỗ trợ của Display & Video 360 bằng cách sử dụng biểu mẫu liên hệ.

Sử dụng thuật toán thời gian đợi luỹ thừa khi thăm dò ý kiến về trạng thái báo cáo

Không thể dự đoán khoảng thời gian để chạy báo cáo. Khoảng thời gian có thể dao động từ giây đến giờ tuỳ thuộc vào nhiều yếu tố, chẳng hạn như phạm vi ngày và lượng dữ liệu cần được xử lý. Ngoài ra, không có mối tương quan giữa thời gian chạy báo cáo và số lượng hàng được trả về trong báo cáo. Do đó, bạn cần thường xuyên truy xuất tài nguyên báo cáo bằng phương thức queries.reports.get và kiểm tra xem trường metadata.status.state của tài nguyên đã được cập nhật thành DONE hoặc FAILED hay chưa để xác định xem tài nguyên đã chạy xong hay chưa. Đây là một quá trình gọi là "cuộc thăm dò ý kiến".

Mặc dù cần thiết để thăm dò ý kiến, nhưng cách triển khai không hiệu quả có thể nhanh chóng làm hết hạn mức khi gặp một báo cáo chạy trong thời gian dài. Do đó, bạn nên sử dụng thuật toán thời gian đợi luỹ thừa để hạn chế số lượt thử lại và tiết kiệm hạn mức.

Thuật toán thời gian đợi luỹ thừa

Thuật toán thời gian đợi luỹ thừa là một chiến lược xử lý lỗi tiêu chuẩn cho các ứng dụng mạng, trong đó ứng dụng sẽ định kỳ thử lại yêu cầu trong khoảng thời gian tăng dần. Nếu được sử dụng đúng cách, thuật toán thời gian đợi luỹ thừa giúp tăng hiệu quả sử dụng băng thông, giảm số lượng yêu cầu cần thiết để nhận được phản hồi thành công và tối đa hoá thông lượng yêu cầu trong các môi trường đồng thời.

Quy trình triển khai thuật toán thời gian đợi lũy thừa đơn giản như sau:

Gửi yêu cầu queries.reports.get đến API.
Truy xuất đối tượng báo cáo. Nếu trường metadata.status.state không phải là DONE hoặc FAILED, tức là báo cáo chưa chạy xong nên tiếp tục thăm dò ý kiến.
Đợi 5 giây + một số mili giây ngẫu nhiên rồi thử lại yêu cầu.
Truy xuất đối tượng báo cáo. Nếu trường metadata.status.state không phải là DONE hoặc FAILED, tức là báo cáo chưa chạy xong nên tiếp tục thăm dò ý kiến.
Đợi 10 giây + một số mili giây ngẫu nhiên rồi thử lại yêu cầu.
Truy xuất đối tượng báo cáo. Nếu trường metadata.status.state không phải là DONE hoặc FAILED, tức là báo cáo chưa chạy xong nên tiếp tục thăm dò ý kiến.
Đợi 20 giây + một số mili giây ngẫu nhiên rồi thử lại yêu cầu.
Truy xuất đối tượng báo cáo. Nếu trường metadata.status.state không phải là DONE hoặc FAILED, tức là báo cáo chưa chạy xong nên tiếp tục thăm dò ý kiến.
Đợi 40 giây + một số mili giây ngẫu nhiên rồi thử lại yêu cầu.
Truy xuất đối tượng báo cáo. Nếu trường metadata.status.state không phải là DONE hoặc FAILED, tức là báo cáo chưa chạy xong nên tiếp tục thăm dò ý kiến.
Chờ 80 giây + một số mili giây ngẫu nhiên rồi thử lại yêu cầu.
Tiếp tục mẫu này cho đến khi đối tượng báo cáo được cập nhật hoặc đạt đến thời gian tối đa đã trôi qua.

Nếu báo cáo chạy xong và kết thúc ở trạng thái DONE, thì bạn có thể truy xuất tệp báo cáo đã tạo từ Google Cloud Storage tại đường dẫn đã cho trong trường metadata.googleCloudStoragePath.