Google Ads API のエンティティとレポートデータを取得するには、次のいずれかの方法を使用します。
2 つの方法の主な違いは次のとおりです。
| GoogleAdsService.SearchStream | GoogleAdsService.Search | |
|---|---|---|
| 本番環境コードに適している | はい | はい |
| サービス | GoogleAdsService |
GoogleAdsService |
| シナリオ | オブジェクトとレポートの取得 | オブジェクトとレポートの取得 |
| レスポンス | ストリームのGoogleAdsRow オブジェクト |
GoogleAdsRow オブジェクトのページ |
| レスポンスのフィールド | クエリで指定されたもののみ | クエリで指定されたもののみ |
| 1 日の使用上限 | アクセスレベルに基づく 1 日の使用上限 | アクセスレベルに基づく 1 日の使用上限 |
SearchStream 対 Search
Search は、レポート全体をダウンロードするために複数の
ページ分割されたリクエストを送信できますが、SearchStream は、レポートのサイズに関係なく、単一のリクエストを送信して Google Ads API との永続的な接続を開始します。
SearchStream の場合、データパケットはすぐにダウンロードを開始し、結果全体がデータバッファにキャッシュされます。コードは、ストリーム全体が完了するのを待たずに、バッファリングされたデータの読み取りを開始できます。
Search レスポンスの個々の
ページをリクエストするために必要なラウンドトリップ ネットワーク時間を排除することで、アプリによっては、SearchStream はページングよりもパフォーマンスが向上します。特に大きなレポートの場合に効果的です。
例
この例では、100,000 行で構成されるレポートについて説明します。次の表に、2 つの方法の会計上の違いを示します。
| SearchStream | 検索 | |
|---|---|---|
| ページサイズ | 該当なし | 1 ページあたり 10,000 行 |
| API リクエスト数 | 1 件のリクエスト | 10 件のリクエスト |
| API レスポンス数 | 1 つの連続ストリーム | 10 件のレスポンス |
パフォーマンス要因
ほとんどのユースケースでは、Search よりも SearchStream をおすすめします。次の
理由から:
単一ページのレポート(10,000 行未満)の場合: 2 つの方法の間に大きなパフォーマンスの違いはありません。
複数ページのレポートの場合: 複数のラウンドトリップが回避され、ディスク キャッシュからの読み取りまたは書き込みが要因となることが少ないため、通常は
SearchStreamの方が高速です。
レート上限
どちらの方法でも、1 日の上限は、開発者トークンの標準の上限とアクセス レベルに準拠しています。結果がページ分割またはストリーミングされているかどうかにかかわらず、1 つのクエリまたはレポートは 1 つのオペレーションとしてカウントされます。