Chúng tôi hiện đang di chuyển một số loại báo cáo từ báo cáo ngoại tuyến sang báo cáo tức thì. Sau khi người dùng được di chuyển, các phản hồi trong queries.list sẽ bao gồm các báo cáo tức thì hiện có. Hãy xem bài đăng trên blog của chúng tôi để biết thêm thông tin.

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

Báo cáo phải tuân thủ một số quy định hạn chế và yêu cầu liên quan đến loại báo cáo, bộ lọc, phương diện và chỉ số. Các 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 "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 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 chỉ dành riêng cho một số loại báo cáo nhất định. Ngoài việc tạo 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 về một số giá trị ReportType nhất định theo giá trị API của Trình quản lý giá thầu.

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

`ReportType`	Các bộ lọc và chỉ số có liên quan
`YOUTUBE`	Bộ lọc có tiền tố `FILTER_TRUEVIEW`. 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 các truy vấn mà bạn thường xuyên chạy vì việc chèn và xoá cùng một báo cáo nhiều lần sẽ 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 có thể sử dụng lại nhiều lần hơn.

Lên lịch gửi 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ác báo cáo này được chạy riêng lẻ và có thể thực thi trên một tập dữ liệu chưa hoàn chỉnh. Báo cáo định kỳ tận dụng tối đa tài nguyên báo cáo vì chúng được chạy hàng loạt và được đảm bảo không thực thi cho đến khi dữ liệu của ngày trước hoàn tất quá trình xử lý. Hãy xem các trường lên lịch có sẵ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 báo cáo có các chỉ số và phạm vi ngày giống nhau cho nhiều nhà quảng cáo hoặc đối tác, bạn nên kết hợp các báo cáo đó để tối ưu hoá số lượng báo cáo.

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

Cân nhắc hạn mức báo cáo

Chúng tôi thực thi 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 thông qua các 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à người dùng có thể chạy trong khoảng thời gian 24 giờ. Cách duy trì 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ập lịch báo cáo đặc biệt định kỳ để giảm số lượng báo cáo đặc biệt một cách cụ thể.
Huỷ kích hoạt các tập lệnh API không cần thiết.

Báo cáo định kỳ đang hoạt động

Giới hạn số lượng báo cáo mà người dùng có thể lập lịch gửi vào một thời điểm nhất định. Cách duy trì hạn mức này:

Kết hợp các báo cáo định kỳ tương tự nhau để giảm tổng số báo cáo định kỳ.
Tắt các báo cáo định kỳ 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à người dùng có thể chạy đồng thời. Cách duy trì hạn mức này:

Lên lịch chạy báo cáo định kỳ.
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 báo cáo của bạn hoàn tất bằng cách thăm dò ý kiến bằng logic thời gian đợi luỹ thừa.

Nếu bạn đã tối ưu hoá việc triển khai báo cáo nhưng vẫn vượt quá hạn mức đã cho, hãy liên hệ với nhóm hỗ trợ Display & Video 360 bằng biểu mẫu liên hệ.

Sử dụng thuật toán đợ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 thời gian chạy của một báo cáo. Thời lượng có thể dao động từ vài giây đến vài 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 xử lý. Ngoài ra, không có mối tương quan nào giữa thời gian chạy báo cáo và số 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 hay FAILED hay chưa để xác định xem tài nguyên đó đã chạy xong hay chưa. Đây là một quy trình được gọi là "bầu cử".

Mặc dù việc thăm dò ý kiến là cần thiết, nhưng việc triển khai không hiệu quả có thể nhanh chóng làm cạn kiệt hạn mức của bạn khi gặp phải 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 để giới hạn số lần 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 chuẩn cho các ứng dụng mạng, trong đó ứng dụng thực hiện hoạt động thử lại định kỳ đối với một 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 sẽ 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 để có đượ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:

Tạo yêu cầu queries.reports.get cho 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, thì điều đó cho biết báo cáo chưa chạy xong và bạn 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, thì điều đó cho biết báo cáo chưa chạy xong và bạn 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, thì điều đó cho biết báo cáo chưa chạy xong và bạn 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, thì điều đó cho biết báo cáo chưa chạy xong và bạn 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, thì điều đó cho biết báo cáo chưa chạy xong và bạn nên tiếp tục thăm dò ý kiến.
Đợi 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 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 theo đường dẫn được cung cấp trong trường metadata.googleCloudStoragePath.