먼저 UI에서 새 보고서 빌드
보고서에는 보고 유형, 필터, 측정기준, 측정항목과 관련된 여러 제한사항과 요구사항이 적용됩니다. 이러한 제한사항은 API에서 적용되며 HTTP 400
오류를 반환합니다. 보고서를 만들 때 오류가 발생하지 않도록 하려면 먼저 Display & Video 360 UI에서 새 보고서를 만드는 것이 좋습니다.
보고서를 빌드한 후 참조 문서 페이지에서 '이 API 사용해 보기' 기능을 클릭하여 Query
리소스의 queries.get
를 실행합니다. 반환된 JSON을 사용하여 향후 보고서를 빌드할 수 있습니다.
보고서 유형별 측정항목 및 필터 사용
일부 측정항목 및 필터 값은 특정 보고서 유형에만 적용됩니다. 먼저 UI에서 보고서를 빌드하는 것 외에도 입찰 관리자 API 값을 기준으로 특정 ReportType
값에 속하는 측정항목과 필터를 식별할 수도 있습니다.
다음은 관련 입찰 관리자 API 필터 및 측정항목 값을 식별하는 몇 가지 방법입니다. 이 표에는 이러한 유형의 보고서에 사용할 수 있는 필터와 측정항목이 모두 나와 있는 것은 아닙니다. 일부 값은 단일 보고서에서 함께 사용할 수 없습니다.
ReportType |
관련 필터 및 측정항목 |
---|---|
YOUTUBE |
|
GRP |
|
YOUTUBE_PROGRAMMATIC_GUARANTEED |
|
REACH |
|
UNIQUE_REACH_AUDIENCE |
|
보고서 저장 및 재사용
동일한 보고서를 여러 번 삽입하고 삭제하면 리소스가 낭비되므로 정기적으로 실행하는 쿼리에 대한 보고서를 만들어 저장하는 것이 좋습니다.
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에서 생성된 보고서 파일을 검색할 수 있습니다.