현재 일부 보고서 유형이 오프라인에서 빠른 보고서로 이전 중입니다. 사용자가 이전되면 queries.list 응답에 기존의 빠른 보고서가 포함됩니다. 자세한 내용은 블로그 게시물을 참고하세요.

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

보고 권장사항

UI에서 먼저 새 보고서 작성

보고서에는 보고 유형, 필터, 측정기준, 측정항목과 관련된 여러 제한사항과 요구사항이 적용됩니다. 이러한 제한은 API에 적용되어 HTTP 400 오류를 반환합니다. 보고서 작성 시 오류를 방지하려면 먼저 Display & Video 360 UI에서 새 보고서를 빌드하는 것이 좋습니다.

보고서를 작성한 후 참조 문서 페이지에서 'API 사용해 보기' 기능을 클릭하여 Query 리소스의 queries.get를 실행합니다. 반환된 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`인 측정항목입니다.

보고서 저장 및 재사용하기

동일한 보고서를 여러 번 삽입하고 삭제하면 리소스가 낭비되므로 정기적으로 실행하는 쿼리에 대한 보고서를 만들고 저장하는 것이 좋습니다. dataRange 필드에서 설정된 Range 값(예: PREVIOUS_DAY 또는 LAST_7_DAYS)을 사용하면 보고서의 재사용 가능성이 높아집니다.

보고서 예약

임시 또는 일회성 보고서는 개별적으로 실행되며 불완전한 데이터 세트에 대해 실행될 수 있으므로 리소스를 낭비할 수 있습니다. 예약된 보고서는 보고 리소스를 최대한 활용합니다. 대량으로 실행되고 전날의 데이터 처리가 완료될 때까지 실행되지 않기 때문입니다. 자세한 내용은 사용 가능한 예약 필드를 참조하세요.

유사한 보고서 결합

서로 다른 광고주 또는 파트너에 대해 동일한 측정항목과 기간이 포함된 보고서를 정기적으로 생성하는 경우, 보고서를 결합하여 보고서 양을 최적화하는 것이 좋습니다.

모든 보고서의 필터를 추가하고 모든 필터 유형을 측정기준으로 추가하여 유사한 보고서를 결합할 수 있습니다. 생성 후 결과 보고서의 행을 원래 필터 값에 따라 분할하여 원본 보고서를 생성할 수 있습니다.

보고 할당량 고려하기

Display & Video 360 보고 기능의 책임감 있는 사용은 다음과 같은 제품 전체 사용 할당량을 통해 적용됩니다.

일일 임시 보고서 실행

사용자가 24시간 동안 실행할 수 있는 임시 보고서 수를 제한합니다. 이 할당량을 초과하지 않으려면 다음 안내를 따르세요.

유사한 보고서를 결합하여 보고서 양을 줄입니다.
반복되는 임시 보고서를 예약하여 임시 보고서 양을 줄입니다.
불필요한 API 스크립트를 비활성화합니다.

활성화된 예약 보고서

사용자가 특정 시간에 적극적으로 예약할 수 있는 보고서 수를 제한합니다. 이 할당량을 초과하지 않으려면 다음 안내를 따르세요.

유사한 예약 보고서를 결합하여 총 예약 보고서 수를 줄입니다.
불필요한 예약된 보고서를 비활성화합니다.
불필요한 API 스크립트를 비활성화합니다.

동시 보고서

사용자가 동시에 실행할 수 있는 보고서 수를 제한합니다. 이 할당량을 초과하지 않으려면 다음 안내를 따르세요.

정기적으로 실행되는 보고서를 예약합니다.
불필요한 API 스크립트를 비활성화합니다.
지수 백오프 로직을 사용한 폴링으로 보고서가 완료되는 시점을 추적합니다.

보고서 구현을 최적화한 후에도 여전히 지정된 할당량을 초과하는 경우 문의 양식을 사용하여 Display & Video 360 지원팀에 문의하세요.

보고서 상태 폴링 시 지수 백오프 사용

보고서를 실행하는 데 걸리는 시간은 예측할 수 없습니다. 이 시간은 기간 및 처리할 데이터의 양 등 다양한 요인에 따라 초에서 몇 시간까지 걸릴 수 있습니다. 또한 보고서 런타임과 보고서에 반환되는 행 수 간에는 상관관계가 없습니다. 따라서 queries.reports.get 메서드를 사용하여 보고서 리소스를 정기적으로 검색하고 리소스의 metadata.status.state 필드가 DONE 또는 FAILED로 업데이트되어 실행이 완료되었는지 확인해야 합니다. 이를 '폴링'이라고 합니다.

폴링이 필요하지만 비효율적인 구현으로 인해 장기 실행 보고서가 발생할 때 할당량이 빠르게 소진될 수 있습니다. 따라서 지수 백오프를 사용하여 재시도를 제한하고 할당량을 보존하는 것이 좋습니다.

지수 백오프

지수 백오프는 클라이언트에서 시간 간격을 늘려 요청을 주기적으로 다시 시도하는 네트워크 애플리케이션의 표준 오류 처리 전략입니다. 지수 백오프를 적절하게 사용하면 대역폭 사용량의 효율성을 높이고, 성공적인 응답을 가져오는 데 필요한 요청 수를 줄이며, 동시 환경에서의 요청 처리량을 극대화할 수 있습니다.

간단한 지수 백오프 구현 흐름은 다음과 같습니다.

API에 queries.reports.get 요청을 전송합니다.
보고서 객체를 검색합니다. metadata.status.state 필드가 DONE 또는 FAILED가 아니면 보고서 실행이 완료되지 않았음을 나타냅니다.
5초 + 임의의 밀리초를 더한 대기 후 요청을 재시도합니다.
보고서 객체를 검색합니다. metadata.status.state 필드가 DONE 또는 FAILED가 아니면 보고서 실행이 완료되지 않았음을 나타냅니다.
10초 + 임의의 밀리초를 대기한 후 요청을 재시도합니다.
보고서 객체를 검색합니다. metadata.status.state 필드가 DONE 또는 FAILED가 아니면 보고서 실행이 완료되지 않았음을 나타냅니다.
20초 + 임의의 밀리초를 대기한 후 요청을 재시도합니다.
보고서 객체를 검색합니다. metadata.status.state 필드가 DONE 또는 FAILED가 아니면 보고서 실행이 완료되지 않았음을 나타냅니다.
40초 + 임의의 밀리초를 대기한 후 요청을 재시도합니다.
보고서 객체를 검색합니다. metadata.status.state 필드가 DONE 또는 FAILED가 아니면 보고서 실행이 완료되지 않았음을 나타냅니다.
80초 + 임의의 밀리초를 대기한 후 요청을 재시도합니다.
보고서 객체가 업데이트되거나 최대 경과 시간에 도달할 때까지 이 패턴을 계속합니다.

보고서 실행이 완료되고 DONE 상태로 끝나면 metadata.googleCloudStoragePath 필드에 지정된 경로의 Google Cloud Storage에서 생성된 보고서 파일을 검색할 수 있습니다.